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

Gregg Vanderheiden gv at trace.wisc.edu
Thu Apr 5 17:46:36 UTC 2012


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 Apr 5, 2012, at 2:56 AM, Liddy Nevile wrote:

> 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/ELEMENTS/ATOMS'

I am not sure you are right here.  Maybe for the COMMON  preference TERMS/ELEMENTS/ATOMS' 
but there will also be   COMMON condition TERMS/ELEMENTS/ATOMS'    (and I think those are components in your refined DC terms.  no?

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

Well the approach we are using allows us to go both ways in the User Preference Profiles

again - the registry is like the dictionary of words that we use to create terms.   The terms can still be expressed in DC format if that is the desired format in the end.  


> 
> Liddy
> 
>> --------------------------------------------------------
>> 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/20120405/8c782e5e/attachment.html>


More information about the Accessforall mailing list