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

Gregg Vanderheiden gv at trace.wisc.edu
Thu Feb 9 05:38:33 UTC 2012


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120208/b2561bef/attachment-0001.html>


More information about the Accessforall mailing list