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

Gregg Vanderheiden gv at trace.wisc.edu
Sat Feb 11 22:58:44 UTC 2012


I think we also have a slightly different use case between  a) finding best match materials  and b) setting the features on the device in front of us.   

Yet we need to keep both in mind (as well as the fact that these are all blurred together when it isnt a device but an application in front of us) 



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 11, 2012, at 3:48 PM, Liddy Nevile wrote:

> 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
> 
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120211/37f201ea/attachment-0001.html>


More information about the Accessforall mailing list