W3C home > Mailing lists > Public > www-rdf-logic@w3.org > January 2001

Re: Extending daml+oil with concrete datatypes

From: Ian Horrocks <horrocks@cs.man.ac.uk>
Date: Mon, 22 Jan 2001 21:54:15 +0000 (GMT)
Message-ID: <14956.44039.926344.315624@excalibur.cs.man.ac.uk>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:38 GMT