Re: [OWLWG-COMMENT] Example why current RDF mapping for QCRs might hurt OWL-1.1-Full [Re: PROPOSAL to close ISSUE-68]

>I have no objection to the solution that was 
>used in OWL 1.0 for this.  So far, if a feature 
>adds problems to DL, we apparently throw it out 
>immediately, but if it causes problems to full, 
>we try to find a work around without worrying 
>too much if it cases problems or confusion - I 
>just fine this asymmetry to be troubling.

I agree with Jim on this, and on the fact that it 
is a serious error to revert to a DAML 'feature' 
which was rejected for good reasons, based on 
deployed systems and usage, in OWL 1.0.

I offer an alternative way to approach this particular problem below.

>  So I propose we don't include QCRs, since the 
>solution proposed is one that was already 
>considered and rejected in OWL 1.0 - what has 
>changed?

This is too drastic. QCRs are very useful and have often been requested.

I don't think the problems are very hard to 
overcome. In fact, I strongly suspect that those 
who are crying that the 1.1-Full sky is falling 
have already thought of them but are happier 
contemplating a future which hasn't got an 
OWL-Full in it. If you recall, Jim, we were told 
on several occasions that OWL 1.0-Full was 
logically impossible. One must expect to hear a 
refrain of cries of woe about anything having to 
do with any non-DL formalism.

>  -JH
>
>
>On Dec 16, 2007, at 4:43 PM, Michael Schneider wrote:
>
>>[ public comment to discussion in OWL-WG;
>>also posted to involved WG members ]
>>
>>Jim Hendler wrote on Thu, 13 Dec 2007
>>in 
>><<http://lists.w3.org/Archives/Public/public-owl-wg/2007Dec/0176.html>http://lists.w3.org/Archives/Public/public-owl-wg/2007Dec/0176.html>
>>within thread "Re: PROPOSAL to close ISSUE-68"
>>
>>>I  would not be happy with  this solution - it creates yet more,
>>>seemingly unecessary terms, and it also was, in DAML days, the single
>>>feature name that confused the most people - I thought we were
>>>proposing a clean solution that didn't require creating a new
>>>syntactic feature, this is quite different - so I oppose closing this
>>>issue with Peter's suggested solution.
>>>   -JH
>>>
>>>On Dec 13, 2007, at 11:27 AM, Peter F. Patel-Schneider wrote:
>>>
>>>>
>>>>ISSUE-68 has to do with a nonmonotonicity in the mapping rules for
>>>>qualified cardinality restrictions.  As pointed out in several places
>>>>this can be alleviated by using the DAML+OIL solution of having a
>>>>different property for qualified cardinalities.
>>>>
>>>>I thus propose using
>>>>
>>>>owl:minCardinalityQ
>>>>owl:maxCardinalityQ
>>>>owl:cardinalityQ
>>>>
>>>>just as in DAML+OIL and close the issue with this change.
>>>>
>>>>Peter F. Patel-Schneider
>>>>Bell Labs Research
>>>>
>>>>PS:  Just about any name could be used, but this one has historical
>>>>      antecedents.
>>>>
>>>
>>>"If we knew what we were doing, it wouldn't be called research, would
>>>it?." - Albert Einstein
>>>
>>>Prof James Hendler
>>>
>><http://www.cs.rpi.edu/~hendler>http://www.cs.rpi.edu/~hendler
>>
>>>Tetherless World Constellation Chair
>>>Computer Science Dept
>>>Rensselaer Polytechnic Institute, Troy NY 12180
>>>
>>
>>Hi Jim!
>>
>>Peter has already pointed out in another thread a serious problem for
>>OWL-1.1-Full arising from the current RDF mapping of QCRs:
>>
>>   QCR problem in OWL 1.1 Full - action ?? from F2F
>> 
>><<http://lists.w3.org/Archives/Public/public-owl-wg/2007Dec/0095.html>http://lists.w3.org/Archives/Public/public-owl-wg/2007Dec/0095.html>
>>
>>And I had found a second problem with the same RDF mapping, which might at
>>least lead to non-desirable effects:
>>
>> 
>><<http://lists.w3.org/Archives/Public/public-owl-dev/2007OctDec/0224.html>http://lists.w3.org/Archives/Public/public-owl-dev/2007OctDec/0224.html>
>>
>>Both problems are easily solved by Peter's proposed change to the RDF
>>mapping.
>>
>>Based on Peter's finding, I want to give an example in this mail, which
>>shows what severe consequences it may have for OWL-1.1-Full, if the WG
>>sticks to the current RDF mapping for QCRs.
>>
>>Let's regard the following OWL-1.1-DL ontology in Functional Syntax, which
>>makes use of QCRs:
>>
>>   (A1) SubClassOf(Human ObjectExactCardinality(2 hasBodyPart Leg))
>>   (A2) SubClassOf(Dog ObjectExactCardinality(2 hasBodyPart Ear))
>>   (A3) SubClassOf(Dog ObjectExactCardinality(4 hasBodyPart Leg))
>>   (A4) ClassAssertion(pluto Dog)
>>
>>In natural English:
>>
>>   "A human has exactly two legs as body parts (A1),
>>   while a dog has two ears (A2) and four legs (A3).
>>   There is also some dog named 'Pluto' (A4)."
>>
>>It is clear that this ontology will be satisfiable in OWL-1.1-DL. I will
>>show that the current RDF mapping of QCRs translates this ontology into an
>>RDF graph, which will most likely be *inconsistent* under OWL-1.1-Full
>>semantics. Note that the above ontology does not look very contrieved, so I
>>expect that the problem shown below will hit many OWL-1.1-Full ontologies.
>>
>>Here is my reasoning why the above ontology will probably be inconsistent
>>under OWL-1.1-Full semantics:
>>
>>The RDF translation for axiom (A1) is, under the current RDF mapping for
>>QCRs, given by (leaving out obvious typing triples):
>>
>>   (R11) <Human> rdfs:subClassOf _:x .
>>
>>   (R12) _:x rdf:type owl:Restriction .
>>   (R13) _:x owl:onProperty <hasBodyPart> .
>>   (R14) _:x owl:cardinality 2 .
>>   (R15) _:x owl11:onClass <Leg> .
>>
>>As Peter has already pointed out, the RDF graph {(R12),(R13),(R14)} is
>>itself the RDF translation of an *other* OWL construct, which is an
>>UN-qualified cardinality restriction on property 'hasBodyPart'.

Indeed. Coming to this discussion rather late, 
and not having followed the threads, I have to 
say that this is blindingly obvious, and the 
resulting problems it will produce also 
blindingly obvious. Clearly, this RDF translation 
is seriously broken, and should never have been 
considered for more than a moment.

This might have been more obvious if instead of 
thinking of the RDF as a mere syntactic 
transcription of an alien notation, one had tried 
to extend the current OWL-Full semantics directly.

There are several ways to get around this. The 
most obvious seems to be to modify R12, by 
introducing a new class of Q-restrictions, so 
that the RDF translation becomes

(R'12) _:x rdf:type owl:QRestriction .
(R'13) _:x owl:onProperty <hasBodyPart> .
(R'14) _:x owl:cardinality 2 .
(R'15) _:x owl11:onClass <Leg> .

To keep this 'clean', the other restrictions 
should be in another new disjoint class, which I 
will call UQRestriction. Then

(R''12) _:x rdf:type owl:UQRestriction .
(R'13) _:x owl:onProperty <hasBodyPart> .
(R'14) _:x owl:cardinality 2 .

is the RDF translation for the other restrictions, and we also have

owl:UQRestriction rdfs:subClassOf owl:Restriction .
owl:QRestriction rdfs:subClassOf owl:Restriction .
owl:QRestiction owl:disjointWith owl:UQRestriction .

I believe the appropriate semantic conditions can 
then be applied without any confusion arising. 
This is of course backwards compatible with OWL 
1.0, in which

owl:UQRestriction rdfs:subClassOf owl:Nothing .

also holds.

>>For this sub
>>graph, there already exists an OWL-1.0-Full semantic condition, given in
>>sec. 5.3 of [1], table "Conditions on OWL restrictions", which in essence is
>>defined to be:
>>
>>    (S-CARD)
>>       IF
>>         r owl:onProperty p .
>>         r owl:cardinality n .
>>       THEN
>>         CEXT(r) = { x : card({y: x p y}) = n }
>>
>>This semantic condition tells that if there exists an (un-qualified!)
>>"=n"-cardinality restriction r on some property p in an RDF graph, then the
>>/class extension/ of r ("CEXT(r)") equals to the set of all instances x
>>which have exactly n ocurrences of property p assigned to them.
>>
>>So given that (S-CARD) is reused in OWL-1.1-Full (what I regard to be very
>>likely

With my proposal above, this is true in a sense 
but the statement will be modified to apply only 
when r is an element of owl:UQRestriction

>>), we will receive from the RDF graph {(R1*)} the following
>>entailment:
>>
>>   (E1) CEXT(_:x) = { x : card({y: x hasBodyPart y}) = 2 }
>>
>>Now, OWL-1.1-Full will have to contain an additional semantic condition for
>>handling QCRs, and I strongly believe that such a semantic condition will
>>have the following form:
>>
>>    (S-QCR)
>>       IF
>>         r owl:onProperty p .
>>         r owl:cardinality n .
>>         r owl11:onClass c .
>>       THEN
>>         CEXT(r) = { x : card({y: x p y AND y rdf:type c}) = n }

Again, yes but only when r is in owl:QRestriction.

>>In this case, we will receive the following /additional/ entailment from the
>>RDF graph {(R1*)}:
>>
>>   (E2) CEXT(_:x) = { x : card({y: x hasBodyPart y AND y rdf:type Leg}) = 2 }
>>
>>Taken together, entailments (E1) and (E2) tell that
>>
>>   (E3) { x : card({y: x hasBodyPart y}) = 2 }
>>        = CEXT(_:x) =
>>        { x : card({y: x hasBodyPart y AND y rdf:type Leg}) = 2 }
>>
>>This alone looks odd, and it is in essence, AFAICT, what Peter was about in
>>his original mail.

And of course this entailment never occurs since 
the two classes of r's are disjoint, so no 
restriction will ever trigger both conditions.

>>However, (E3) alone is still satisfiable under specific
>>conditions.
>>
>>But let's now look at axiom (A2): With an analog argumentation as for (A1)
>>we receive the following set equality:
>>
>>   (E4) { x : card({y: x hasBodyPart y}) = 2 }
>>        = CEXT(_:y) =
>>        { x : card({y: x hasBodyPart y AND y rdf:type Ear}) = 2 }
>>
>>where '_:y' denotes the cardinality restriction used in (A2), after being
>>translated into an RDF graph. Note that '_:y' is a different bNode from
>>'_:x', so it /may/ denote a different restriction class.
>>
>>But looking closer to (E3) and (E4) reveals, that the respective left hand
>>sides of these equations are the /same/ in both cases. So we learn:
>>
>>   (E5) CEXT(_:x) = CEXT(_:y)
>>
>>Now, looking again into sec. 5.2 of [1], table "Characteristics of OWL
>>vocabulary related to equivalence", first entry, we see that the following
>>semantic condition holds (please mind the "iff" in the right table header!

Right, and it should be "only if". See below.

>>):
>>
>>   (S-EQUIV)
>>     IF
>>       CEXT(x) = CEXT(y), for classes ("IOC") x and y
>>     THEN
>>       x owl:equivalentClass y
>>      ("<x,y> IN EXT_I(S_I(E))" with E := "owl:equivalentClass")
>>
>>Thus, from (E5) and (S-EQUIV) we obtain:
>>
>>   (E6) _:x owl:equivalentClass _:y .
>>
>>And this means that the two QCRs from axioms (A1) and (A2) are actually
>>equivalent classes. Or in English:
>>
>>   "Everything which has exactly two ears
>>   also has exactly two legs, and vice versa."
>>
>>So axiom (A2) is semantically OWL-1.1-Full equivalent to (in Functional
>>Syntax for easy read, but assume it were given in RDF instead):
>>
>>   (A2') SubClassOf(Dog ObjectExactCardinality(2 hasBodyPart Leg))
>>
>>The QCR in (A2') is obviously disjoint from the QCR in (A3), so class Dog,
>>being a subclass of both QCRs, turns out to be empty:
>>
>>   (E7) <Dog> rdfs:subClassOf owl:Nothing .
>>
>>And by stating through (A4) that Pluto is a Dog, we see that our ontology is
>>inconsistent in OWL-1.1-Full:
>>
>>   (E8) <Pluto> rdf:type owl:Nothing .
>>

Most ingenious, but to me this proof is a symptom 
of a basic mistake in the OWL semantics as 
compared to RDFS, which is its insistence on 
treating classes extensionally. IMO, OWL 1.1 
would be vastly improved if it were to go back to 
the RDFS style for dealing with equivalence of 
classes. The resultlng semantics is both more 
intuitive (unless possibly you have taken several 
courses in FO logic taught from older textbooks) 
and computationally more tractable. It seems like 
a win/win to me.

However, the above fix for the QCR problem does not require this improvement.

Pat Hayes


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Sunday, 16 December 2007 23:21:40 UTC