W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > May 2007

Re: [hcls] Harmonization of labels, descriptions and definitions

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Wed, 30 May 2007 11:24:06 +0100
Message-Id: <CE5ED511-BF3F-4C01-BC75-9D6AA4F551A3@cs.man.ac.uk>
Cc: William Bug <William.Bug@DrexelMed.edu>, public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>
To: Alan Ruttenberg <alanruttenberg@gmail.com>

On May 30, 2007, at 7:11 AM, Alan Ruttenberg wrote:

> I think there are two dimensions:
>
> 1) Allowing annotation properties to have subproperties so, e.g.  
> that skos:prefLabel and skos:altLabel can be subproperties of  
> rdfs:label.
> Mostly this is addressed by punning in 1.1 but there are still  
> annotation property leftovers like rdfs:label and rdfs:comment or  
> any other property where one doesn't want to make a commitment as  
> to whether they are datatype or object.

We at manchester have been discussing the annotation system for  
several months. Boris and Bernardo crystalized one strand of our  
thinking in an ISWC paper. It's like punning except 1) you project  
the entities into a separate domain, i.e., imagine that instead of  
one document which holds abox assertions about classes and properties  
as well as individuals, you have two, one for classes and properties  
and one for individuals and 2) you have another box for axoms. A  
language like SPARQL can seamlessly query across these documents, so  
all the system need to do is automatically keep em in synch. This  
makes mixed tbox and abox queries pretty straightforward as well.

Thus, you can reserve punning (or some other higher order features)  
in the "domain part" of the ontology for representing *domain* features.

(What started this whole line off was my concern about the  
indiscriminate mixing *annotation* modeling and domain (higher-order)  
modeling...you can get some very weird and hard to track down  
effects. While punning doesn't let you get "direct" entailments  
between levels, i.e., just because C is *equal* to B doesn't mean  
that C (as a class) is *equivalent* to D, as it would be in Hilog and  
OWL Full), you can get indirect ones, e.g., through fixing the size  
of the domain, or of a class.)

> 2) Some sort of easy tagging mechanism for labels - perhaps  
> something along the lines of the language tags. The case is that  
> one ontology is used by a variety of communities (proteomics, flow  
> cytometry, enzymology) each of which has preferred labels for some  
> of the terms, and it would be nice to have some global switch to  
> select which view you wanted to see.

So, you can do this in line or out of line. Out of line solutions  
include things like Fresnel which have a selector/view language which  
let you develop "informational" style sheets. There are several  
Fresnel viewers and toolkits out there (we were using it in JSpace).  
It also allows you to do some presentation, e.g., ordering. The plus  
side is that you don't have to touch the ontology itself. The  
downside is that the sheet can get out of synch with practice.

Inline can be done in an icky or non-icky manner. Icky would be to  
have distinct properties and duplicate common information, perhaps  
getting fall back behavior through property inheritance (I *said* it  
was icky!). Non icky would be, as you say, tags.

> btw, couldn't easily tell from the 1.1 spec whether one can add  
> annotations to labels (like this tag thing).

Only in an icky or semi-icky manner at the moment, I believe. The  
semi-icky would be to make a label individual with two properties,  
tag and value. Indeed, that would *have* to be the case in the RDF  
serialization, I think.

The functional syntax and XML syntax can easily be extended to add a  
tag "slot" to annotations (instead of having to nest it with a label  
object). I *suppose* in RDF you could try to overload the lang  
tag...oh...you could also make datatypes which had no other purpose  
but to be the tag.

Hope this helps.

Cheers,
Bijan.
Received on Wednesday, 30 May 2007 10:23:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:27 UTC