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

Liddy Nevile liddy at sunriseresearch.org
Thu Feb 9 21:51:39 UTC 2012


clearly one of the great advantages of using URIs as Gottfried  
suggests is that there will be no confusion even when the properties  
etc are in 100 different human languages :-)


On 10/02/2012, at 8:21 AM, Gregg Vanderheiden wrote:

> yep
> this is similar to what we are doing.
> like to be able to handle localization though-- and not have to  
> freeze the english names.  so I suggest the base reference not be  
> human language.   but all viewing of them by humans is human  
> language (label paired with stable non-language based unique code).
>
> 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 9, 2012, at 3:18 PM, Liddy Nevile wrote:
>
>> thanks for this!
>> I think I get tags...
>>
>> The usual way to handle the URIs is to have namespaces that are  
>> identified and then a prefix (eg AFA) is used so the individual  
>> terms are found in the relevant namespace. I am not sure why there  
>> is a problem - if the pairs have words those can appear in the code  
>> - AFA:textsize - for example would send a machine to a namespace  
>> identified by AFA and the human can see what's happening.
>>
>> Liddy
>>
>> On 10/02/2012, at 6:14 AM, Gregg Vanderheiden wrote:
>>
>>>
>>>
>>> On Feb 9, 2012, at 10:54 AM, Clark, Colin wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> Responses inline...
>>>>
>>>> On 2012-02-09, at 12:38 AM, Gregg Vanderheiden wrote:
>>>>> GV:   I think hierarchy is a problem -- since many preferences  
>>>>> will end up in more than one parent -- with either Aliasing or  
>>>>> duplicating (with the problem of maintaining) can be a problem.
>>>>
>>>> So here you're arguing that duplication is a problem for  
>>>> hierarchies, but in the case of redundantly prefixing each and  
>>>> every property in a preferences profile with a long URL, you  
>>>> don't think duplication is a problem?
>>>
>>>
>>> different topics
>>>
>>> one has to do with the same preference appearing in multiple times  
>>> in a hierarch and having to be maintained there.
>>>
>>> the other has to do with a long string of characters that keeps  
>>> appearing for each (different) preference belonging to the same  
>>> origin.   it is a file length problem only.    but as I pointed  
>>> out below - I don't think that it is a problem because
>>> 1) any file viewer could lay things out so that those were in a  
>>> separate 'column' and easy to ignore (or they could be put AFTER  
>>> the name - value pair on the display to make it easy for screen  
>>> readers to ignore them by moving on to the next line  -- or having  
>>> them hidden.
>>> 2) they could be tokenized  or compressed (which will tokenize them)
>>>
>>> so no problem for using URLs
>>>
>>>>
>>>>> My personal belief is that we should use TAGS rather than  
>>>>> categories.   It is easy to find all of the preferences that  
>>>>> relate to any TAG and a preference could have many different tags.
>>>>>
>>>>> Again - there can even be different TAG sets - reflecting  
>>>>> different models of the world.
>>>>
>>>> Tags are a really cool idea. Gregg, can you take a stab at  
>>>> showing how you'd represent tags using the "simple data  
>>>> structures" we all favour? (hint: you'll need containment)
>>>>
>>>> Also, it's worth trying to sketch out the algorithm we'd propose  
>>>> to implementors for parsing tags and matching them to categories  
>>>> of assistive technologies. Gregg, do you want to take a stab at  
>>>> that? It's likely a more complex algorithm than traversing a  
>>>> straight hierarchy, but it might well be a worthwhile approach.
>>>
>>> Lets chat.   Tags are mostly used to find things.   Like keywords  
>>> for documents.
>>>
>>> "show me all the preferences for people who are BLIND or   have  
>>> COGNITIVE DISABILITIES   or   are DEAF"
>>> "show me all the preferences that relate to SCREEN READERS"
>>> "show me all the preferences that relate to VOICE SYNTHESIZERS
>>> "show me all the preferences that relate to TEXT COMMUNICATION
>>> "show me all the preferences that relate to CAPTIONS
>>> "show me all the preferences that relate to
>>>
>>>>
>>>>>> 1. They're easy for machines, but are hard for people to read.  
>>>>>> We want our specification to be as approachable and easy-to- 
>>>>>> understand as possible. Using URLs instead of readable names  
>>>>>> increases complexity; when I read through the UIC spec, I found  
>>>>>> it a bit intimidating.
>>>>>
>>>>> GV:  what is your alternative that would provide guaranteed  
>>>>> unique?
>>>
>>> absolutely no need for anything to be unique except      
>>> preferenceRef:source
>>> since we may want translations, I would make the PreferenceRef a  
>>> number so it becomes     PrefNumber:RegistryID
>>>
>>>
>>> a registry entry would be would have a unique identifier of
>>> PrefNumber:RegistryID
>>> and values of     ValueType, ValueRange
>>>
>>> A separate file can contain names so that it can be localized.
>>>
>>> Another file can contain the tags or outlines - so that different  
>>> ones can be proposed.
>>>
>>>
>>>>
>>>> As I said in my previous email, I'm proposing the optional  
>>>> inclusion of a unique namespace housed at the top of a collection  
>>>> of preferences to which the namespace applies. It's easy for  
>>>> implementers to handle, simple to express, and doesn't repeat  
>>>> itself.
>>>>
>>>>>> 2. Prepending a namespace (URI) to each and every key will have  
>>>>>> a substantial performance impact on real-world implementations.  
>>>>>> Remember that in many applications, the user's profile will be  
>>>>>> sent across the network and may be processed and transformed  
>>>>>> multiple times. For Cloud4all, we're anticipating supporting  
>>>>>> mobile devices and global deployments; sending redundant data  
>>>>>> across slow connections (like a mobile phone's EDGE connection)  
>>>>>> will be a bottleneck. "Don't Repeat Yourself" (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself 
>>>>>> ) is a very useful principle we can apply to our specification.
>>>>>
>>>>> GV:  I agree - but couldn’t you handle this with a token /  
>>>>> variable at the top for any URI/URL that is repeated in the  
>>>>> string?
>>>>
>>>> I don't quite understand what you're suggesting, but it sounds  
>>>> vaguely reminiscent of what I'm proposing.
>>>
>>> just a way to not repeat a very long string 99 times.  you just  
>>> create a token for the phrase.
>>>
>>>
>>>>
>>>>> (won't we send as compressed - and this is what the compression  
>>>>> routine will do automatically )
>>>>
>>>> Perhaps, but that's an implementation detail. A specification  
>>>> shouldn't force implementors into a particular performance  
>>>> optimization in order to work around its weaknesses.
>>>
>>>
>>> agree
>>>>
>>>>
>>>> ---
>>>> Colin Clark
>>>> Lead Software Architect,
>>>> Inclusive Design Research Centre, OCAD University
>>>> http://inclusivedesign.ca
>>>>
>>>
>>> _______________________________________________
>>> 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
>



More information about the Accessforall mailing list