A Problem With The Semantics of DAML+OIL Restrictions

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.

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?

  * How does a reasoner determine the sufficient conditions for being an
instance of a restriction?

Note that this problem is confounded by the fact that DAML+OIL allows a
restriction to contain multiple constraints.  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)

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.


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.  Reasoners could incorporate that
assumption in whatever way they wanted.  For example, an FOL reasoner
could transliterate each RDF statement into an FOL relational sentence
as described in the axiomatic semantics paper, and it could add a
sentence to the translation for each restriction described in the file
stating sufficient conditions for being an instance of the restriction. 
The sufficient conditions could use a new relation SatisfiesRestriction
that takes as arguments (1) an object, (2) a property, (3) a property
that expresses a constraint in a restriction such as toClass, hasValue,
cardinality, etc., and (4) a value for the property that is the third
argument.  So, for example, the literal:

  (SatisfiesRestriction ?x parent hasValue Joe)

would mean that ?x satisfies the constraint that "Joe" is a value of
"parent" for ?x.

The sufficient conditions for being an instance of a restriction would
then be a conjunction of SatisfiesRestriction sentences corresponding to
the constraints expressed in the restriction.

For example, the restriction that is the class of all objects that have
"Joe" as a value of "parent" and all of whose parents are type "Person"
would be translated into RDF as follows:

  (type R Restriction)
  (onProperty R parent)
  (hasValue R Joe)
  (toClass R Person)

The translation into KIF would be the following sentences:

  (Type R Restriction)
  (PropertyValue onProperty R parent)
  (PropertyValue hasValue R Joe)
  (PropertyValue toClass R Person)
  (=> (and (SatisfiesRestriction ?x parent hasValue Joe)
           (SatisfiesRestriction ?x parent toClass Person))
      (Type ?x R))


The axioms for hasValue and toClass would be changed to be as follows:

  (<=> (SatisfiesRestriction ?x ?p hasValue ?v)
       (PropertyValue ?p ?x ?v)) 

  (=> (and (PropertyValue onProperty ?r ?p)
           (PropertyValue hasValue ?r ?v)
           (Type ?x ?r))
      (SatisfiesRestriction ?x ?p hasValue ?v))

  (<=> (SatisfiesRestriction ?x ?p toClass ?c)
       (forall (?j) (=> (PropertyValue ?p ?x ?j) 
                        (Type ?j ?c))))

  (=> (and (PropertyValue onProperty ?r ?p)
           (PropertyValue toClass ?r ?c)
           (Type ?x ?r))
      (SatisfiesRestriction ?x ?p toClass ?c))

Thus, "(SatisfiesRestriction ?x ?p hasValue ?v)" is just a shorthand for
the hasValue constraint, "(SatisfiesRestriction ?x ?p toClass ?c)" is a
shorthand for the toClass constraint, etc.

Received on Monday, 2 July 2001 18:04:08 UTC