[Accessforall] [SP2] Conditional preferences

Gregg Vanderheiden gv at trace.wisc.edu
Mon Aug 6 19:32:28 UTC 2012

interesting thoughts.
I'm trying to figure out how to make them into actionable items. I'm not sure I know how to do that quite yet. but I do think that we could put needs in the registry as well as preferences if and when we figure out exactly what they would look like.

Do you have anything in particular that you think we should do right now Andy with regard to this?

Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison

Co-Director, Raising the Floor - International
and the Global Public Inclusive Infrastructure Project
http://Raisingthefloor.org   ---   http://GPII.net

On Aug 6, 2012, at 2:18 PM, Andy Heath <andyheath at axelrod.plus.com> wrote:

> 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
> Cheers
> andy
> -- 
> __________________
> Andy Heath
> http://axelafa.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120806/67bbd350/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/67bbd350/attachment-0001.bin>

More information about the Accessforall mailing list