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

I too have been struggling with Restriction semantics. After much discussion
Geoff Chappell convinced me that
the correct way to apply a restriction to a property of a specific class was
to assert triples like
so:
(Type R Restriction)
(onProperty R parent)
(toClass R Person)
(subclassOf Person R)

in other words the "parent" property of a "person" must be another "person".
If this is correct then
the onProperty, toClass, hasValue properties should also apply to the class
person (not instances but the class itself) and it should be legal to then
assert:

(onProperty Person parent)
(toClass Person person)
(onProperty Person pet)
(toClass Person Animal)

If so what then are the indended restrictions?

-AM

----- Original Message -----
From: "Richard Fikes" <fikes@KSL.Stanford.EDU>
To: "www-rdf-logic" <www-rdf-logic@w3.org>
Sent: 07/02/01 6:07 PM
Subject: 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:47:45 UTC