[Accessforall] Alternative way of handling conditions

Liddy Nevile liddy at sunriseresearch.org
Thu Apr 5 22:10:40 UTC 2012

Comments here now - thanks for explanations.

Here are some that could help as well.

1. One of the principles for good metadata is that metadata is also  
data etc so there is a notion of 'first classness'. Everything in DC  
that has a value is a 'term' with a domain and a range - that is also  
the principle for the Semantic Web and 'linked data'. Whatever we call  
particular terms, as I understand them, they should have a generic  
term, IMHO, for talking about them all. DC then has a class called  
'core terms' but this is tradition and in fact, there are not 15 but  
more like 18 but nobody says this.

DCMI has lots more terms that are shared, or common. These terms are  
developed in sets that DCMI calls 'application profiles' This, IMHO,  
is not a good name but it is now traditional and to stay. All new  
terms in APs are DC conformant.

DCMI has a namespace or two in which it publishes terms. This is  
simply a couple of pages somewhere on the web to which metadata  
systems refer for definitions etc of terms. People making APs also  
usually publish them openly if they have worked with others to develop  
them and want to share them. There is a DC registry where these have  
been published to date but now DCMI is recommending using the even  
more open schema.org registry. One issue is to publish the schema in a  
form that can easily be ingested by others for their systems so there  
is also work to say how to publish schemas (APs in DCMI language).  
These schemas are usually just a short page of RDF/XML or something  

I am a little concerned that we are building a database of terms (all  
our metadata goodies). I think we would be ell served if we could  
share with others so we can use their metadata and share ours. I think  
we'd do this best with a namespace and a registry where people could  
see what we have and add theirs if they find they need more than we  
have and so work with specialists in their domain to make more 'terms'.

2. I repeat my suggestion that to get the terms that we need right, it  
is helpful to use CMAPS, or an equivalent, so we can immediately see  
what we have, the domain and range of each term, and from there, it  
would be really easy to get CMAPS to print out what we are doing, to  
develop the mirror image with the resource/service as the domain, etc.  
I would like to see the list of things that we are going to work with  
- is that somewhere, please?

BTW, is a face-to-face meeting planned for this group? Perhaps I am  
not part of the relevant group but I am very interested and certainly  
keen to be sure we get the new 24751 as good as possible.


On 06/04/2012, at 3:46 AM, Gregg Vanderheiden wrote:

> 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/ 
> I am not sure you are right here.  Maybe for the COMMON  preference  
> 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

More information about the Accessforall mailing list