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

Erlend Øverby erlend.overby at karde.no
Mon Feb 13 08:40:37 UTC 2012


My thought on this... I think much of our discussions are based on different use-cases, and since we do not have a common use-case for our discussions, we will continue to have some misunderstanding. The case that some we have different insight to the puzzle and related activities could also cause some confusion.

I have some comments inbetween here.

Den 11. feb. 2012 kl. 21:50 skrev Gregg Vanderheiden:

> 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)

This implies that the preference is either pushed to the piece of software or hardware. Or that the sw/hw gets the preference from somwhere.
- If the preference is pushed, the sw/hw must be able to manage all kinds of preferences, because it does not know what is pushed.
- If the sw/hw askes for the preference, it could in the asking also state the format of the preference avoiding any problems with interoperability.

> we get the preference and pass it on to something (settings handler) that will cause it to set the applications settings.

This implies that there is some smartness somewhere that knows the personal preferences, knows the applications capacities, and then sends an information package with settings the application know how to react to.

> this handler may be custom to the application -- or a system handler if the app uses the system method for application settings

I understand this as the handler working as a translator, that ensures that application knows how to react properly to the preferences we set. With a translator we could also have very specific preferences for very specific applications, and the translator service will then be able to communicate with a "closed preference/settings eco-system".

> 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.

Yes - my understanding as well.

> 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
It also need to know the peculiarities of the app, how this is communicated is as far as I know not been discussed yet. (it could be a specific application profile of the work we are doing now.) Peculiarities of an application should be expressed following the same principles as we are expressing all our metadata.

> 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.

With a local UniqueID, an application could have its own set of preferences, specifying any odd capacity of the application. The UniqueID that is used to identify the preferences of the application, is then used by the translator to share this information. The translator SW will follow the UniqueID, end up at some strange place, and try to harvest as much information as possible so that the appropriate settings could be applied (communicated). Ideally by following the different identifiers at the local vendors store, we should end up at a globally recognized and well known store. This will then tell the translator that the preferences are extensions from something we know, and then something we should know to handle.

> 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. 

This is one way of seeing it. If we have a name-value pair we will have a database with two columns, instead of the RDF three columns.

> 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.

In all practical implementations, the URI will be a URL :-)
The URL should ideally lead to some meaningful information for both humans and machines. 
(The XML Namespace - failed at this point)

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120213/38656db2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2769 bytes
Desc: not available
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120213/38656db2/attachment-0001.bin>

More information about the Accessforall mailing list