W3C home > Mailing lists > Public > public-owl-wg@w3.org > October 2007

Re: comments on RDF mapping

From: Jim Hendler <hendler@cs.rpi.edu>
Date: Tue, 30 Oct 2007 11:55:32 -0400
Message-Id: <B330A9CE-F673-49B6-B2E2-8C258DFC8A8D@cs.rpi.edu>
Cc: Alan Ruttenberg <alanruttenberg@gmail.com>, Boris Motik <boris.motik@comlab.ox.ac.uk>, public-owl-wg@w3.org, Alan Rector <rector@cs.man.ac.uk>
To: Jeremy Carroll <jjc@hpl.hp.com>

FWIW, I think annotations were one of the real contributions of the  
original OWL WG in a way that was somewhat unexpected.  For many  
years the workaround for many DL systems to handle the need for non- 
inherited classes was to create a special instance associated with  
each class, and to use that to store the specific properties related  
to the class - and of course the "reasoning" associated with this  
happened to some extent outside the reasoner -- i.e. the application  
knew how to use these.
  With the invention of annotations, suddenly there was a clean place  
to put this - for example, the National Cancer Institute's ontology  
uses annotations for things like unique reference numbers on various  
class names -- a non-semantic class that is still crucial for their  
applications (links the class names back to pubmed and such).  This  
has also been used in several cases I've seen to provide a link  
between class names and other URIs that wouldn't necessarily be  
inherited (or might necessarily not be inherited) - for example, one  
ontology I like is one someone in the UK did (sorry, I've lost the  
pointer) where they associated classes from some well-known  
ontologies  with flickr terms that corresponded - so Cyc:cat could be  
linked to flickr's photos of cats (this was done by hand, so where  
terms were unambiguous, the pictures could be used to show a novice  
which definition of the term was being used -- i.e. milont:tank could  
be linked to photos of M1s rather than fish).
  Anyway, this is a long way to say that I second the idea that we  
might want to revisit annotations w/respect to allowing a "minimal"  
semantics to them - so it woudln't break DL implementations, but  
would allow this feature to be more widely used by tools.

On Oct 30, 2007, at 10:27 AM, Jeremy Carroll wrote:

> Alan Ruttenberg wrote:
>> My understanding is that there is a requirement to be able to  
>> create properties attached to classes that have more inference  
>> support than is currently possible using annotation properties.  
>> For example, it is desirable that an "annotation property" for an  
>> editing time stamp should have a range that is xsd:date, or, for  
>> SKOS, we would like  to be create subproperties of rdfs:label.
>> Alan Rector articulated these cases initially, IIRC. I suspect  
>> they are recorded somewhere amongst  the OWLED stuff.
> If I have understood correctly, these requirements are about  
> annotation properties, in particular in the way they interact with  
> tools such as editors.
> It is clearly helpful for editors if they know what sort of values  
> an annotation property may have, and whether or not an annotation  
> property is intended as a label.
> For maximal interop with RDFS, using the RDFS methodology (i.e.  
> rdfs:range, and rdfs:label) is good.
> My understanding (or perhaps misunderstanding) is that there is no  
> theoretical problem with extending the annotation semantics to  
> include such parts of RDFS. I (mis)understand that it is more a  
> preference by the DL implementors, and/or editors of the semantics  
> to not give annotations any semantics at all.
> Note this use case seems to only be about punning annotation  
> properties with data properties.
> Jeremy

"If we knew what we were doing, it wouldn't be called research, would  
it?." - Albert Einstein

Prof James Hendler				http://www.cs.rpi.edu/~hendler
Tetherless World Constellation Chair
Computer Science Dept
Rensselaer Polytechnic Institute, Troy NY 12180
Received on Tuesday, 30 October 2007 15:59:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:59 UTC