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

Richard Fikes wrote:
> 
> We are developing a DAML+OIL reasoner based on our axiomatic semantics
> paper and have an initial version of the reasoner running.  That work
> has led me to a set of concerns about the semantics of DAML+OIL
> restrictions on which I would like some feedback.  Although I take
> responsibility for whatever claims are made here about these problems,
> Richard Waldinger, Pat Hayes, Deborah McGuinness, and Gleb Frank have
> all contributed to an initial discussion of these issues and an
> exploration of possible solutions.
> 
> The concerns are focused on the semantics of DAML+OIL restrictions.  A
> DAML+OIL restriction is a class, and moreover is a non-primitive (aka
> defined) class.  Thus, the conditions stated in a restriction element
> are intended to provide both necessary and sufficient conditions for
> membership in the class.  So, a restriction that has a value of "parent"
> for the property onProperty and a value of "Person" for the property
> toClass is intended to represent the class of all objects all of whose
> values of "parent" are type "Person".  The concern is that a
> straightforward translation of such a restriction into RDF, e.g.:
> 
>   (Type R Restriction)
>   (onProperty R parent)
>   (toClass R person)
> 
> does not capture the notion that the restriction has no other values of
> toClass and has no values for hasValue, cardinality, etc.  The missing
> "completeness" information is important since any such additional values
> would have to be included in the sufficient conditions for membership in
> the restriction.

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.


> Since the DAML+OIL reference description
> (http://www.daml.org/2001/03/reference.html) says that a DAML+OIL
> knowledge base is a collection of RDF triples, the questions are:
> 
>   * What set of RDF triples corresponds to a DAML+OIL restriction?

You got it right above.

>   * 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))))))



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

>  That is, the above example
> restriction could also contain a value "Sam-Jones" for property hasValue
> so that the restriction is saying that it is the class of all objects
> that have "Sam-Jones" as a parent and all of whose parents are type
> "Person".  The RDF for that restriction would be:
> 
>   (Type R Restriction)
>   (onProperty R parent)
>   (toClass R person)
>   (hasValue R Sam-Jones)

Yes... provided Sam-Jones is a parent, that's the same as

   (Type R Restriction)
   (onProperty R parent)
   (hasValue R Sam-Jones)

no?

> Attached below are two proposals for fixing this problem.  All comments
> welcome.
> 
> Richard
> 
> Change DAML+OIL So That A Restriction Contains Only One Constraint
> -----------------------------------------------------------------
> 
> 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.

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.

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



-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Monday, 2 July 2001 18:33:49 UTC