<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><b><font class="Apple-style-span" color="#006d08">GV: Comments below </font></b>
</div>
<br><div><div>On Feb 8, 2012, at 6:55 PM, Clark, Colin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Gottfried,<br><br>Here are some ideas that I have been contemplating since yesterday's meeting...<br><br>On 2012-01-31, at 3:07 PM, Gottfried Zimmermann (List) wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre">     </span>• A user profile consists of property-value pairs in a flat structure.<br></blockquote><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre">    </span>• Should not have complex structures - we need simple structures that could be combined to express complex things<br></blockquote><br>Can you elaborate a bit more on why you think that user profiles must be a flat structure?<br><br>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.<br><br>Were you thinking of this differently?<br></div></blockquote><div><br></div><div><b><font class="Apple-style-span" color="#006d08">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.</font></b></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>ALso there are many ways to build a hierarchy.</b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>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. </b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>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. </b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>Again - there can even be different TAG sets - reflecting different models of the world.</b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>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.</b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>So I would suggest</b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>1) we use flat set of </b></font></div><div><font class="Apple-style-span" color="#006d08"><b>2) we support that ability to associate any set of TAGs </b></font></div><div><font class="Apple-style-span" color="#006d08"><b><span class="Apple-tab-span" style="white-space:pre">  </span>- 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 )</b></font></div><div><font class="Apple-style-span" color="#006d08"><b>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. </b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><br></div><br><blockquote type="cite"><div><br><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre">    </span>• Keys are URIs, values are of any type that can be stored as a string.<br></blockquote><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre">        </span>• The definition of a key consists of its URI, and its type and value space (e.g. enumerated values, integer).  (See <a href="http://myurc.org/TR/res-prop-vocab1.0/">http://myurc.org/TR/res-prop-vocab1.0/</a> as an example.)<br></blockquote><br>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?<br><br>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. <br><br>However, I have two reservations about the idea of using a URI for key names in our specification:<br></div></blockquote>\<b><font class="Apple-style-span" color="#006d08">GV:  I share your concern.</font></b><br><blockquote type="cite"><div><br>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.<br></div></blockquote><div><br></div><b><font class="Apple-style-span" color="#006d08">GV:  what is your alternative that would provide guaranteed unique?  </font></b><br><blockquote type="cite"><div><br>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" (<a href="http://en.wikipedia.org/wiki/Don%27t_repeat_yourself">http://en.wikipedia.org/wiki/Don%27t_repeat_yourself</a>) is a very useful principle we can apply to our specification.<br></div></blockquote><div><br></div><b><font class="Apple-style-span" color="#006d08">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?   </font></b></div><div><font class="Apple-style-span" color="#006d08"><b>(won't we send as compressed - and this is what the compression routine will do automatically )</b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font><blockquote type="cite"><div><br>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 (<a href="http://www.json.org/fatfree.html">http://www.json.org/fatfree.html</a>) because it's simple, but this should work in any representation.<br></div></blockquote><div><br></div><b><font class="Apple-style-span" color="#006d08">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?  </font></b></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font><blockquote type="cite"><div><br>For codified, fully-standardized preferences, we can omit a namespace:<br><br>{<br>    screenReader: {<br>        usage: "required",<br>        speechRate: 80,<br>        pitch: 0.6,<br>        volume: 0.4<br>    }<br>}<br><br>A community extension (this is a pretty contrived example, but hopefully you get the point):<br><br>{<br>    screenReader: {<br>        usage: "required",<br>        speechRate: 80,<br>        pitch: 0.6,<br>        volume: 0.4<br>    },<br>    extension: {<br>        namespace: "<a href="http://www.iata.org/airplanePreferences">http://www.iata.org/airplanePreferences</a>"<br>        name: "Airline booking preferences",<br>        fields: {<br><span class="Apple-tab-span" style="white-space:pre">    </span><span class="Apple-tab-span" style="white-space:pre">    </span>seat: "aisle",<br>                meal: "vegetarian"<br>        }<br>    }<br>}<br><br>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.<br><br><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>• Both core properties and live properties are stored in a registry database.<br></blockquote><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre">  </span>• The registry database is hosted by Raising the Floor.<br></blockquote><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre">        </span>• A Web-based interface provides access to the registry for the public.<br></blockquote><br>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 <a href="http://schema.org">schema.org</a> communities in terms of the social aspects of how to enable open contribution while still maintaining a coherent specification for implementers.<br><br>I hope this helps,<br><br>Colin<br><br>---<br>Colin Clark<br>Lead Software Architect,<br>Inclusive Design Research Centre, OCAD University<br><a href="http://inclusivedesign.ca">http://inclusivedesign.ca</a><br><br>_______________________________________________<br>Accessforall mailing list<br>Accessforall@fluidproject.org<br>http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall<br></div></blockquote></div><br></body></html>