[Accessforall] [SP2] Conditional preferences

Gregg Vanderheiden gv at trace.wisc.edu
Mon Aug 6 05:13:54 UTC 2012


GV: comments below

gregg 

On Aug 5, 2012, at 11:59 PM, Antranig Basman <antranig.basman at colorado.edu> wrote:

> 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.

GV:  I agree.   the time based one is probably not the best example.  A better one might be  "if background volume is > x db spl " (e.g. turn on captions).  This one would not be a proxy for something else. 

> 
> 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 >= '18:00'".
> 
> 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

GV:  I presume you mean CONTEXT TERMS    (the values would come in realtime). 

> - and for the purposes of simplicity, I suggest that we make no distinction in our registry between storage of operators and values

GV:  do you mean  CONTEXT TERMS and OPERATOR TERMS? 

GV:  I'm not sure I follow.   They would have some things in common (perhaps a name and definition etc)  but I don't see operators as having value ranges.  They would also have different roles. I can see that context terms and preference terms would be the same.. We have already established that they can be used in place of each other. But operators seem to be quite different. 

> - 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.

GV:  I can see a preference showing up as a context but I can't see a preference or a context turning up in the role of an operator nor vice versa.

GV:  can you say something more about what you mean here? Am I misunderstanding?



> 
> 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.

GV:  now you have lost me.
> 
> 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.

GV:  I agree with this although I am not sure exactly what the implications are.
> 
> I hope this is any more clear,
> Thanks,
> Antranig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120806/dae4ced0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7318 bytes
Desc: not available
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120806/dae4ced0/attachment-0001.bin>


More information about the Accessforall mailing list