- From: Ian Horrocks <horrocks@cs.man.ac.uk>
- Date: Mon, 22 Jan 2001 21:54:15 +0000 (GMT)
- To: Jeff Heflin <heflin@cs.umd.edu>
- Cc: www-rdf-logic@w3.org
On January 22, Jeff Heflin writes: > Ian, > > There is one thing that bothers me about your proposal: the need to have > a set of restrictions for data types that mirrors those for classes > (i.e., the toDataType, hasDataType, hasDataTypeQ, hasDataValue and > onConcreteProperty properties mirror the existing DAML properties > toClass, hasClass, hasClassQ, hasValue, and onProperty). At any rate, > the proposal seems to imply that whenever we add a special semantic > "property" to the language we will have to create both ordinary and > concrete versions of it. This could get rather cumbersome as the DAML > language is expanded. Jeff, I don't particularly like it either, particularly as I have to do the work of extending daml+oil.daml! The trouble is caused by the liberality of the RDF syntax, in particular the fact that we can combine various restrictions in a single instance of Restriction. We therefore need the different names in order to clarify the semantics in cases such as: <daml:Restriction> <daml:onProperty rdf:resource="#hasParent"/> <daml:hasClassQ rdf:resource="#Person"/> <daml:maxCardinalityQ>1</daml:maxCardinality> </daml:Restriction> If I tried this without the Qs it would express three restrictions: a hasClass restriction, a simple cardinality restriction and a qualified cardinality restriction. Another problem is that given: <daml:Restriction> <daml:onProperty rdf:resource="#hasParent"/> <daml:toClass rdf:resource="#Person"/> <daml:onConcreteProperty rdf:resource="#age"/> <daml:hasDataType rdf:resource="#over17"/> </daml:Restriction> without the "Concrete" qualifiers, the toClass and hasDataType restrictions would apply to both properties. > I noticed in daml+oil+concreate.daml that ConcreteProperty is already a > subclass of rdfs:Property, which effectively eliminates the need for an > onConcreteProperty property (since the range of onProperty is Property). This is just a mistake - the range of onProperty should be AbstractProperty. I have now fixed it. > What is we also add a class called DataType that is a subclass of > rdfs:Class? That is: > > <rdf:Description rdf:ID="DataType"> > <rdfs:subClassOf="http://www.w3.org/2000/01/rdf-schema#Class"/> > </rdf:Description> > > where the range of any particular ConcreteProperty must be a DataType. > If useful, you could also add AbstractClass which is disjoint with > DataType. > > Now, since DataTypes are Classes, we should be able to use DataTypes in > the domains of toClass, hasClass, etc., while still being able to > distinguish between "ordinary" classes and data types (since all data > types are instances of DataType). This seems more natural to me than > having to come up with a whole new set of semantic primitives (such as > hasDataType, toDataType, etc.) for data types. Also note that the model > theoretic semantics are relatively unchanged by this (since your > proposed semantics for toDataType are already identical to those of > toClass, and the same is true for the other pairs of properties as > well). I don't think that this would solve the problem I outlined above. > One problem with my suggestion is that someone may attempt to define an > instance of a particular data type or place ad hoc constraints on a data > type (things I believe you were trying to prohibit syntactically with > your proposal). We could say such constructs are undefined, allowing > most systems to effectively ignore such messy stuff, although some > theorem provers may still be able to make some use of it. As I explained above, the syntax is more to do with clarification than restriction. The real restriction is the fact that the interpretation domains of abstract classes and concrete datatypes are disjoint (and that ConcreteProperty and AbstractProperty are disjoint); so it doesn't seem like a good idea to say that datatypes are all instances of some class. Ian > > Jeff > > > Ian Horrocks wrote: > > > > An outline proposal for extending daml+oil with concrete datatypes can > > be found at: > > > > http://www.cs.man.ac.uk/~horrocks/DAML+OIL/Datatypes/ > > > > Comments welcome. > > > > Ian Horrocks and Peter Patel-Schneider
Received on Monday, 22 January 2001 17:00:42 UTC