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

Clark, Colin cclark at ocadu.ca
Thu Feb 9 00:55:55 UTC 2012


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?

> 	• 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:

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.

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.

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.

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



More information about the Accessforall mailing list