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

Liddy Nevile liddy at sunriseresearch.org
Thu Apr 5 07:56:06 UTC 2012

mmm...comments below.
On 05/04/2012, at 12:18 PM, Gregg Vanderheiden wrote:

> 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
No, no confusion here - DC uses the language 'term' for all things  
that some call 'elements' and that we are calling 'COMMON 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
I am worried that some of what is proposed is actually not going to  
lead to the best results. There is a creep towards database ideas, I  
think, and that tends to narrow the interoperability of what we might  
do and drive us towards having to have federations or whatever of  
databases. I come with a strong DC background, I admit, and also am  
keen to enable the re-use of our triples, hopefully so that what we do  
can lead to a light-weight broad-based network of .AccessForAll.

So, for example, the idea of conditions worries me because it breaks  
the idea of a simple metadata declaration so I try to re-think it  
until I see it as a declarative metadata term - I can't help it! I  
think why I refer to 'refinements' in this context is not clear to  
everyone, at all.

At least I am catching up on my sleep ready for next week!


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

More information about the Accessforall mailing list