[Accessforall] Dependency between preferences

Andy Heath andyheath at axelrod.plus.com
Thu Jul 26 17:17:25 UTC 2012


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



More information about the Accessforall mailing list