- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Tue, 23 Oct 2007 12:08:19 +0100
- To: Ian Horrocks <Ian.Horrocks@comlab.ox.ac.uk>
- CC: public-owl-wg@w3.org
Ian Horrocks wrote: > The motivation for properties such as subObjectPropertyOf is not related > to punning. The idea is to facilitate parsing/species validation by > enforcing strong typing. For example, it is illegal in OWL DL for a > datatype property to be a subProperty of an object property, but when > parsing a <P subPropertyOf S> triple, the types of P and S may not be > known. As a result, not only will a decision on the species of the > ontology need to be postponed, but it becomes dependent on a > (relatively) complex and non-local condition, i.e., that P and S are > either both datatype properties or both object properties. > > Ian > Thanks. Species parsing/validation is hard, but a solved problem - which a handful of people need to master. Adding to the vocabulary that any OWL user needs to understand is a significant burden on the whole community. Each and every additional vocab term has a cost; and this design choice in OWL 1.1 seems to add several vocab terms, principally to reduce the cost to implementors. Is this a good trade-off? This is made worse, since OWL 1.1 is a 'small' change on OWL 1.0, which has chosen generally not to make such distinctions. To me, adding QCRs and sub property chains feel like appropriate new features for a minor version change. Rethinking the typing system feels like a major version change, with a possible loss of backward compatibility. Having subObjectPropertyOf subDataPropertyOf and subPropertyOf feels like the worst of design by committee, where we have two competing designs which we have failed to choose between. As is, the OWL 1.0 design is a given, and new features should be motivated by user needs that cannot be addressed in OWL 1.0 - rather than implementor ease. Jeremy
Received on Tuesday, 23 October 2007 11:08:46 UTC