[Accessforall] Minutes of AccessForAll Meeting on 2012-01-31
andyheath at axelrod.plus.com
Thu Feb 9 13:47:04 UTC 2012
AKH: Goodness, what a lot of discussion embedded in deep threads - not
of value imho to address *all* the detail but some key points.
AKH: I love this concept painted by Gregg - the flat structure with
tags. What all the implications for implementations are I'm not sure.
It seems pretty easy to map what we did in AfA 3 to it (the prefs
anyway). Yes yes yes - containers and hierarchy are bad - though some
mechanisms on top of the prefs *will* build hierarchies (hopefully not
containers but ..). The points made about hierarchy and those about
containers are imho correct and I illustrated those same points with
examples in the critique of 24751 which is where we started with AfA 3 -
I *will* post this to the wiki at some point soon but I have to a) find
the docs again and b) edit out some proprietary material and c) the wiki
aint awake yet. There is also much material around the web about IEEE
LOM and what's wrong with it from that same perspective - hierarchy and
containers do not allow things to be in more than one place is the main
point - they *create* complexity by constrain where there was none.
Imposing order (sequence) is another (containers are usually implemented
AKH: Colin - I wouldn't put too much effort in studying AfA 3 yet unless
you are looking at the docs inside IMS - we made quite a few changes
since we made material available publicly, including compromises in the
model to meet implementation constraints. Watch this space.
AKH: Liddy - There seem to be similarities with the facets idea - is it
identical ? (probably not or the term facets would have a wider usage in
tag systems maybe ?).
AKH Comments edited into the following section pasted from another post
>> 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
>> 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?
AKH: A solution might be "handle" systems with registered terms having
>> 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 )
AKH: Doesn't it depend on just how broad the address space is - for
example is there are 10,000 namespaces that would be a problem - but if
say 30 namespaces evolve ? or 50 ? Someone makes a point about networks
over slow mobiles (limited bandwidth). I had the same thought about the
Cloud at all and certainly about Apple's use of SIRI for example (few
servers I admit). The solution often adopted to this seems to be proxy
networks of a few servers optimised for usage geographically - such as
Amazon and Google have for example -f ro major services that is the
likely approach and for smaller ones maybe the difficulty won't be hit.
Is bandwidth *really* going to be a problem ?
> ah-ha - I think I want to call those tags 'facets'
> On 09/02/2012, at 6:24 PM, Gregg Vanderheiden wrote:
>> On Feb 9, 2012, at 12:39 AM, Liddy Nevile wrote:
>>> 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?
>> Actually no.
>> we START with name-value pairs (as Gottfried suggested)
>> this is a FLAT listing of all the name:value pairs.
>> but each item in the list also can have TAGS associated with it.
>> For example
>> might have tags BLIND, SPEECH, COGNITIVE, RATE, SCREEN-READER
>> that would allow this (and other speech parameters) to show up in a
>> search for SPEECH or BLIND or COGNITIVE or any other "Group" that it
>> might be associated with.
>> This makes it easy for example to find all the preferences that relate
>> to SPEECH or SCREEN-READERS or COGNITIVE or BLIND and this parameter
>> would show up in each of those groups. but there would only ever be
>> one name-value pair.
>> NOTE that the TAGS are separate from(but associated with) the
>> Name-Value pairs. RtF could have a set of tags. HDM could have a
>> different set. ANother group may have a hierarchical set of tags that
>> would allow the Name:value pairs to be viewed hierarchically according
>> to someones model.
>> NONE of the TAG sets however need to be formal and anyone can use any
>> one of them. They do not define anything. they are just different ways
>> to of grouping and looking at or searching the long list of name-value
>> pairs to make it easier to work with them.
> Accessforall mailing list
> Accessforall at fluidproject.org
More information about the Accessforall