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

Andy Heath andyheath at axelrod.plus.com
Sun Feb 12 22:19:12 UTC 2012

comments edited in.
> 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.
>  1. we have a preference which is stored somewhere -- and we want to
>     apply it to a piece of software (or hardware/software)
>  2. we get the preference and pass it on to something (settings handler)
>     that will cause it to set the applications settings.
>      1. this handler may be custom to the application -- or a system
>         handler if the app uses the system method for application settings
>  3. 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
>      1. the preference is either
>          1. specific to that app,
>          2. or the handler translates it to the specific setting for the app
>          3. or there is a translator in the pipe between the preference
>             storage and the handler that translates it.
>  4. 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?

Not missing anything I can see - this seems to be a completely correct 
description of the use of preferences. What Colin and I were talking 
about was content/services (sorry to confuse) - i.e. what you describe 
in your sections 3.1.2 and 3.1.3 above (which might be mediated in a 
proxy, so from some viewpoints what you see might not be what you get 
;-) ) - it doesn't seem to apply to preferences.

The one thing where there could be some deviation from the view you 
paint is where human interface meets the preference store - where there 
might be presentation of terms in a local language for example - so the 
view one sees of a URL in one language domain (country) might not be the 
same as might not be the same as in another, though the URL would be the 
same. The only use case where there might be a local copy of a 
registered term is where the database or parts have been cached for 
efficiency. This has no impact on the picture you paint Greg AFAI can see.

You refer to what is being implemented in GPII - this is of course a 
black box looking from here at this point in time, for me anyway.

> 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


Andy Heath

More information about the Accessforall mailing list