[Accessforall] Minutes of AccessForAll Meeting on 2012-01-31
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...
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?
> 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
>>> 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
>>>> it might become so after we considered how people and tools
>>>> 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)
>>> they don't exist.
>>> so for theoretical discussions URI is fine. But now that I think
>>> 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
>>>> where there are federated registries (which is one way to filter
>>>> culturally for example) - but in my mind we are talking about a
>>>> 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
>>> not in) the COMMON TERMs registry but that is for convenience - not
>>> required. Companies can put their terms anywhere they like -- and
>>> 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
> Accessforall mailing list
> Accessforall at fluidproject.org
More information about the Accessforall