[Accessforall] [SP2] Conditional preferences

Antranig Basman antranig.basman at colorado.edu
Mon Aug 6 04:59:35 UTC 2012

On 03/08/2012 15:48, Gregg Vanderheiden wrote:
> On Aug 3, 2012, at 4:00 PM, "Clark, Colin" <cclark at ocadu.ca <mailto:cclark at ocadu.ca>> wrote:
>> As a next step, I'm wondering if anyone would like to explore designs for an extensible, registry-based
>> representation for conditional preferences? I know Antranig has already done some sketching in this
>> regard, and some of the work we've done for Model Transformation in the core architecture might also serve
>> as a precedent for this kind of an approach.
>> Colin
> Can you say more about what you mean here exactly?

Hi Gregg - here are some further notes, regarding the potential real meaning (or at least, more practical 
meaning) of expressions that we saw in the first implementation sketch such as "localtime >= '18:00' && 
localtime < '22:00'. There is some discussion is going on in the other thread about "tidying up the 
deckchairs" of a hypothetical expression language, but I think we need to make a big investment in 
understanding up front what such a design might mean for our users.

I think these kinds of expressions expose the fact that this sketch is at the same time "doing too much" and 
"doing too little". The space of operators that we have designed into the system will almost immediately be 
found inadequate for the first real use cases we run into. For example, the user who expresses a time-based 
preference is probably using this as a proxy for some other condition - for example, it may be that he/she 
is particularly tired in the evenings, or alternatively (either completely separately, or else concurrently) 
finds it hard to read in the evenings due to low light levels. It is these true, underlying semantic 
preferences which the user will be aiming for, and could be identified with a "community of common interest" 
depending on what the real underlying semantic is.

In one case, for example, the "true semantic" might be better served by a predicate evaluating "is it more 
than 30 minutes after sunset at my current location". In another case, the "true semantic" might be "is the 
level of illumination at my current location greater than 500 lux". It's worth noting that even with these 
kinds of expressions, we may still find ourselves some distance from the user's own vocabulary - but we may 
at least find ourselves closer to modelling their real NEED than with expressions such as "localtime >= 

Some of this semantic requirement could be taken up by allowing free extensions to the "ontology of values" 
- for example, one could imagine new values arising such as "http://example.com/context/timeAfterSunset" 
"http://example.com/context/localIllumination" etc., but even the example above shows that simple extensions 
to the domain of values will not be sufficient. Our attempt to compare a time value with a string value 
"18:00" shows that in general our early, fixed repertoire of operators is not going to be sufficient.

To meet the requirements of authoring, as well as the requirements of adequate modelling of user needs, I 
propose that we require a registry of OPERATORS in conjunction with our registry of CONTEXT VALUES - and for 
the purposes of simplicity, I suggest that we make no distinction in our registry between storage of 
operators and values - they are strings as encoded above, which may be looked up into an implementation held 
in JavaScript code registered into the system which is capable of computing their value in a particular context.

This idea is already implicit in the registry of values held above - for example, 
'http://example.com/context/localtime" cannot be held to have meaning in the absence of the ability to 
locate an implementation computing its value in a particular context. Operators in this view then need be no 
different - "context values" become grandfathered in as cases of operators which take no arguments.

As an overall aim, I think one of our overriding goals is to design a system which creates a terrain where 
communities of interest may be able to find each other. Simply proceeding from the engineering standpoint of 
"building a system we know how to build" is most likely simply to create a maze in which they can get lost. 
Therefore we should design nothing without an eye to what its role might ultimately be in a 
community-structured product.

I hope this is any more clear,

More information about the Accessforall mailing list