[Accessforall] Alternative way of handling conditions (was Re: I presume our meetings ...)

Gregg Vanderheiden gv at trace.wisc.edu
Thu Apr 5 02:18:07 UTC 2012

I think there is some confusion or crossed messages in our discussion..

The database (REGISTRY) does not have what one would think of as DC terms

Rather the Registry contains COMMON TERMS/ELEMENTS/ATOMS that one would would think of as components of DC Terms

The COMMON TERMS/ELEMENTS/ATOMS take two forms.    NeedsAndPreferences  and   Conditions     

In DC you usually combine the N&P TERMS/ELEMENTS/ATOMS  and a set of Condition TERMS/ELEMENTS/ATOMS into one string that makes up a DC term

So no one is saying that "refinements" are not needed or not important.  Rather they are just saying that instead of a basic N&P  DC term and then a large number of refinements -- the suggested approach is to have a COMMON N&P TERM be used in combination with varying numbers and combinations of  COMMON 'CONDITION"  TERMS   to make up a  "USER PREFERENCE"  as it might be stored in the a User N&Preference Profile.

This is more in keeping with the way the manufacturers are storing their settings.  

What we are doing now is just gathering all the Common Term / Atoms/ Components that would make up a User Preference.  We will then have a  better ideas what we are doing or should do.   Several ways for storing the preferences (several forms) have been proposed and ALL of them can be use IN A SINGLE User record with the structure we are proposing/ building.  As long as each format follows rules, they should be able to be translated from one form to another.    So we can proceed without burning any bridges or having to make any irreversible decisions.  

I hope this is clearer -- but some examples and the full set of data will be helpful here.  And we should have them soon from all that we have collected. 

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 Apr 4, 2012, at 5:01 PM, Liddy Nevile wrote:

> two after-thoughts!
> I would advise against defining terms so that the range is just binary - because then there is not a good sentence and also because that value cannot then be treated as data - it's a literal which is not good long-term
> and
> it would also be possible to define two terms:
> time-before-1800
> and time-after-1800
> or, more specifically, time-before and time after with the range being ISO times... and the same thing for dates etc....
> Liddy
> On 05/04/2012, at 12:35 AM, Christophe Strobbe wrote:
>> Dear Liddy,
>> In your proposal, are the strings "language", "notEnglish-TV-format", "subtitle-fontsize-1800-0600", "volume-0900-1700" the keys or names (modelled as URLs in the other parts of the scenario)?
>> Time (when expressed as e.g. 1800-0600) and location (when expressed as GPS co-ordinates) are not discrete but continuous values, so when you integrate them into the keys, the keys are no longer discrete values. Also, the conditions can change, for example, when in our scenario Martha decides that she wants the xxlarge subtitle fontsize between 1900-0800 instead of 1800-0600. So when we integrate these conditions into the keys, the keys become unstable (i.e. they vary over time). Is this desirable? If yes, why?
>> If I misunderstood what you meant, please let me know.
>> Best regards,
>> Christophe
>> From: Liddy Nevile <liddy at sunriseresearch.org>
>> To: "Accessforall at fluidproject. org" <Accessforall at fluidproject.org>
>> Sent: Wednesday, 4 April 2012, 0:07
>> Subject: Re: [Accessforall] I presume our meetings are now permanently moved to 13:00 UTC
>> I have added what I think is an alternative way of handling the 'conditionals' to the page where Christophe Strobbe has the defns...namely http://wiki.fluidproject.org/display/ISO24751/Scenario+with+Conditional+Items+in+A+User+Profile
>> Liddy
>> _______________________________________________
>> Accessforall mailing list
>> Accessforall at fluidproject.org
>> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120404/4d7c9431/attachment-0001.html>

More information about the Accessforall mailing list