[Accessforall] [SP2] Conditional preferences

Andy Heath andyheath at axelrod.plus.com
Mon Aug 6 19:18:04 UTC 2012

axelrod:andy - I haven't followed every twist and turn in this
thread so I'm guessing and filling in the gaps, possibly wrongly,
but what I'm seeing here is a debate about whether preferences
should only be described in low level terms or whether there should be 
some notion of needs (or something like that, that is at a higher level) 
in there somewhere.  Am I interpreting this discussion reasonably ?

Assuming I am, though noise level may not be the best example of the 
argument I shall put, I'd like to make the point that if one extends 
GPII to the boundaries of ICT and just a little beyond then I do think
it *is* very important to start with needs (and the argument about 
getting lost in low level detail below - not sure who made that argument 
- holds imho.
Whether such a correspondence should be made in the profile
or external to it I'm not sure - but at some level we are talking about
human needs that transcend technologies, particularly they transcend
changes in technologies - much like the POUR of WCAG but with more
detail - there may be different implementation technologies (shall
we call them techniques ?) in different domains and those might change 
as technologies change - but needs like "its noisy and I need to 
perceive it" do not vary from person to person (the need is the
same, whether someone has it a particular time or not changes).

I have encountered talk in other "standards" bodies (SWG-A, SC35 and 
BSI) of mapping needs to preferences - in particular there is a proposal
from BSI (the UK mirror organisation for international standards) to
do some work on this in SWG-A involving implementation and a
mapping from the SWG-A needs summary to techniques.  I am on the ad-hoc 
group that is doing that work but we didn't start yet. A vendor we all 
know is involved and I'm led to believe is supplying some real support. 
Maybe we can get one hymn sheet for us all to sing from :-).

Having low level preferences and understanding those in terms of needs
are not necessarily mutually exclusive.  One way might be to be able to
use terms for needs inside a profile as terms (which I think is what is
being discussed below) but as terms which are "composed" from technical
properties. - axelrod:andy
> On Aug 6, 2012, at 5:12 AM, Antranig Basman
> <antranig.basman at colorado.edu <mailto: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
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall


Andy Heath

More information about the Accessforall mailing list