- From: Jim Hendler <hendler@cs.rpi.edu>
- Date: Tue, 30 Oct 2007 11:55:32 -0400
- To: Jeremy Carroll <jjc@hpl.hp.com>
- 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>
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. -JH 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