[Accessforall] [SP2] Conditional preferences

Gregg Vanderheiden gv at trace.wisc.edu
Mon Aug 6 18:21:23 UTC 2012



On Aug 6, 2012, at 5:12 AM, Antranig Basman <antranig.basman at colorado.edu> wrote:

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

GV2: You are thinking too detailed I think.  what I meant was -- if there is ANY noise - please turn on the captions.   ANy noise of course has to be defined so you just have an DB SPL level to trigger that.   I see what you mean by all of these triggers being a trigger for some condition in the user or their ability to use the product.    but many of those are not measurable and the user does not want to be queried or have to enter it -- so they set the proxy themselves in their preference. 

GV2: So how do you see this changing our system?   By suggesting new Operators? or Triggers? or ?? 
thx
 


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

GV2:  we use CONTEXT TERM as  the ID  and the value is the value.  that was my point.  if you say CONTEXT VALUE you are talking about an instance not a variable.     


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

GV2:  perfect.
I think you are absolutely correct.  We can just make a different type of term in the registry.

can you add a column to the chart at  http://wiki.gpii.net/index.php/REGISTRY   and check the fields it would use  - and add any new field you might need?

I put an empty column at the far right to make it easy for you  (there is a WYSIWYG option which makes it easy) 

in fact I just added a column and tried to fill it out.  please look and correct it. 


> 
> 
>>> 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 :)

GV2: I thought it was the other way around.   when you DON'T know the implications - it becomes an academic issue - one for study.    or maybe I misread that.  no matter. 

this is an interesting thought and might play into our next proposal 

> 
>>> 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/fa09c85c/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/fa09c85c/attachment-0001.bin>


More information about the Accessforall mailing list