[Accessforall] [SP2] Conditional preferences

Antranig Basman antranig.basman at colorado.edu
Mon Aug 6 10:12:37 UTC 2012


On 05/08/2012 23:13, Gregg Vanderheiden wrote:
> *GV: comments below*
>
> *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. *

I think that even this condition could be seen as a proxy under some circumstances. One of the clearest ones 
being "Turn on captions if I cannot hear" - it is unlikely that the real user will have a personal model of 
db spl although this might be established for them by a helper. But given this particular proxy, there may 
be other implementations under other circumstances, such as it being nighttime and it not being practical to 
turn up the speaker volume to a sufficient level that the user could hear, even if there were no background 
noise, for fear of disturbing the neighbours, etc.

> *
> *
>>
>> 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? *

Yes, in general... I would tend to consider the suffix "TERM" is implicit in anything held in our 
registries, since we would naturally talk about these in terms of our capacity for reference rather than 
what they (the registries) supply. We might say "CONTEXT VALUE TERMS" or "OPERATOR TERMS" similarly....

> *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?**

No, it is fine. I didn't mean to imply that these things were in any sense interchangeable, but merely that 
we could treat them using the same infrastructure for handling references and resolving references onto 
implementations.


>> 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 think that is a great position for us to be in, since it gives real body to the expectations we might get 
by gathering real data on what our users want in practice. If we were already clear on what the implications 
were, we might be tempted to do this as a mere academic exercise :)

>> I hope this is any more clear,
>> Thanks,
>> Antranig
>



More information about the Accessforall mailing list