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

Re: Extending daml+oil with concrete datatypes

From: Jeff Heflin <heflin@cs.umd.edu>
Date: Mon, 22 Jan 2001 16:09:39 -0500
Message-ID: <3A6CA193.82D4216C@cs.umd.edu>
To: Ian Horrocks <horrocks@cs.man.ac.uk>
CC: www-rdf-logic@w3.org

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.

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).
What is we also add a class called DataType that is a subclass of
rdfs:Class? That is:

<rdf:Description rdf:ID="DataType">

where the range of any particular ConcreteProperty must be a DataType.
If useful, you could also add AbstractClass which is disjoint with

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

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.


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 16:09:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:45:36 UTC