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

Re: Extending daml+oil with concrete datatypes

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Tue, 23 Jan 2001 13:23:48 -0500
To: heflin@cs.umd.edu
Cc: horrocks@cs.man.ac.uk, www-rdf-logic@w3.org
Message-Id: <20010123132348I.pfps@research.bell-labs.com>
From: Jeff Heflin <heflin@cs.umd.edu>
Subject: Re: Extending daml+oil with concrete datatypes
Date: Tue, 23 Jan 2001 13:06:38 -0500

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

This one restricts both eyeColor and hairColor to be both green and brown.
This is perfectly OK, semantically, but probably not very useful.  

The problem occurs when a proper subset of a set of semantically-meaningful
triples is also a set of semantically-meaningful triples.  Then the
meaning of the superset cannot be present without the meaning of the
subset.  We have made several annoying decisions that were mandated by this
problem.  If instead we had a more-powerful grouping construct we would not
have had to do this.

Received on Tuesday, 23 January 2001 13:24:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:33 UTC