Re: ISSUE 131 (OWL R Unification): Different semantics on syntactic fragment

Hi Ian,

In a thread you started a while ago (after a long discussion on another 

we seemed to converge toward a solution based on first finalizing the 
conformance issues. However, _my_ assumption back then was that if an 
implementation implements the OWL R Rule set (and _only_ that), then 
this would be a perfectly o.k. OWL R implementation for all those RDF 
graphs that fall under the OWL R syntactic restrictions. The issue we 
had, and for which the thread offered a good way forward, was what would 
happen to graphs that fall outside the syntactic restriction of OWL R.

However... I was clearly wrong. Michael's example shows that the Rule 
set would not provide a proper implementation of OWL R. A conformant OWL 
R implementation must do more than just implementing the rules or, put 
it another way, an implementation using the rules only could not claim 
to be OWL R conformant. This is a different and pretty serious issue 
which, I must admit, would make me vote against unification at this point.

In another mail Michael says that we should close this issue without 
action. Maybe so. At the minimum we should acknowledge that there is no 
consensus on this issue at the moment...



Ian Horrocks wrote:
> Michael,
> It has never been claimed that OWL R DL and OWL R Full are completely 
> equivalent on the syntactic fragment. What is claimed (see Section 4.4 
> of the existing Profiles doc) is that for ontologies within the 
> syntactically defined fragment the OWL RL rules will be complete w.r.t. 
> certain kinds of entailment -- in particular w.r.t. those entailments 
> that correspond to query answering.
> Your example is a good illustration of why it would be *a very bad idea* 
> to define a 3rd semantics for OWL based on the OWL RL rules. According 
> to this semantics, it would NOT be the case that owl:intersectionOf (C 
> D) is a subClassOf D. Any reasoner finding this entailment would be 
> unsound and non-conformant w.r.t. this semantics. This would, IMHO, be 
> highly counter-intuitive. Moreover, I expect that many rule based 
> implementations *will* find this entailment, or at least answer "yes" to 
> a query asking if it holds, because they will use the standard 
> rule-based technique for answering such a subsumption query, i.e., 
> assert a fresh individual to be an instance of owl:intersectionOf (C D) 
> and check if it is entailed that this individual is an instance of D. 
> This entailment *will* follow from the rules.
> Regarding the guarantees that are made, guaranteeing soundness and 
> completeness w.r.t. OWL RL Full semantics for ontologies in the 
> syntactic fragment and certain kinds of entailment seems to be the best 
> that we can do -- as you yourself have clearly illustrated. I don't 
> pretend to fully understand your statements about reasoners based on 
> subsets of the OWL RL rules, but they seem to be based on a 
> misunderstanding about what is being stated w.r.t. soundness and 
> completeness, and on some strange assumptions about how conformance will 
> be defined.
> Regards,
> Ian
> On 10 Aug 2008, at 15:45, Michael Schneider wrote:
>> Dear WG!
>> I was able to find an example, which demonstrates that the semantics 
>> of OWL R DL and OWL R Full differ on the syntactic fragment of a 
>> unified OWL R language (see below). The example shows that entailments 
>> exist w.r.t. the semantics of OWL R DL (actually, the OWL 2 DL 
>> semantics), for which there is no equivalent sequence of rule 
>> applications in OWL R Full. This means that the semantics of OWL R 
>> ontologies, which match the syntactic fragment of OWL R, cannot be 
>> defined in parallel by both the DL semantics *and* the ruleset.
>> An alternative approach would be to define the semantics of OWL R on 
>> the syntactic fragment by the OWL 2 DL semantics only. However, I 
>> would expect that this would lead to significant acceptance problems 
>> for implementers, who want to base the implementation of their OWL R 
>> reasoner on the OWL R ruleset (and for customers/users of such 
>> reasoners, either).
>> An implementer, who plans to create a reasoner based on the ruleset, 
>> certainly wants to be ensured that his reasoner implements *all* of 
>> OWL R, not only a subset, i.e. is complete w.r.t. the OWL R semantics. 
>> It would at least be very confusing and hard to accept that it is not 
>> sufficient to just implement the "OWL R rules", in order to create a 
>> complete OWL R reasoner. But with my counter example, it now turns out 
>> that completeness will not be achievable for such a rulebased reasoner.
>> Even worse, having such a concrete counter example makes it easy to 
>> create a proper *superset* of the current ruleset, which will still be 
>> sound w.r.t. the OWL R semantics. This means that the implementer 
>> cannot even claim that his reasoner is at least the "best possible" 
>> triple-rule based implementation of OWL R.
>> The only thing which the implementer can claim is that his reasoner is 
>> a "valid" OWL R reasoner, i.e. is sound w.r.t. the OWL R semantics. 
>> But this will also be the case for any reasoner, which is based on an 
>> arbitrary *subset* of the OWL R rules, and even for trivial reasoners, 
>> which do not produce any inferences at all. So, OWL R soundness alone 
>> isn't a very interesting property of an OWL R reasoner in practice.
>>> From this p.o.v., I would expect that, after a unification, 
>>> implementers will not regard the OWL R ruleset to be relevant as a 
>>> base for the implementation of OWL R reasoners. IMO, the OWL R rules 
>>> will then be no more than just an arbitrary example for how one MAY 
>>> create a valid OWL R reasoner. Without completeness guarantees, this 
>>> ruleset won't be better than any other ruleset which provides formal 
>>> OWL R soundness. Compared with the ruleset's current status in OWL R 
>>> Full, where it specifies the semantics of the language, this would be 
>>> a significant demotion.
>>    * * *
>> The example below is not simply a bug in the current ruleset, which 
>> could easily be fixed. Instead, it shows two general problems:
>>  (1) The ruleset would need to be able to create fresh bNodes on the 
>> right hand side of derivations. To my understanding, it was a design 
>> goal to avoid this. At least, none of the current rules creates such 
>> new bNodes on the consequent side.
>>  (2) Since the semantics of the current OWL R DL language is the DL 
>> semantics, it allows for very flexible reasoning with complex class 
>> expressions, as long as an ontology conforms to OWL R DL's syntactic 
>> restrictions. The current triple ruleset isn't able to compete with 
>> this amount of flexibility. And don't believe that this can be overcome.
>> Here is the example. We start from the RDF graph
>>   G_L := {
>>     ex:C rdf:type owl:Class .
>>     ex:D rdf:type owl:Class .
>>     ex:C rdfs:subClassOf ex:D .
>>   }
>> This is a valid OWL R DL ontology in RDF graph form, since only named
>> classes are used on the LHS and RHS of the subclass axiom (see sec. 4.2.3
>> of [1]).
>> The second RDF graph is
>>   G_R := {
>>     ex:C rdf:type owl:Class .
>>     ex:D rdf:type owl:Class .
>>     _:X owl:intersectionOf ( ex:C ex:D ) .
>>     _:X rdfs:subClassOf ex:D .
>>   }
>> Again, this is a valid OWL R DL ontology, because this graph RDF-maps 
>> to the
>> following expression in Functional Syntax (omitting declarations):
>>   SubClassOf( IntersectionOf(ex:C ex:D) ex:D )
>> According to sec. 4.2.3 of [1], intersections of named classes may 
>> occur on
>> the LHS of subclass axioms.
>> The semantic meaning of these two graphs is given in OWL R DL by applying
>> the OWL 2 DL semantics. According to the OWL 2 DL semantics, the 
>> entailment
>>   G_L |= G_R
>> is true, because from
>>   C subset D
>> follows
>>   (C and D) subset D
>> However, there is no sequence of applications of OWL R Full rules, which
>> starts in G_L, and which produces G_R (or a super graph of G_R) as a 
>> result.
>> Actually, there is no single triple rule in OWL R Full that would 
>> allow to
>> produce the bNode '_:X', which occurs in G_R but not in G_L.
>> Regards,
>> Michael
>> [1] <>
>> -- 
>> Dipl.-Inform. Michael Schneider
>> FZI Forschungszentrum Informatik Karlsruhe
>> Abtl. Information Process Engineering (IPE)
>> Tel  : +49-721-9654-726
>> Fax  : +49-721-9654-727
>> Email:
>> Web  :
>> 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


Ivan Herman, W3C Semantic Web Activity Lead
PGP Key:

Received on Tuesday, 12 August 2008 08:36:08 UTC