- From: Michael Schneider <m_schnei@gmx.de>
- Date: Tue, 09 Jan 2007 22:21:28 +0100
- To: alanruttenberg@gmail.com
- CC: bernard.vatant@mondeca.com, der@hplb.hpl.hp.com, semantic-web@w3.org, timbl@w3.org, marc@geonames.org, public-owl-dev@w3.org
Alan Ruttenberg wrote: > OWL 1.1 is currently being discussed. It removes some of the > motivation for having annotation properties - using them to add > properties to classes in OWL DL. Upon review of the spec I see that > there is special syntax for rdfs:label and that it is defined as an > annotation property. I'm wondering whether it makes sense to instead > define it as a datatype property, which would remove the restriction > that it can't have subproperties. But when rdfs:label is a owl:DatatypeProperty, how will you then attach a label to a owl:Class in OWL/DL? I believe this is a frequent usecase in ontology design in order to assign human readable names to classes (which can, for instance, then be shown as a balloon in the ontology browser). But at least in current OWL/DL, attaching a datatype property to some class is not allowed. What I have found in OWL1.1 is this "punning" mechanism: When you have some class C, you can then also give this same name, "C", to some instance. So one could perhaps come to the conclusion, that one can just attach the datatype property to the /instance/ C, which is of course formally allowed in OWL/DL. But, as I understand punning correctly, there is no semantical connection between Class(C) and Individual(C) (see [1, §3.3]) - it just seems to be meant as a form of name "overloading". And this would /not/ solve the above problem! (It could instead easily lead to some hard to find errors: One might intend to add some property to a class, but, in fact, the property is added to an instance, which happens to have the same name.) > In the spec its use is (halfway) > constrained to be a datatype property because when specified via the > Label() construct its value must be a "constant". Another, more exotic use of rdfs:label, which comes to my mind, would be to label a resource with some /graphical object/ instead of a text label. Not, that I would argue for doing so, but people will perhaps come to this idea, and perhaps some people already did so. In this case, the label would better be an URL to the graphical resource instead of a text string. And then, a datatype property would not be the right thing, again. Michael [1] http://owl-workshop.man.ac.uk/acceptedLong/submission_11.pdf
Received on Tuesday, 9 January 2007 21:21:40 UTC