Re: Extending daml+oil with concrete datatypes

See my comments inserted in the text below...

Ian Horrocks wrote:
> 
> 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 don't think this is right. We would have a similar problem if someone
tried to define two "normal" restrictions within the same
daml:Restriction element. Consider the example:

<daml:Restriction>
   <daml:onProperty rdf:resource="#eyeColor" />
   <daml:hasValue rdf:resource="#green"> 
   <daml:onProperty rdf:resource="#hairColor" />
   <daml:hasValue rdf:resource="#brown">
</daml:Restriction>

Does this restriction define the set of things with hair that is
green/brown and eyes that are green/brown? That would be an odd
interpretation. (Note: that the use of specially named properties can't
solve this problem). The usefulness of the restriction element is that
is allows you to describe each restriction independently, such as:

<rdfs:subClassOf>
   <daml:Restriction>
      <daml:onProperty rdf:resource="#eyeColor" />
      <daml:hasValue rdf:resource="#green"> 
   </daml:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
   <daml:Restriction>
      <daml:onProperty rdf:resource="#hairColor" />
      <daml:hasValue rdf:resource="#brown">
   </daml:Restriction>
</rdfs:subClassOf>

... which clearly means the set of things that have both green eyes and
brown hair. Thus, I believe a restriction should define a restriction on
a single property, and anything else is undefined. Therefore, I don't
think your example makes a convincing argument for keeping the special
data type 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.


You are right that it doesn't solve that particular problem, but as I
point out above, special data type properties don't solve the larger
problem either.

 
> > 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.


Personally, I don't have a problem with considering DataType a kind of
Class. In the RDF Schema Spec, a class "... corresponds to the generic
concept of a Type or Category." (RDFSS 2.2.3) I see a DataType as a very
special kind of class with some built-in rules (a predefined set of
instances, possible ordering, possible arithmetic ops, etc.).

However, if it bothers you to think of a DataType as a kind of class,
then perhaps we could create a class (I'll call it TypeOrClass for lack
of a better name) that is the superclass of two disjoint classes
DataType and Class (this class corresponds to UD in the model theoretic
semantics). Now, we can say TypeOrClass is the range of all of our
standard restriction properties that used to have Class as the range,
allowing them to be used with ordinary classes or with data types.
Finally, we might want to make a minor tweak to RDF Schema, saying that
the range of rdfs:range is TypeOrClass (so DataTypes could be the range
of some properties, i.e., ConcreteProperties). An advantage of the
TypeOrClass approach, is that it would be illegal to use a DataType as a
range of rdf:type, range of rdfs:domain, or in the domain and range of
rdfs:subClassOf, but properties that can legally have values from the
abstract or the concrete domain can be defined in a common sense way.

> 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 Tuesday, 23 January 2001 13:06:44 UTC