[Accessforall] Minutes of AccessForAll Meeting on 2012-01-31

Liddy Nevile liddy at sunriseresearch.org
Sat Feb 11 21:48:30 UTC 2012


I think this is right - the bit about having a local property-value  
pair comes from our experience where people use the public stuff - say  
the gpii stuff, but also have a couple of pairs that relate to their  
local needs - eg - previous accesses of this doc. With the flat  
structure these local properties can be alongside the global ones.

One of the things I wrestled with when we were doing 24751 and I was  
trying to do a flat pairs model for DCMI so AccessForAll could be used  
on the web, was that if you have preferences and use those to try to  
satisfy a user's needs, but fail because there is not a service or  
alternative that can work for the user, then how do you search for  
something that will work? I thought that then you would want to grab  
the metadata (or make some) from what you did get as possible  
resources and then construct a new search with a wider set of  
criteria. That is, have the system learn from the resources that were  
not quite right so it can make a new attempt to find what will be  
useful. The lesson from this thinking is that it is not just a matter  
of constraining the first search - especially as that might not bring  
back what you will want to use later - it is more a matter of doing a  
search for the resource and then filtering it.... either to find the  
right resource or to set up a new search...

Liddy


On 12/02/2012, at 7:50 AM, Gregg Vanderheiden wrote:

> We need to think about what we are talking about here.
>
> Let me check the thought pattern here and see if we are all talking  
> about the same thing.
>
> 	• we have a preference which is stored somewhere -- and we want to  
> apply it to a piece of software   (or hardware/software)
> 	• we get the preference and pass it on to something (settings  
> handler) that will cause it to set the applications settings.
> 		• this handler may be custom to the application -- or a system  
> handler if the app uses the system method for application settings
> 	• This handler must be able to know the MEANING of that preference  
> - so they know how to translate it into the setting of the  
> particular app
> 		• the preference is either
> 			• specific to that app,
> 			• or the handler translates it to the specific setting for the app
> 			• or there is a translator in the pipe between the preference  
> storage and the handler that translates it.
> 	• in order for the handler (or translator) to make it specific to  
> the application the handler/translator must have some way of knowing  
> what that preference means in relation to this specific app
>
> Now - if the preference is not from some recognized registry (and  
> does not have a recognized meaning) then it is not clear how it can  
> be used.
>
> So I can understand how preferences can be stored locally - -but I  
> don't understand how their  identification,  their UniqueID if you  
> will, can be a local site (unless this is something theoretical  
> rather than the GPII as we  are talking about it.
>
> I had thought that the URL we were talking about -- was part of  
> the   name-value pair.   That is, it was the namespace part of the    
> namespace/name-value pair.
>
> In that case we need something unique for the namespace/name  and I  
> had thought we were nominating the a URL to be the namespace (or the  
> key part of it that guaranteed both the uniqueness of the namespace/ 
> name and also could be a very handy pointer back to where we can  
> find description information as to who controls the namespace and  
> where the description of the intended meaning for each of the names  
> in the namespace was.
>
> Am I missing something?
> or misconceiving something?
>
> thx
>
> Gregg
> --------------------------------------------------------
> Gregg Vanderheiden Ph.D.
> Director Trace R&D Center
> Professor Industrial & Systems Engineering
> and Biomedical Engineering
> University of Wisconsin-Madison
>
> Co-Director, Raising the Floor - International
> and the Global Public Inclusive Infrastructure Project
> http://Raisingthefloor.org   ---   http://GPII.net
>
>
>
>
>
>
>
>
> On Feb 10, 2012, at 2:33 PM, Andy Heath wrote:
>
>> akh:comments edited in below
>>
>>>> I believe a URL gives a means to access a resource
>>> Right
>>>> - subtly different from where the resource came from (not that that
>>>> has impact for the matter here).
>>> actually the URL should lead directly to the location of the  
>>> registry
>>> that the info came from.
>>
>> akh: Not necessarily - e.g. local cache (maybe held in a proxy -  
>> transparently to the user) is a good way to speed stuff up (and  
>> answers Colin's point from an earlier mail - having extensive  
>> references that *seem* to go out to the web is not necessarily  
>> inefficient). In fact that might be one way to have an abstract API  
>> that doesn't know whether some facility is on the device or remote.  
>> We adopted this approach in EU4ALL, a European project I worked on  
>> that implemented 24751. URL's are not always what they might seem.
>>
>>>
>>>> I don't think the URL/URI distinction is important at this point  
>>>> but
>>>> it might become so after we considered how people and tools  
>>>> interact
>>>> with "the" registry. It is easily revisited later.
>>> A URI SHOULD also lead you directly there. But it would require that
>>> there are universal servers (e.g. universal name server for a URN)  
>>> and
>>> they don't exist.
>>> so for theoretical discussions URI is fine. But now that I think  
>>> about
>>> it -- I think we should stick with URL so it will actually work.
>>
>> akh:That's fine - its easy to change later if needed.
>>
>>>>
>>>> I called it ""the" registry" because it occurred to me while I was
>>>> thinking about the URL/URI question is that there are ways to do  
>>>> this
>>>> where there are federated registries (which is one way to filter
>>>> culturally for example) - but in my mind we are talking about a  
>>>> single
>>>> registry here - as specified in 1.
>>>
>>> I think we will have one COMMON TERMS registry for GPII - but  
>>> there will
>>> be many since each company or creator can create new TERMs for their
>>> product(s) and they will not be in th COMMON TERMS registry
>>> We are setting up a mechanism for companies to store them next to  
>>> (but
>>> not in) the COMMON TERMs registry but that is for convenience - not
>>> required. Companies can put their terms anywhere they like -- and  
>>> the
>>> URL would point to them. At least that is the current plan --  
>>> subject to
>>> modification with better ideas. We are implementing one now however
>>> since we need it in the next 60 days to be operational.
>>>
>>
>> akh:sounds ok.
>>
>>
>> Cheers
>>
>> andy
>> -- 
>> __________________
>> Andy Heath
>> http://axelafa.com
>>
>> _______________________________________________
>> Accessforall mailing list
>> Accessforall at fluidproject.org
>> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall
>
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall



More information about the Accessforall mailing list