[Accessforall] Alternative way of handling conditions (was Re: I presume our meetings ...)
liddy at sunriseresearch.org
Wed Apr 4 21:21:32 UTC 2012
Thanks for your response, Christophe. Attempted answers below.
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)?
As we do it in the DC world, the strings are the names of properties
that are identified by URIs. I guess in our terminology that means
> 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
I don't think this is right. 1800-0600 is a discrete period of time.
In DC we use time periods, eg, for subjects that occur in history, and
for other things. So I don't see that as a problem - it is defined to
be a period and there is a standard we use for declaring it.
Of course, I have been going on and on about refinements. This works
in DC metadata because of the structure built into the definition by
having strict rules about refinements etc. I suspect it would be very
helpful if the team were to learn more about the DC structure and how
it works. I keep hearing that refinements are not necessary, relevant,
etc - I cannot imagine how we will end up with good metadata if we
deny the structure of the terms - and, by the way, that is what an
ontology does so that is why I keep saying yes to a simple ontology.
> 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.
One of the rules of AccessForAll from the beginning has been that the
needs and prefs are not tied to a person, simply because we expect
them to want to change them, and they are therefore always able to be
changed. I do not know why this is a problem? The two time periods are
different metadata - and a third person will use yet another time
period, probably. Is it because you'd need another time period? That
should not cause a problem either. Both time periods are simply the
values for a term that identifies time or the term that specifies the
time period within it (as above) has values that are binary, etc -
there are ways of doing all these things, so long as the defns are in
> So when we integrate these conditions into the keys, the keys become
> unstable (i.e. they vary over time).
No, this is not correct - I am not sure what the 'keys' are but
nothing becomes unstable, as I understand it. Is this worry caused by
the database approach being used?
> 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
More information about the Accessforall