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: Tue, 23 Jan 2001 23:14:26 +0000 (GMT)
Message-ID: <14958.4178.633920.352068@excalibur.cs.man.ac.uk>
To: Jeff Heflin <heflin@cs.umd.edu>
Cc: www-rdf-logic@w3.org
I will try to clarify why we need hasClassQ:

On January 23, Jeff Heflin writes:
>
> [snip]
>
> 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.

This is exactly the interpretation - it may be odd but if you choose
to write it this way then that is what you get. As you show below, you
can make things clear by separating the two statements about hairColor
and eyeColor:

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

But if I don't have hasClasQ, when I try to write a qualified
cardinality constraint describing the class of things that have at
most three Doctors amongst their children, I get:

 <daml:Restriction>
   <daml:onProperty rdf:resource="#hasChild"/>
   <daml:hasClass rdf:resource="#Doctor"/>
   <daml:maxCardinalityQ>3</daml:maxCardinalityQ>
  </daml:Restriction>

(aside - note that there can be any number of children, in fact there
may not be any children at all, but if there are children, then at
most three of them can be Doctors)

Note that the combination of onProperty and hasClass make a perfectly
valid restriction, so I have also "inadvertently" stated that I have
at least one child who is a Doctor, something that I may not have
wanted or intended. The problem is that there is now NO WAY to state a
qualified cardinality restriction without also stating a hasClass
restriction.

Similarly, if we try to dispense with the Q versions of the various
cardinality restrictions there is no way to state a qualified
restriction without also stating an unqualified one.

The way to resolve the problem in general would be to define the
possible combinations of properties on restrictions and the meaning in
each case, but I don't see how this can be done in RDF.


As for the dedicated concrete datatype syntax, we probably could get
rid of a lot of it if we also relaxed some range restrictions. This
has pros and cons - it makes the language more compact but it could
also be argued that it makes it less clear (and maybe harder to
parse). But I am certainly open to argument on this point.

Ian
Received on Tuesday, 23 January 2001 18:21:27 GMT

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