Re: Extending daml+oil with concrete datatypes

Do we have to give DAML semantics for every legal RDF construction? I
don't see why we can't say some perfectly-good RDF (such as the example
below) is just not valid DAML. I'd rather encourage tool developers to
consider Restrictions with more than one onProperty to be errors that
should be brought to the user's attention, rather than (in this case)
making the assumption that what is intended are things whose eyeColor
and hairColor are both green and brown. We could even make onProperty a
UniqueProperty to be explicitly clear that there should only be one for
each restriction!

Jeff

"Peter F. Patel-Schneider" wrote:
> 
> 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.
> 
> peter

Received on Tuesday, 23 January 2001 15:45:25 UTC