[Accessforall] What is a term and what is a value

Andy Heath andyheath at axelrod.plus.com
Wed Aug 1 17:17:37 UTC 2012


This follows on from my emails about preferences that need
more than one term for their expression with dependency between the 
terms, such as "for visual modality I need auditory".

After discussion in IMS, and after I wrote a json schema to validate
instances and showed what the thing would actually look like, we (the 
IMS we) decided that coding the dependency in the term (for example
"auditoryFORvisual" would be a kludge (aside - is "kludge" a kludge? no 
matter). A consequence for systems of doing it that way is extremely 
long strings which may well knock over some implementations.

It is a fact that solving this is impossible without a dependency 
somewhere.  That means that somewhere, there must be either an entity
that references another entity in some relation or there must be 
structure.  Flat cannot do everything.  The question is where the
dependency or structure is best expressed.

I am coming down to the idea that the registry *must* be flat in that
each term must be independent from each other term and ideally no 
structure or relationship be coded inside the term (so terms like
"audioFORvisual" should be outlawed).  However, the preference sets
need not be flat. In fact it might be too early in the development of
preference sets to fix the form completely (we already encountered
a wish to go back to the drawing board for conditions) - it may take
some time and experimental research to get the right structure for 
preference sets.

However, if the dependency must be coded somewhere, and noting that 
structure is a way to code data dependency, several possibilities that 
are open occur to me:

1. Use "condition" in the manner I outlined in my earlier mail (this
doesn't feel right)

2. Introduce an extra field that can be used to express dependency (so 
as not to misuse "condition"

3. Allow values of a preference to be structured. There are lots of
ways to do this - we might allow a value to be a tuple for example,
say ("auditory", "visual") or a json object,
say { "accessMode" : "visual", "adaptationRequest" : "auditory" }.
Note that though the terms would be in the registry, this kind of
structure would not.  I like this solution and think it could be used
to solve many problems that are difficult without it just down the road.
Preference sets are not going to be flat - there will be a highly 
complex conditions structure at least for example.

Has anyone thought about vocabularies/enumerations ?

Cheers

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



More information about the Accessforall mailing list