- From: Graham Klyne <gk@ninebynine.org>
- Date: Thu, 13 Nov 2003 13:54:00 +0000
- To: "Jeff Z. Pan" <pan@cs.man.ac.uk>, Ian Horrocks <horrocks@cs.man.ac.uk>
- Cc: www-rdf-logic@w3.org
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.) ... 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.pdf [2] http://www.ninebynine.org/RDFNotes/RDF-Datatype-inference.html#sec-Test-cases ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Received on Thursday, 13 November 2003 08:56:14 UTC