[Accessforall] [SP2] Conditional preferences

Andy Heath andyheath at axelrod.plus.com
Mon Aug 6 20:32:39 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.

Could do. I'm unsure whether that would work and may not be necessary (yet?)

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

Well as anything moves forward in those places I'll share it with this 
group and vice versa. Nothing happens in Europe in August.  Ideas that 
operate across standards bodies are not unproblematic.  What I perceive 
in different standards bodies is they all want to do this problem, but 
GPII will get there first so my approach is to encourage harmonisation 
with GPII and not the other way around.  I do agree
the ideal way to do it is to start at needs not preferences. By starting
at needs one can solve some problems without the solution being
ICT at all.

Meanwhile, noting that this is a much newer idea than preferences (the 
technical implementation and efficacy of which have been explored much 
more) I reckon there is a need for a time of experimentation.  I'm 
trying to figure out how to do that technically - I reckon we need, 
within the "set of preferences" format a way to aggregate (and thus 
label) particular combinations of preferences and particular 
combinations of conditions. One of these gives a way to label a context 
(which Colin seemed to be asking for) and one gives us a way to
express a need but what the contribution to each of preferences and 
conditions is is a little fuzzy and I haven't yet come up with a good
way to do that - it might be necessary to mix references to prferences 
*and* conditions.  I feel certain it requires extra definitions within
preference sets which don't interfere at all with the current structure 
and which might be ignored by some implementations and used by others.

I haven't looked at the way the proposed solutions registry operates and 
what kind of data is in it yet - sounds to me like an idea that "needs 
needs".

axelrod:Andy
>
> /Gregg/
> --------------------------------------------------------
> 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
> <mailto: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>
>>> <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 <mailto:Accessforall at fluidproject.org>
>>> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall
>>>
>>
>>
>>
>> Cheers
>>
>> andy
>> --
>> __________________
>> Andy Heath
>> http://axelafa.com
>>
>



Cheers

andy
-- 
__________________
Andy Heath
http://axelafa.com



More information about the Accessforall mailing list