[Accessforall] Alternative way of handling conditions (was Re: I presume our meetings ...)
liddy at sunriseresearch.org
Thu Apr 5 07:56:06 UTC 2012
On 05/04/2012, at 12:18 PM, Gregg Vanderheiden wrote:
> I think there is some confusion or crossed messages in our
> The database (REGISTRY) does not have what one would think of as DC
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.
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
>> it would also be possible to define two terms:
>> 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....
>> 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,
>>> 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
>>> Accessforall mailing list
>>> Accessforall at fluidproject.org
>> Accessforall mailing list
>> Accessforall at fluidproject.org
More information about the Accessforall