Re: Reasoning with datatype restriction predicates

Graham,

> In implementing a variation of an the idea from your "Reasoning with
> Datatype Groups" paper [1], I've a question:  is it necessary to
assume
> that the constrained properties are also functional properties (i.e.
having
> cardinality one)?
>
> (I started out thinking that the answer was "yes".  Having finished
> assembling my question, I come to a view that the answer is "no",
but that
> there may be some value to associating cardinality restrictions with
> datatype restrictions.)

Like OWL DL, we don't assume a datatype property to be functional in
our approach; we can, however, set it as functional by using a
property axiom, e.g. in OWL abstract syntax:

DatatypeProperty(ex:age Functional),

or in  Notation 3:

ex:age a owl:DatatypeProperty, owl:FunctionalProperty .

It is possible, therefore, for a datatype property (of an object) to
have multiple values, like you mentioned in your sideLength example.
Thus it makes sense to allow cardinality constraints.

The general (abstract) syntax for cardinality constraints for datatype
expressions is as follows:

restriction({datavaluedPropertyID}  cardinality datatypeExpression)

E.g.  we can describe a customer who has at least 5 friends' email
addresses which are from the same domain as his own email address(es):

SubClassOf(ex:FriendlyCustomer ex:Customer)

Class(ex:FriendlyCustomer partial
    restriction(:eAddress :friendseAddress
                        minCardinality("5"^^xsd:nonNegativeInteger )
                        (email:sameDomainAs)
                        )
           )

Or in Notation 3:

ex:FriendlyCustomer a owl:Class;
    rdfs:subClassOf ex:Customer;
     rdfs:subClassOf
    [owlx:onProperties (:eAddress :friendseAddress)
     owl:minCardinality "5"^^xsd:nonNegativeInteger
     owlx:constraints (email:sameDomainAs)]

Note that a customer might have more than one email addresses,
therefore we are actually counting tuples here.

The above general form is very expressive, which doesn't mean users
can't use some restricted forms of it in their applications. There are
quite a few special/simplified forms of  cardinality constraints for
datatype expressions:

1) to constrain how many values a datatype property (of an object) can
have: use only one datatype property and set the constraint as
rdfs:Literal, which means no constraints; e.g.

ex:A a owl:Class
    rdfs:subClassOf
    [owlx:onProperties (:eAddress)
     owl:minCardinality "2"^^xsd:nonNegativeInteger
     owlx:constraints (rdfs:Literal)];


2) to constrain how many tuples of values a set of datatype properties
can have: set the constraint as rdfs:Literal; e.g.

ex:B a owl:Class
    rdfs:subClassOf
    [owlx:onProperties (:eAddress,:friendseAddress)
     owl:minCardinality "5"^^xsd:nonNegativeInteger
     owlx:constraints (rdfs:Literal,rdfs:Literal)];


3) to constrain how many values of a datatype property (of an object)
satisfy the constraint: use only one datatype property, and use a
unary constraint; e.g.

ex:C a owl:Class
    rdfs:subClassOf
    [owlx:onProperties (:eAddress)
     owl:minCardinality "1"^^xsd:nonNegativeInteger
     owlx:constraints (email:fromUK)].

In addition, similar to the someValuesFrom and allValuesFrom
restrictions on objects, we have someTuplesSatisfy and
allTuplesSatisfy restrictions on datatypes. I am not sure if you have
tried them in your test cases though.

Best,
Jeff
--
Jeff Z. Pan  ( http://DL-Web.man.ac.uk/ )
Computer Science Dept., The University of Manchester







> Starting with the example from your paper, transcribed into Notation
3:
>
>    :River a owl:Class ;
>      rdfs:subClassOf
>      [ a owlx:BinaryRelation ;
>        owlx:onProperty1 :length_kilo ;
>        owlx:onProperty2 :length_mile ;
>        owlx:BinaryPredicate unit:kilosPerMile . ] .
>
> (where unit:kilosPerMile names a predicate that imposes an
appropriate
> relation between the values of the named properties.)
>
> In the case of a river, it seems fairly "obvious" that it has a
single
> value for length.  So:
>
>     _:a a :River
>       :length_kilo "20"^^unit:lengthInKilo
>       :length_kilo "30"^^unit:lengthInKilo
>
> would typically be understood to be an inconsistency, as would:
>
>     _:a a :River
>       :length_kilo "20"^^unit:lengthInKilo
>       :length_kilo "22"^^unit:lengthInMile
>
> But is this always the case?  Suppose we're talking about a (large)
field,
> with properties :hasSideLength_kilos and :hasSideLength_miles
>
>     _:b a :Field
>       :hasSideLength_mile "20"^^unit:lengthInMile
>       :hasSideLength_mile "30"^^unit:lengthInMile
>
> could reasonably be talking about a field with at least two sides,
from
> which we might infer (assuming a restriction on :field similar to
that for
> :river):
>
>     _:b a :Field
>       :hasSideLength_kilo "32"^^unit:lengthInKilo
>       :hasSideLength_kilo "48"^^unit:lengthInKilo
>
> (or from the latter, deduce the former).
>
> I had approached this work on the basis that if multiple values were
> supplied and found to be inconsistent, then that would lead to an
inference
> of inconsistency.  But this suggests not.
>
> The "teddy bear effect" has struck.  I now realize that I have made
> different assumptions when drafting test cases (e.g. [2]), and
writing my
> code.  It seems there are three+ choices:
>
> 1. Assume that restrictions are applied to functional properties.
Then any
> set of property values that don't satisfy the relation are deemed to
be
> inconsistent.  The :field case above suggests this may be an
unnecessary
> restriction.
>
> 2. Assume that restrictions are applied to properties without
cardinality
> constraints.  Then property values that don't conform to the
relation are
> simply taken as different instances of the properties, and no
inconsistency
> arises.  Separate application of cardinality constraints may cause
an
> inconsistency to be detected.
>
> 3. Allow the cardinality of the properties to be determined by the
> relation.  This seems messy, but would appear to allow common cases
to be
> captured easily, and maybe allows for a more direct implementation.
>
> 4. (This is a variation of 3, but seems neater):  allow a
cardinality to be
> imposed on the relation that defines a restriction;  i.e. limit the
number
> of property-value-tuples that may be jointly true of a given
> instance.  Hmmm... This seems like a possible approach to unify
handling of
> datatype reasoning with cardinality reasoning:  a restriction on
just one
> property may be used to impose owl cardinality restrictions (as well
as
> some value-range restrictions).
>
> I find (4) to be very appealing... I shall reflect some more on it.
>
> #g
> --
>
> [1]
http://www.cs.man.ac.uk/~horrocks/Publications/download/2003/PaHo03a.p
df
>
> [2]
>
http://www.ninebynine.org/RDFNotes/RDF-Datatype-inference.html#sec-Tes
t-cases
>
>
> ------------
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
>
>

Received on Friday, 14 November 2003 07:02:46 UTC