Re: Reasoning with datatype restriction predicates

Jeff,

Thanks for your comments.

It seems we are moving along similar lines...

At 12:14 14/11/03 +0000, Jeff Z. Pan wrote:
>Like OWL DL, we don't assume a datatype property to be functional in
>our approach;

That's the conclusion I came to.  Some of the results (in the absence of 
explicit cardinality constraints) may be surprising.  One of my test cases:

[[
     xsd_boolean:And a rdfd:GeneralRestriction ;
       rdfd:onProperties (rdf:_1 rdf:_2 rdf:_3) ;
       rdfd:constraint xsd_boolean:and .
]]

combined with this:
[[
     test:and06 a xsd_boolean:And ;
       rdf:_1 "true"^^xsd:boolean ;
       rdf:_2 "false"^^xsd:boolean ;
       rdf:_3 "true"^^xsd:boolean .
]]
(where the value of rdf:_1 is intended to be the conjunction)

yields this:
[[
     test:and06 a xsd_boolean:And ;
       rdf:_1 \"false\"^^xsd:boolean ;
       rdf:_2 \"false\"^^xsd:boolean ;
       rdf:_3 \"true\"^^xsd:boolean .
]]
(because the original value of rdf:_1 is taken to be a value in some other 
tuple).  Adding a cardinality constraint has the desired effect of forcing 
an inconsistency to be recognized.

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

OK.  I don't currently have a separate cardinality reasoner, so this is 
academic for me, but I see the point.  (But see final comments below.)

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

Yup.  That's how mine is working.  The And rule above becomes:

[[
     xsd_boolean:And a rdfd:GeneralRestriction ;
       rdfd:onProperties (rdf:_1 rdf:_2 rdf:_3) ;
       rdfd:constraint xsd_boolean:and ;
       rdfd:maxCardinality "1"^^xsd:nonNegativeInteger .
]]

Interestingly, once I got the tuple-cardinality logic working, I found that 
other aspects of the datatype inference process became simpler.

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

Yes... I'm thinking that I can adapt my datatype reasoner to perform 
OWL-like cardinality reasoning as well.  I think I can write a rule parser 
to recognize the relevant OWL constructs in an RDF graph, and generate 
(what I call) a rule  to perform the corresponding inference.  But that's 
not high on my priorities right now.

Currently, I only have a maxCardinality constraint implemented on my 
datatype constraints ... drawing conclusions from minCardinality feels a 
bit non-monotonic to me (but that won't stop me if I encounter an 
application that needs it.)

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

An interesting thought.  It's not something for which I'm aware of any 
immediate requirement, but I'll bear it in mind.

Thanks,

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Friday, 14 November 2003 18:16:00 UTC