From: Pat Hayes <phayes@ihmc.us>

Date: Sun, 16 Dec 2007 15:21:20 -0800

Message-Id: <p06230916c38b56b5db70@[192.168.1.6]>

To: Jim Hendler <hendler@cs.rpi.edu>

Cc: "Owl Dev" <public-owl-dev@w3.org>, "Jim Hendler" <hendler@cs.rpi.edu>, <pfps@research.bell-labs.com>, <ian.horrocks@comlab.ox.ac.uk>, <alanruttenberg@gmail.com>

Date: Sun, 16 Dec 2007 15:21:20 -0800

Message-Id: <p06230916c38b56b5db70@[192.168.1.6]>

To: Jim Hendler <hendler@cs.rpi.edu>

Cc: "Owl Dev" <public-owl-dev@w3.org>, "Jim Hendler" <hendler@cs.rpi.edu>, <pfps@research.bell-labs.com>, <ian.horrocks@comlab.ox.ac.uk>, <alanruttenberg@gmail.com>

>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/phayesReceived on Sunday, 16 December 2007 23:21:40 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:58:16 UTC
*