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

Liddy Nevile liddy at sunriseresearch.org
Thu Feb 9 06:39:26 UTC 2012

lots of good discussion.

I think we should remember that from the perspective of JTC1, a lot of  
work has been done to make a standard for metadata that is the  
simplest and most used way of providing and implementing metadata. I  
think at least for the purposes of JTC1, this expert advice should be  
noted. Beyond that, as most major entities in Europe use the sort of  
metadata advocated now by JTC1, I see no reason for trying to invent a  
better way of doing things?

Eric Miller has pointed out that the magic of URIs, as Tim BL says, is  
that they can always be disambiguated and they make it easy for people  
to add their own. I am not an expert in optimization but I do know  
that the use of URIs does not mean that people get lost because  
everything is URIs instead of words. The usual implementations have  
clear instructions and wizards for humans that 'speak' about the  
definitions of the terms represented by the URIs in ways that are  
appropriate to the audience using the wizards - and these vary  
enormously without any effect on the resulting metadata.

I am not clear what you mean by tags - I think you mean the same thing  
as Gottfried is advocating, in fact?  properties with values?


On 09/02/2012, at 4:38 PM, Gregg Vanderheiden wrote:

> GV: Comments below
> On Feb 8, 2012, at 6:55 PM, Clark, Colin wrote:
>> Hi Gottfried,
>> Here are some ideas that I have been contemplating since  
>> yesterday's meeting...
>> On 2012-01-31, at 3:07 PM, Gottfried Zimmermann (List) wrote:
>>> 	• A user profile consists of property-value pairs in a flat  
>>> structure.
>>> 		• Should not have complex structures - we need simple structures  
>>> that could be combined to express complex things
>> Can you elaborate a bit more on why you think that user profiles  
>> must be a flat structure?
>> I agree 100% that we need to ensure that all preferences can be  
>> represented using standard data structures--the things that work  
>> across all programming languages and technologies. In practice,  
>> we're talking about the basics: Strings, Numbers, Booleans, Arrays,  
>> and Dictionaries. But I think the careful use of hierarchy can be a  
>> helpful tool for grouping and categorizing properties within a  
>> user's preferences. It's a balancing act, but I think that a fully  
>> flat structure (no containers) will be substantially more complex  
>> than a judicious use of hierarchy.
>> Were you thinking of this differently?
> 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.
> ALso there are many ways to build a hierarchy.
> I thought from our discussion that we were going to go with a flat  
> listing -- over which many different SORTS or ontologies or  
> groupings could be mapped.
> 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.
> A lesson on categories can be taken from the European work to create  
> a taxonomy of assistive technologies.   What makes sense as a  
> hierarchy in one language will make no sense in another language.
> So I would suggest
> 1) we use flat set of
> 2) we support that ability to associate any set of TAGs
> 	- Note that a hierarchy can be represented as a set of TAGs with a  
> specific set of constraints.    and displayed as a hierarchy  
> whenever desired.   (and this would even allow duplicates in  
> different parents / nodes )
> 3) we create a set of TAGs that we think are most useful (but our  
> set could be easily replaced in the future if someone else creates a  
> better set) (or the old and new tags can reside side by side and  
> people just use the one they prefer.
>>> 	• Keys are URIs, values are of any type that can be stored as a  
>>> string.
>>> 	• The definition of a key consists of its URI, and its type and  
>>> value space (e.g. enumerated values, integer).  (See http://myurc.org/TR/res-prop-vocab1.0/ 
>>>  as an example.)
>> I think I see the problem you're trying to solve here, and I think  
>> it's an important one. I'm wondering if we can bounce around a few  
>> alternative approaches?
>> If I understand your proposal correctly, the goal of using URIs for  
>> key names is to ensure that the community can freely extend the  
>> specification in a coordinated but agile way. This makes perfect  
>> sense; namespacing helps avoid collisions and provides room for  
>> easy extension.
>> However, I have two reservations about the idea of using a URI for  
>> key names in our specification:
> \GV:  I share your concern.
>> 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?
>> 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?
> (won't we send as compressed - and this is what the compression  
> routine will do automatically )
>> Could we instead consider a model where preferences can be stored  
>> in "buckets," each of which may optionally have a namespace  
>> associated with it? Here's a few examples of what I'm thinking of;  
>> I'm using JSON syntax (http://www.json.org/fatfree.html) because  
>> it's simple, but this should work in any representation.
> GV:  interesting - but if they are all distributed -- and the same  
> term is used by different buckets... would it result in the same or  
> similar?
>> For codified, fully-standardized preferences, we can omit a  
>> namespace:
>> {
>>    screenReader: {
>>        usage: "required",
>>        speechRate: 80,
>>        pitch: 0.6,
>>        volume: 0.4
>>    }
>> }
>> A community extension (this is a pretty contrived example, but  
>> hopefully you get the point):
>> {
>>    screenReader: {
>>        usage: "required",
>>        speechRate: 80,
>>        pitch: 0.6,
>>        volume: 0.4
>>    },
>>    extension: {
>>        namespace: "http://www.iata.org/airplanePreferences"
>>        name: "Airline booking preferences",
>>        fields: {
>> 		seat: "aisle",
>>                meal: "vegetarian"
>>        }
>>    }
>> }
>> Again, this is just a sketch--I'll talk to the rest of the GPII  
>> development team to get their thoughts on the issue. The key take- 
>> away here, though, is that instead of using URLs for each key, we  
>> can make strategic use of containers to group together attributes  
>> under a particular namespace. The end result is a slimmer, less  
>> repetitive structure.
>>> 	• Both core properties and live properties are stored in a  
>>> registry database.
>>> 	• The registry database is hosted by Raising the Floor.
>>> 	• A Web-based interface provides access to the registry for the  
>>> public.
>> I think it's a great idea to have an open, web-based place to share  
>> community extensions. For the "live" properties, we may want to  
>> take some inspiration from the microformats and schema.org  
>> communities in terms of the social aspects of how to enable open  
>> contribution while still maintaining a coherent specification for  
>> implementers.
>> I hope this helps,
>> Colin
>> ---
>> 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