Re: A Problem With The Semantics of DAML+OIL Restrictions

Thanks for your reply to my message.  I know you followed up your first
reply with a second one saying that perhaps the problem was not as
easily dealt with as you had suggested in your first reply.  However, I
think it may be useful to comment on some of the points in your first
reply.

> Hmm... I consider onProperty and toClass to be
> UniqueProperties, i.e. cardinality 1.
> 
> I thought that was in the axiomatic or model-theoretic
> semantics somewhere; if not, I'd consider that a bug.
> And of course it should be in the prose etc.

I don't see anything in the language spec documents that restrict
toClass, hasValue, etc. to be unique properties.  If that is the
intention of the language design committee, it would be useful for the
committee to say that and of course to add that to the spec documents.

> >   * How does a reasoner determine the sufficient conditions for being an
> > instance of a restriction?
> 
> Using Ax94 etc.
> 
> Ax94.    (=> (and (PropertyValue onProperty ?r ?p)
> 
>                (PropertyValue toClass ?r ?c)) 
> 
>           (forall (?i) (<=> (Type ?i ?r)
> 
>                             (forall (?j) (=> (PropertyValue ?p ?i ?j) 
> 
>                                              (Type ?j ?c))))))

The problem is that axiom is incorrect if other properties like hasValue
or cardinality also have a value for the restriction.  That is, it is
not sufficient for an object to simply satisfy the toClass constraint in
order to be an instance of the restriction, it also has to satisfy any
other constraints that are present in the restriction.  We can fix the
axiom by saying that an object is an instance of a restriction if and
only if it satisfy all the toClass constraints in the restriction and
all the hasValue constraints in the restriction and all the cardinality
constraints in the restriction, etc.  The problem then becomes one of
knowing (proving) that one indeed has *all* of those constraints.  How
do I know that the next RDF statement in the file doesn't state an
additional constraint on a given restriction?

> > Note that this problem is confounded by the fact that DAML+OIL allows a
> > restriction to contain multiple constraints.
> 
> Not really.
> 
> i.e. you can describe such a restriction, but you're
> almost certain to state an inconsistency or
> end up with an empty/unsatisfyable class in
> almost all cases.

I disagree.  I thought the example I gave in my earlier message (i.e., a
restriction saying that "Joe" is a parent (using hasValue) and that all
parents are persons (using toClass)) was quite reasonable.  It's also
easy to combine a toClass constraint and a cardinality constraint in one
restriction (e.g., the class of all objects that have at least one
sibling and all of whose siblings are male).

> > The most straightforward solution to this problem seems to be to change
> > DAML+OIL so that a restriction expresses exactly one constraint.  That
> > would mean that a restriction would have one value for exactly one of
> > the properties toClass, hasValue, minCardinality, maxCardinality,
> > cardinality, etc.
> > 
> > That is the solution I would recommend.
> 
> That's a pretty good health warning for users: don't
> try to specify more than one on the same restriction.

Note that the DAML+OIL reference document says:

"When there are multiple restrictions listed as part of a single
Restriction element, the property P has to satisfy all of the
restrictions (i.e., multiple restrictions are read as a conjunction)."

and does not contain any warnings about the inadvisability of including
multiple restrictions in a single restriction element.

> But I don't see why we need to do it that way formally.
> 
> Formally, we can just say (if we have not already)
> that each of toClass/hasValue/etc. is functional/unique/cardinality-1.

That isn't sufficient as I said above because other properties like
hasValue or cardinality can also have a value for the restriction.

> > Make a Completeness Assumption About the Description of a Restriction
> > ---------------------------------------------------------------------
> > 
> > Assume the RDF statements in a given file completely describe each
> > restriction mentioned in the file.
> 
> Ugh. No thanks. We went to a lot of trouble to avoid that
> sort of thing, and I'd rather not go there.

I agree.

As I said in my first message, I think the solution of simply requiring
that restrictions can specify only one constraint is the preferable one.

Richard

Received on Monday, 2 July 2001 19:12:30 UTC