[Accessforall] Use of terms that depend on other terms

Andy Heath andyheath at axelrod.plus.com
Tue Jul 31 15:22:23 UTC 2012


I said on the call I'd post some more discussion material
on this requesting views.  Sorry its a bit long.

Here is the bones of the problem. In IMS Access for All 3 we have
some terms that depend on others. For example I might express in
a preference that for "visual" material I want an "auditory" 
alternative.  Originally we modelled this as a triple, expressing
a relationship like this:

("visual", accessModeRequired, "auditory").

To bind this in languages that don't have direct expression of 
relationships we introduced structure - specifically in json XML-style 
(with some irrelevant detail removed) it looks like this:

  [
    {
       "accessModeRequired" : {
             "existingAccessMode" : "visual",
             "adaptationRequest" : "auditory"
             }
         }
  ]

Note that an instance might have more than one occurrence of this
property.
The fact that is json is irrelevant, the discussion is about its 
intrinsic structure.

The question on the table for me is how to put preferences like this
into GPII using what seems to be becoming the "standard" form.  There
are four obvious different ways that are possible (note: all of this 
discussion is expressed without using URL's for terms - but all of them 
would be URL's. in practice) :

1. Code the dependency within the term value.
For example, have a term in
the registry called "accessModeRequired" with a value that must come
from the vocabulary ["auditoryFORvisual", "textFORvisual". 
"tactileFORauditory" .... ]. Then then a GPII preference within a set
could be

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

Vocabs are going to get very big.

2. Use "condition" to express the dependency.
Assume the registry contains "visual" and "auditory" defined as constant 
terms/values. Then we have a registry term (or a term defined
outside the registry in some Metadata scheme) that we use like this


{ "property" : "accessModeRequired",
   "condition" : "visual",
   "value" : "auditory" }

This might need some function or other around "visual" to indicate the
use of the term reference in the condition here is to signify that it
expresses the modality that is to be adapted - since conditions will be 
used in many other ways this usage would need fishing out.  As I 
expressed in my earlier email this feels like misuse of "condition".
Gottfried expressed a similar perspective on it.

3. have the terms "visual" and "auditory" in the registry and then
express in an external Metadata scheme a property "accessModeRequired" 
that uses them and expresses the dependency - this is actually quite 
messy to do because one has to deal with multiple occurences  of this 
one preference (with different values but possibly for the same 
modality-to-be-adapted) in the same set of preferences and by separating 
the info into two parts that are not "held together"
as they are in a record it
becomes harder to deal with multiple occurrences (one has to know which 
one of the pair goes with which other of the pair - requires indexing).

4. have the term "visual" and "auditory" in the registry then also have 
the terms "accessModeRequiredExistingAccessMode" and 
"accessModeRequiredAdaptationRequest:, each of which taking a term from
the vocab ["visual", "auditory" ... ] as its value.  These could be 
within the registry or in an external scheme - that wouldn't matter. 
This seems to suffer from the same messiness as 3 because of the need to
keep the parts together.

There may be other permutations of mechanisms that form ways to do this.

My thinking is coming down to 1 or 2.  I think 3 and 4. suffer from 
messy hard aspects w.r.t. multiple records and mostly allow solutions 
where part of the solution is exterior to the preference set in some 
fashion and so they should be excluded. It *must* be possible to do this
entirely within GPII otherwise its crazy.  Of 1. or 2. though, I can see
advantages and disadvantages of either approach.  The difference is 
whether the dependency is expressed in the term (and therefore recorded 
as an entity in the registry - e.g. "auditoryFORvisual") and just used 
in a preference or expressed inside a preference set in the way that 
particular preference is coded. By the way - we have a lot more than 
just a few of these in AfA 3 - we also have an adaptationType and a 
mediaType that work the same way.

Actually I think this is a problem that will raise itself in unexpected 
places when other 24751 properties are coded in the gpii
registry because I've seen lots of very structured json
preferences around cloud4all implementation hangouts
(emails, wikis etc.) and in some cases those
structures will be "hiding" dependencies like this. AdaptationDetail
is one example.  We will imho need best practices and this might be
one.

Your views please - which is best 1 or 2 and why and do you agree with 
me that 3 and 4 are rubbish ?

Cheers

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



More information about the Accessforall mailing list