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

Andy Heath 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 
as records).

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
 >> 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?

AKH: A solution might be "handle" systems with registered terms having 
associated URL's
 >> 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'
> thanks....
> Liddy
> On 09/02/2012, at 6:24 PM, Gregg Vanderheiden wrote:
>> On Feb 9, 2012, at 12:39 AM, Liddy Nevile wrote:
>>> Gregg
>>> 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?
>>> Liddy
>> 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
>> Speech-Speed:<Value>
>> 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.
>> helpful?
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall


Andy Heath

More information about the Accessforall mailing list