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

Liddy Nevile 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  
> values.
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  
a namespace..
> 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,
> 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

More information about the Accessforall mailing list