[Accessforall] [SP2] Conditional preferences
andyheath at axelrod.plus.com
Thu Aug 2 05:40:07 UTC 2012
Sorry this is long - there is a technical argument in the middle.
Well yes. Thanks for the link - I had already read it, which is why I
joined the architecture list (but I may not have so thanks).
Architecture matters. The devil can be in the detail here.
I agree with your arguments below, particularly that more research
is necessary with preference sets before their structure is set in stone
and that there is a need to interoperate with systems using all kinds
of representational structures and get what we can from them/with them
and matching work with heterogeneous structures is good and the way to
go (though I still think we need to make the gpii solution as flat as
possible while allowing for not-flat in matching).
However, my point was actually a very much smaller one. My point
isn't that flatter is hard - I do think flatter is better and easier
to work with and I like the approach we have so far. My point is
not that there are things that are difficult with flat structure but
that some things are not possible in principle. This is similar to
data normalisation with databases - one ends up with the simplest
structure possible but no simpler (Albert again ;-) ). One doesn't
end up with just one flat table. There are real data dependencies
that cannot be normalised away. The IMS
accessModeRequired is one of these. There is simply no way
to express "for this modality I prefer that modality" without
expressing a relationship between modalities - either directly
or by using structure to group two fields together.
To me these are all aspects of one problem and part of the solution
is the expression of that dependency in a preference. We can play
around with whether that's in the registry, in ontologies (which is
another word for Metadata in many ways) - but we *cannot* solve the
problem of expressing "for this I want that" without a relationship
or structure. Its the same issue as that which leads us to group
any entities together. We have to have grouping or relationships
(which are separated grouping - tell that to my ex-wife ;-) joke).
What I'm trying to do is to say "we need grouping or relationship
in order to use the IMS AfA 3.0 stuff with GPII - what should
be the best practice on where to put it" ? At the moment my view
is we put it in the preference sets and my preferred way to do
this is by allowing values of a preference to be a structure - its
still necessary to aim for "as simple and flat as possible" but
not all structure can be dispensed with.
I think there are other cases where there is real data dependency
hiding in 24751 - adaptationDetail is one of them (the detail is
often closely linked with the adaptationKind and difficult to
"normalise out" - I may have remembered the field names wrongly).
I note that we are re-inventing wheels here. I don't agree with Liddy's
argument to do this job with the (non-implemented) Metadata world
because that has its own problems (one of which is its often too far
removed from implementation - and all that stuff about
sentences and words from Gregg, with which I agree).
But there are results here that have been
"discovered" over a long period and I think I observe GPII
discovering them all over again. The history of this thing
in the Metadata world is that we tried over and over to tackle
this data dependency issue and met resistance every time.
People working on Metadata always insisted on the principle
that Metadata was always "about one thing" and not about
relating different things. In those Metadata schemes where
there was any element that could be used to model relationships
to other entities (IEEE LOM has one but I forget what its called)
it proved pretty impossible to find any serious usage of it or
convince people that we weren't talking about one entity but
about related entities.
We tried to write our own and hit resistance every time.
We knew all along that this couldn't be done without expressing
relations or structures but the Metadata world wouldn't accept it
because all their practices were about Metadata about *one* isolated
entity independent from all the others. That is qualitatively
different from what is needed here.
A main principle in all of the Access for All work that I've been
involved with has been "for this I need that". Is that the
right principle ? If it is then if we bury it and hide it and
force people and systems to work around it then I question whether
we will be moving the goalposts as far as the stated intentions
of gpii are. Traditional approaches bury that principle and we
end up arguing in each area separately but the same argument - so we
have the argument about captions, then we have the same argument about
audioDescriptions, then about document format X. Its the same argument
all the time and we are allowing that to be hidden behind the
technological details. I believe we need to be able to explicity model
"I need this for that". Currently I can't see that in the model we
have. My proposal is we allow it in preference sets but not in
the registry (which seems to be following "good Metadata principles").
In my way of thinking if we ignore this then we may be catering more
to the producers and less the consumers by accepting too much the way
things have been done so far ?
Am I being naive here (I am often accused of such) ? Is this more change
than gpii is setting out to achieve ? Is this just about
tinkering around the edges ? I think and hope not.
> Awesome, I think we are in serious agreement, and this conversation
> might lead to some fruitful insights for our various
> As you say, a flat structure brings with it some pretty substantial
> problems when creating real implementations. Structure and
> relationship is extremely useful. Part of the problem with dictating
> a single, standard hierarchy is that different structures or
> ontologies are often needed for different situations or
> implementation problems. We also need tools to be able to integrate
> with systems that don't conform to the standards, even if we'd
> prefer they did.
> You might be interested in reading the slides from Antranig's recent
> presentation on Matchmakers to see how a hierarchy or containment
> model has enabled us to start implementing some pretty powerful and
> elegant approaches to matching user needs with solutions using a
> CSS-like system of specificity:
> My first impression of how to solve these issues is to create a
> system that embraces these multiple views of a preferences document,
> which will be optimized for particular implementation strategies or
> "world views" about user preferences. But there's a lot more to
> consider here still.
> I hope this helps,
> On 2012-08-01, at 2:09 PM, Andy Heath wrote:
>> Hi Colin,
>> Yes I realised this. My reason for flagging it was because I was
>> hearing from a few people that it was all solved and working. In
>> fact the problems of doing it with a flat structure are less
>> trivial than people seem to be imagining. See for example my
>> posts about preferences which have relations between terms in them
>> - particularly my post today with the subject "What is a term and
>> what is a value" which proposes my preferred solution to that
>> issue and which would work well with the way we are doing it in
>> It is unfortunately a fact that not everything one would want to
>> do can be done without either expressing a relationship or some
>> structure. I'd very much appreciate your thoughts on this in
>> response to those mails. I fear that without a solution to how to
>> express related terms things will be more limited than they need
>> be. The existing 24751 does have a solution for that - it does it
>> with container-based structure (i.e. records (or json objects)).
>> Structure or relationship must go somewhere - the only question is
>> Have a happy day :-).
>>> Hey Andy,
>>> On 2012-07-31, at 3:41 AM, Andy Heath wrote:
>>>> What I do see in looking around cloud4all material is many
>>>> instances of json structures that are not flat at all - they
>>>> may follow a style similar to the existing 24751. I see these
>>>> being used as an argument that gpii has been implemented
>>>> successfully. I don't want to be controversial or denigrate
>>>> anyone's work - I'm thrilled that something is working, but
>>>> without agreement on these fundamental data formats and their
>>>> use in implementation I'm unsure how what's been implemented
>>>> is different in kind from Web4all or any other implementation
>>>> of 24751.
>>>> Hopefully we are moving towards agreement on these "forms of
>>> I hope I can provide some background information on our choices
>>> so far in terms of JSON structures.
>>> We've been developing the GPII/Cloud4all architecture for a
>>> number of months now. When we started, very little consensus had
>>> yet been formed regarding a new structure for ISO 24751. This
>>> working group was still in the brainstorming phase. Similarly,
>>> the IMS 3 version of AccessForAll was still in flux and did not
>>> include any of the relevant preferences for assistive technology
>>> from the old Display and Control branches, so we couldn't use
>>> it, either.
>>> But to get something working, we had to use something stable and
>>> documented, even if we knew it was going to change in the
>>> future. As a result, many of the example preferences documents in
>>> the system currently use the released version of ISO 24751. When
>>> the new structure for 24751 stabilizes to the point where it can
>>> be implemented (I think we're very close), we'll be updating
>>> these preferences profiles accordingly.
>>> But we should also keep in mind our overall architectural
>>> approach: ISO 24751 and the flat registry will provide us with a
>>> shared, standard document structure for preferences. In
>>> addition, the Cloud4all preferences server will also be capable
>>> of producing transformations or "views" of a user's preferences
>>> in different structures, perhaps taking into account ontologies
>>> or different structures. This way, we get the benefits of a
>>> standard, interoperable structure while being able to easily
>>> produce alternative representations that are optimized for
>>> particular implementations or use cases.
>>> --- Colin Clark Lead Software Architect, Inclusive Design
>>> Research Centre, OCAD University http://inclusivedesign.ca
>> andy -- __________________ Andy Heath http://axelafa.com
>> _______________________________________________ Accessforall
>> mailing list Accessforall at fluidproject.org
> --- Colin Clark Lead Software Architect, Inclusive Design Research
> Centre, OCAD University http://inclusivedesign.ca
More information about the Accessforall