[Accessforall] Dependency between preferences

Gottfried Zimmermann (List) zimmermann at accesstechnologiesgroup.com
Tue Jul 31 11:03:34 UTC 2012


Hi Andy,

my personal answer to your question is: 1.  

I don't like 2 because the condition seems to contains some kind of
matchmaker-specific (or inferred) information.

3 is a deviation from our flat model.

Thanks,
Gottfried

-----Ursprüngliche Nachricht-----
Von: accessforall-bounces at fluidproject.org
[mailto:accessforall-bounces at fluidproject.org] Im Auftrag von Andy Heath
Gesendet: Donnerstag, 26. Juli 2012 19:17
An: Accessforall at fluidproject.org
Betreff: [Accessforall] Dependency between preferences

Hi all,

I've just been building json validation schemas, some in
GPII-preference-style, for the IMS Access for All 3.0 public draft (which
will be public in a few days now) and I have a question in my head because
there are three (or more) ways to express preferences where there is a
dependency between two atomic "preference-things" 
(don't want to call them terms yet).

In AfA 3 we have preferences like this

"for 'visual' modality I request an 'auditory' alternative/adaptation".

Using the latest GPII representation for a preference but ommitting  the
http verbiage and just using the end points of the URL's as terms and
cutting a few corners we have the following ways a preference like this
could be expressed (with appropriate terms in the registry):

1.
{ "property" : "accessModeRequired",
   "condition" : "",
   "value" : "auditoryFORvisual" }

i.e. terms that in the real world are related in a preference, collapsed
into one term that expresses it all.

2.
{ "property" : "accessModeRequired",
   "condition" : "adaptation for visual",
   "value" : "auditory" }

In this version the condition essentially points to another term in the
registry (the "visual" term).  This is subtly different from saying another
preference must be present and it feels like shoe-horning something into
somewhere it wasn't designed for - yet "condition" can contain term
references - it must be able to, so all it needs is some functional way to
incorporate the meaning of this kind of reference to a term. It just feels
like a fiddle though.

3.
The third way is to have the terms "visual" and "auditory" in the 
registry as stand-alone terms and have some external "ontology"
or metadata scheme that uses these terms and introduces the
relationship between them in instances of preferences.
An example might be ISO MLR or IMS AfA might reference terms
like this but still put the Metadata mechanisms on top.

As I said, I just did a json schema for 1. to see how it played out.
AfA 3 is a small model - in its full (non-core) version there are ten
terms in the modality vocabulary and 11 in a vocab we call MediaType, 
which means the vocab for solution 1 for this particular preference
has 110 terms in - and its only a very small piece of the world. 
Admittedly they won't all be useful.

So the question for me is which is the mechanism of choice ?

If its 1. the job is done.
If its 2. - well it just doesn't feel right, it may be misuse of 
"condition" - but we could make it work.
If its 3. - well this is the basis of my argument in the 24751 
discussions that we could be getting on with starting a new part of the 
revised 24751 which does the needed metadata in MLR.

The serious points underlying this ? Flat is one thing, I agree with the 
reasons for having the registry flat. But in the real world data
isn't flat - there are structures and relationships (which may be the
same thing) and without relationships there is much that cannot be done.
Metadata is needed (on top of not built in to the registry)
to make this thing useful - very little can be done without it.
(I note that arguments around the structure of sets of preferences
are closely-related to arguments around metadata).

But right now, I just need to somehow get a decision on the best way
to go on this.

Cheers

andy
-- 
__________________
Andy Heath
http://axelafa.com

_______________________________________________
Accessforall mailing list
Accessforall at fluidproject.org
http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall



More information about the Accessforall mailing list