W3C home > Mailing lists > Public > public-owl-dev@w3.org > October to December 2007

RE: [OWLWG-COMMENT] Example why current RDF mapping for QCRs might hurt OWL-1.1-Full

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 18 Dec 2007 16:00:13 -0800
Message-Id: <p06230942c38dffad5e80@[]>
To: "Michael Schneider" <schneid@fzi.de>
Cc: "Owl Dev" <public-owl-dev@w3.org>

>[agreed, offlist]

actually that was just an accident, so back on-list again :-)

>Hi again, Pat!
>>-----Original Message-----
>>From: Pat Hayes [mailto:phayes@ihmc.us]
>>Sent: Tuesday, December 18, 2007 3:34 AM
>>To: Michael Schneider
>>Subject: RE: [OWLWG-COMMENT] Example why current RDF mapping
>>for QCRs might hurt OWL-1.1-Full
>>>Hi Pat!
>>>Many thanks for looking through my reasoning! The rest of
>>this thread moved
>>>a bit in a different direction from what I had expected...
>>>Regarding your suggestion to fix the issue, you claim that it will be
>>>backwards compatible with OWL-1.0. But I do not recognize how this can
>>>really be achieved. Please see below!
>>Yes, you are right. OK, let me modify the proposal slightly. It is
>>structurally the same but the terminology has been altered, according
>>the following table:
>>old proposal		new proposal
>>owl:UQRestriction		owl:Restriction
>>owl:QRestriction		owl:QRestriction
>>owl:Restriction		owl:Restriction1.1
>>with isomorphic relationships between them.
>This means that the additional axioms, you mentioned in your previous mail,
>will become:
>   owl:Restriction rdfs:subClassOf owl:Restriction1.1 .
>   owl:QRestriction rdfs:subClassOf owl:Restriction1.1 .
>   owl:QRestriction owl:disjointWith owl:Restriction .

Yes, though I'm using owl11:Restriction rather 
than owl:Restriction1.1 below, following your 

>>This introduces a new
>>name for the class of restrictions in 1.1, which is a proper
>>superclass of the restrictions in 1.0, thereby maintaining
>>consistence of terminology between 1.0 and 1.1. The RDF
>>representation for an unqualified restriction in 1.1 is now exactly
>>the same as it was in 1.0, and has isomorphic conditions imposed upon
>>it. OWL 1.1 will therefore use the exact same RDF encoding for its
>>1.0 subset as 1.0 does, and will support the exact same entailments
>>within that subset.
>I'm afraid there is still a problem. :-( It will at least not be possible to
>simply extend the current RDF compatible semantics of OWL-1.0 with your

Well no, but that isn't necessary, and is 
probably not going to be possible in any case for 
other reasons, I would guess. OWL 1.1 can 
(should? must?) be given its own semantic 
specification, especially for the RDF embedding, 
which should support the same entailments as 1.0 
for the 1.0 fragment, but can (should? must?) be 
phrased somewhat differently. It is easy to see 
how to do it, Im sure you could write it out, but 
I hereby volunteer to do so if you feel it is 

The chief advantage to this compared to Peter's 
suggestion is that it keeps the actual language 
simpler, which is a huge advantage compared to 
making it easier to write the semantic spec. I 
don't think Peter's suggestion is feasible. Jim 
is not alone in absolutely detesting the old DAML 
vocabulary, and if it is brought back simply to 
avoid a routine piece of spec-writing, there will 
be hell to pay (and quite rightly, IMO). It might 
even prevent the spec reaching REC status. I for 
one would strongly lobby against any attempt to 
bring back the bad points of DAML syntax.

BTW, you say that Peter's suggestion is 'robust', 
but the central problem of it is that it uses the 
same term for the class of 1.0 restrictions as 
for 1.1 restrictions, yet these are different 
sets. This is not a robust technique! It is 
likely to cause other problems, since the meaning 
of a central part of the semantic spec shifts 
incompatibly between the 1.0 and 1.1 specs. Its 
relatively easy to change the words: what makes 
things robust is not changing the mathematics.

>The natural solution seems to be to change the semantic cardinality
>condition into:
>   IF
>     x rdf:type owl:Restriction .
>     x owl:onProperty p .
>     x owl:cardinality n .
>   THEN
>     ...
>But if this "bugfix" would be applied in the OWL-1.1 semantics, OWL-1.1-Full
>would not really be perfectly backwards compatible with OWL-1.0-Full. Fact
>is that according to OWL-1.0-Full semantics the following RDF graph already
>completely specifies a cardinality restriction:
>   (R21) _:x owl:onProperty <hasBodyPart> .
>   (R22) _:x owl:cardinality 2 .
>Because both, that the additional information that '_:x' denotes an
>owl:Restriction, and that the extension of this class equals a cardinality
>restriction, is entailed from {(R2*)} through the OWL-1.0 semantic
>cardinality restriction. But with the "fixed" semantic cardinality condition
>in OWL-1.1, this graph would not match any semantical condition anymore, so
>it would *not* specify a cardinality restriction.

True, well spotted.

>The question is, whether this new loss of backwards compatibility may be
>regarded to be a minor problem. Well, this is certainly hard to answer, and
>I am neither able nor willing to answer this question.

Well, I am :-) It is minor. I bet there isn't a 
single deployed 1.0 ontology which omits the 
owl:Restriction triple in this way. IMO this very 
small change is well worth the cost of an ugly 
extension to the language. But for compatibility 
purists, read on.

>  Instead, I prefer to
>go the easy way, by voting for Peter's solution to introduce a new property
>   owl11:qualifiedCardinality
>With this, the above problems will not occur, because OWL-1.0-Full simply
>does not have any semantic condition which matches parts of the RDF graph
>  (R31) _:x rdf:type owl:Restriction .
>  (R32) _:x owl:onProperty <hasBodyPart> .
>  (R33) _:x owl:qualifiedCardinality 2 .
>  (R34) _:x owl11:onClass <Leg> .
>besides one condition which entails from (R31) that _:x is an owl:Class, but
>this is ok, of course.

One gets a similar fix by modifying the 
onProperty, which has the advantage that it does 
not alter the 'core' vocabulary, only the 
vocabulary that is introduced to handle the RDF 

(R31') _:x rdf:type owl:Restriction .
(R32') _:x owl11:onPropertyQ <hasBodyPart> .
(R33') _:x owl:cardinality 2 .
(R34') _:x owl11:onClass <Leg> .

And this could be given an analogous semantics 
where the first triple is redundant. But I am 
still leery of calling this an owl:Restriction. 
The fact is, its not an OWL1.0 restriction. It 
just takes one 'iff' in the spec to foul things 
up. I'd rather use

(R31'') _:x rdf:type owl11:Restriction .

>So Peter's solution seems to work in a robust way, and it will also allow
>(or I should better say: it won't prevent) to construct an OWL-1.1-Full
>semantics, which is backwards compatible with OWL-1.0-Full by simply
>extending the current set of semantic conditions in OWL-1.0.

As said above, I think this is a misguided 
ambition, one likely to create more problems than 
it solves, and in any case not semantically or 
mathematically necessary. This kind of situation, 
where adding some new vocabulary requires one to 
rephrase the older semantic conditions to 
preserve their intended meaning in a larger 
language, is not at all uncommon.


>  (Whether there
>will still have to be fixes to certain OWL-1.0 semantic conditions will then
>be a different story).
>Dipl.-Inform. Michael Schneider
>FZI Forschungszentrum Informatik Karlsruhe
>Abtl. Information Process Engineering (IPE)
>Tel  : +49-721-9654-726
>Fax  : +49-721-9654-727
>Email: Michael.Schneider@fzi.de
>Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555
>FZI Forschungszentrum Informatik an der Universität Karlsruhe
>Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
>Tel.: +49-721-9654-0, Fax: +49-721-9654-959
>Stiftung des bürgerlichen Rechts
>Az: 14-0563.1 Regierungspräsidium Karlsruhe
>Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
>Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus

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 Wednesday, 19 December 2007 00:00:36 UTC

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