[Accessforall] Minutes of AccessForAll Meeting on 2012-01-31
gv at trace.wisc.edu
Sat Feb 11 20:50:35 UTC 2012
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?
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
>>> - 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.
> Andy Heath
> Accessforall mailing list
> Accessforall at fluidproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Accessforall