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

On July 2, Richard Fikes writes:
> 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

Richard,

This "problem" was discussed at length when we were designing the
language (if I did around in the mail archive I can find some examples
similar to the one you provide above). Like it or not, this is what
you get when you use rdf, as it provides no way to specify structural
constraints on the kinds of thing you can write (you can "say anything
about anything").

Having said that, and although the above style of multiple constraints
are probably best avoided (in the interests of human
read/understandability at least), they present no inherent
difficulties and are comparable to stating the equivalence of two
simple restrictions - I could say much the same thing as your
Sam-Jones example with something like:

   (Type R Restriction)
   (onProperty R parent)
   (toClass R person)

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

   (sameClassAs R R2)

Of course, as in your example, we can now infer that the set of
objects who have Sam-Jones as a parent is the same as the set of
objects all of whose parents are persons. This may not be a very
sensible thing to say, but you can say crazy things in any tolerably
expressive language.

The (model theoretic) semantics are clear about the meaning of
restrictions (whether multiple or single), and they shouldn't present
any problems for a reasoner (beyond those that are already there due
to the ability to state arbitrary equivalences).

We deliberately chose to avoid the "solution" of using the language
(DAML+OIL) to constrain itself (e.g., by setting cardinality
constraints on toClass etc) as we did not want to try providing a
semantics for this kind of usage.

Regards, Ian


> 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 19:59:31 UTC