W3C home > Mailing lists > Public > public-owl-wg@w3.org > March 2008

RE: Proposal to resolve ISSUE-67

From: Michael Schneider <schneid@fzi.de>
Date: Mon, 24 Mar 2008 11:49:03 +0100
Message-ID: <0EF30CAA69519C4CB91D01481AEA06A08035CC@judith.fzi.de>
To: "Alan Ruttenberg" <alanruttenberg@gmail.com>
Cc: "Web Ontology Language ((OWL)) Working Group WG" <public-owl-wg@w3.org>
Hi Alan!

>-----Original Message-----
>From: public-owl-wg-request@w3.org 
>[mailto:public-owl-wg-request@w3.org] On Behalf Of Alan Ruttenberg
>Sent: Monday, March 24, 2008 2:58 AM
>To: Web Ontology Language ((OWL)) Working Group WG
>Subject: Proposal to resolve ISSUE-67
>> The mapping rules use RDF reification.
>> However, RDF reification has very weak semantics, making it  
>> difficult to achieve an OWL Full semantics that works.
>> It is unlikely that  RDF graph's constructed with such rules mean  
>> what is intended.
>In the current mapping, we have:
>> Axioms with annotations are reified. If s p o is the RDF  
>> serialization of the corresponding axiom without annotations given  
>> in Table 2 and the axiom contains annotations Annotation(apIDi  
>> cti), 1 = i = n, then, instead of being serialized as s p o, the  
>> axiom is serialized as follows:
>> _:x rdf:type owl11:Axiom
>> _:x T(apIDi) T(cti) 1 = i = n
>> _:x rdf:subject s
>> _:x rdf:predicate p
>> _:x rdf:object o
>I believe the main difficulty is that in the RDF semantics
>_:x rdf:subject s
>_:x rdf:predicate p
>_:x rdf:object o
>does not entail
>s p o

True, this entailment does not hold.

Note that if a reified statement would entail the triple "s p o", then RDF reification would not be applicable for encoding negative property assertions.

In order to contribute to the further discussion about RDF reification and OWL-1.1-Full, here is, AFAICT, the precise OWL-1.0-Full semantics of RDF reification:

Derived from RDF semantics:

  rdf:subject rdf:type rdf:Property
  rdf:predicate rdf:type rdf:Property
  rdf:object rdf:type rdf:Property

Derived from RDFS semantics:

  rdf:subject rdfs:domain rdf:Statement
  rdf:subject rdfs:range rdfs:Resource

  rdf:predicate rdfs:domain rdf:Statement
  rdf:predicate rdfs:range rdfs:Resource
  rdf:object rdfs:domain rdf:Statement
  rdf:object rdfs:range rdfs:Resource

  rdf:Statement rdf:type rdfs:Class  # entailed

OWL-Full entails all the above triples with the following URI substitutions being performed:

  rdfs:Resource	--> owl:Thing
  rdfs:Class 	--> owl:Class
  rdf:Property 	--> owl:ObjectProperty

BTW: I have often seen people being puzzled about the mysterious semantics of RDF reification given in 


I claim that one can savely ignore everything which is written in this section. It is marked to be a pure *MAY* semantics, and it is only targeted to /extentions/ of RDF, not to RDF itself. None of the extentions of RDF which are relevant for our purpose of standardizing OWL-1.1-Full, namely RDFS and OWL-1.0-Full, have adopted this optional semantics.

>The proposed resolution is to have the triple {s p o} also serialized.

I agree!

>Consider an axiom from OWL 1.0 whose mapping, barring annotations,  
>remains the same in OWL 1.1. Suppose that axiom is mapped to {s p o}.  
>If we now look at the situation in 1.1 we see that the same axiom  
>with an annotation has a few more triples (the reifying triples), but  
>is also *missing* the triple {s p o}. From an RDF point of view,  
>adding an annotation to an axiom is nonmonotonic.

Syntactically, this is pretty confusing, IMHO.

>Putting {s p o} back in the mapping means that adding an annotation  
>to an axiom only means adding some triples to the serialization. I  
>believe that this means that the OWL Full semantics has an easier job  
>handling the annotated axioms. Rather than have to start with the  
>weak semantics of the reified triples and reconstitute entailments  
>that would follow from {s p o}, they instead only need to account for  
>the additional implications of the reifications of the triples.  
>Because the semantics of reifications is so weak, I expect that this  
>will be relatively simple, but I defer to Michael to comment on this.



I propose 1.1-Full semantics which entail the original axiom triple from the reified version. This can be regarded as a kind of "repair" semantics. Without this, the Full-semantics of the original axiom would simply be non-available, if an axiom is annotated. However, if the original axiom triple would remain in the RDF graph, then it would probably not be necessary to define additional 1.1-Full semantics for axiom annotations.

>I note that making this change has the side effect that in the case  
>that there are two almost identical axioms, differing only in that  
>one has an annotation and the other not, it will not be possible to  
>faithfully roundtrip. This is because in this case we will have (for  
>our example above) two {s,p,o} triples generated, but the RDF will  
>collapse this in to one. I don't personally consider this a problem,  
>but if a tool desires to remember that a particular axiom doesn't  
>have an annotation, it can annotate this axiom with an (optional)  
>Annotation(syntaxHint ThisAxiomHasNoOtherAnnotation).

Consider the situation, where an axiom A := "s p o" is contained in an ontology O1, which is imported into a different ontology O2, and O2 annotates the axiom A. Then the axiom /closure/ will contain *both* the encoding of the original axiom *and* the reified version. So it seems to me that it would be just consequent to have both encodings even in the same ontology.

>One last issue is the question of whether a blank node _:x should be  
>used in the mapping rather than giving an explicit name to the  
>If this raises any issues in the OWL Full semantics then  
>I suggest that we generate a unique name for the axiom in the OWL1.1  
>namespace. I believe that it would be adequate to use the URI that is  
>the concatenation of the expansion of owl11:aa_, the time of  
>serialization(as would be encoded for xsd:dateTime), and and an ascii  
>encoding of the md5 of the functional syntax expression of the axiom.  
>However, nothing should depend on the actual naming convention.

I did not experience any problems with having a bNode in the RDF mapping. If you look again at 


then you will see that the "main semantic condition" there does not deal with the "bNode vs. URI" question at all (in analogy to the way semantics are defined for multi-triple constructs in 1.0-Full).

I therefore opt for keeping the bNode in the mapping, because this is the "canonical" way to encode reified statements. And it is of course much easier to deal with (no need to create and process certain URIs).


My personal preference is:

  (1) Have both the original axiom and the reified statement in the RDF graph.

  (2) Avoid using the RDF reification vocabulary. Instead, use a shadow vocabulary specific to the task of encoding axiom annotations: 

     { owl11:Axiom, owl11:axiomSubject, owl11:axiomPredicate, owl11:axiomObject }

The latter preference is *not* semantically motivated, because I don't see any immediate semantic issue with using RDF reification for axiom annotations. 

But politically, I believe it is better to avoid the RDF reification vocabulary in OWL-1.1-Full. I know that a lot of people in the SemWeb community dislike RDF reification. And I see no need to annoy these people, if there is a simple and straightforward technical workaround.


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

Received on Monday, 24 March 2008 10:49:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:03 UTC