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

Re: Axiom annotations

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Thu, 19 Apr 2007 23:54:38 +0100
Message-Id: <B53738FF-8690-452E-90C7-F05A8C398C78@cs.man.ac.uk>
Cc: public-owl-dev@w3.org, Holger Knublauch <holger@topquadrant.com>
To: Michael Schneider <m_schnei@gmx.de>

On Apr 19, 2007, at 9:38 PM, Michael Schneider wrote:

> [@Holger: cc'd to you to let you know, because parts of this mail  
> are citing you or are about Topbraid Composer]
> [@Bijan: This is a reply to both of your answers]
> Bijan Parsia wrote on Wed, 18 Apr 2007, 21:36:57 +0100:
> > On Apr 18, 2007, at 8:49 PM, Michael Schneider wrote:
> >
>>> Wouldn't the introduction of RDF reification into the OWL2RDF   
>>> mapping exclude the reification vocabulary from being used in  
>>> OWL  axioms?
> [...]
>>> Until now, reification hasn't been blacklisted in
>>>   http://www.w3.org/TR/owl-semantics/mapping.html#4.2
>>> but then it would probably be.
>>> Again, yet another widely used feature of RDF which is going to  
>>> be  forbidden in OWL.
>> Some might take issue with the terms "widely used" and "feature"  
>> when  applied to reification.
> I remember an entry about reification in Holger Knublauch's  
> Topbraid Composer (TBC) Blog:
> <http://composing-the-semantic-web.blogspot.com/2006/07/reifying- 
> reified-relationships.html>
>    "In our recent modeling exercises with real-world customers
>    it became (once more) evident that reified relationships
>    are a key requirement in many domains."
> So (as Jeremy already reported for the case of Jena users) there  
> seem to be quite a few people who really use reification.

There are lots of ways to reify and one needn't use the rdf  
vocabulary to do it. For example, when you encode n-ary relationships  
as objects you are reifying those relationships.

There are *lots* of use cases for reifying or some other sort of  
comments on entities and axioms.

That's not the same as saying that RDF reification is a good thing.

I'm sad if people are using it. However, I still hear *no numbers*.  
And the only reification I've ever seen, personally, is EARL and OWL  
1.1's RDF mapping.

OWL-S reifies composite processes and doesn't use the RDF reification.

So I remain unconvinced. I agree with the need for certain mechanisms  
100%. I disagree that RDF reification is a serious or workable  
solution. I argued against it in the RDF mapping and I argue against  
it in general.

> Bijan Parsia wrote on Wed, 18 Apr 2007, 21:55:38 +0100:
>> On Apr 18, 2007, at 9:36 PM, Michael Schneider wrote:
>>> If I correctly understand Alan's above citation from the draft,   
>>> this is meant as an "EITHER s p o OR reification" (whatever form  
>>> of  reification will be used in the end).
> [...]
>>> Really, I would prefer to have a "ALWAYS s p o AND ADDITIONALLY   
>>> reification IF NEEDED FOR ANNOTATION".
>> This is possible but a bit dangerous. There is no connection  
>> between  the reification and the regular, thus it's possible for  
>> them to get  out of synch. If they do get out of synch, how do you  
>> know that your  annotation is annotating *that* axiom?
> Hm, can you please elaborate on this argument a little more? I am  
> not sure if I really understand it completely.
> What do you mean by "no connection"?

Take the following graph:

:s :p :o.
_:x a rdf:Statement;
	rdf:subject :s;
	rdf:predicate :p;
	rdf:object :o.

Now consider changing the predicate of the first triple to p1. What  
happens to the reification?

Nothing, and arguably nothing *should* happen. But if you are going  
to use the reification to hang metadata *on this very triple in this  
very graph* then there *needs* to be a connection.

Ok, we can hook it up in an application dependent way. It's not  
*impossible*, just neither interoperable nor particularly pleasant.

> When I have an RDF file containing an spo statement and a reified  
> statement, I don't see any difficulties to decide in any possible  
> case, if the reified statement is a reification of the spo  
> statement or not.

If you go back to the great reification debates, one thing you'll  
find is the question of whether a reification reifies the *particular  
utterance*, so to speak, of a triple, or the *triple type*. In other  
words, in the following graph:

:x1 a rdf:Statement;
	rdf:subject :s;
	rdf:predicate :p;
	rdf:object :o.
:x2 a rdf:Statement;
	rdf:subject :s;
	rdf:predicate :p;
	rdf:object :o.

should we conclude that :x1 = :x2?

One of the many things that need to be settled.

And again, what happens if you have only a couple of the parts of a  

> So I would say that there is a pretty strong connection between an  
> spo statement and its reification, at least when it is in the same  
> file/ontology. Am I wrong?


> And what exactly do you mean by "getting out of sync"? Do you mean  
> some situation of the kind where I change e.g. the subject of the  
> spo statement, but forget to also update the rdf:subject's value of  
> the reified statement?


> Such an accident is, of course, always possible, not only for  
> reified statements. For instance, if I have an EnumeratedClass E  
> and change the URI of one of its instances i in the Description of  
> i, than I have to update this instance's URI in the 'oneOf' list of  
> E, too.

Didn't quite follow that, but there's a pretty big difference in  
finding and replacing a URI and having to do the complicated surgery  
between a reification and the original.

Tools make it easier, but then what do you care about the underlying  

> Such kinds of mistakes can easily happen when doing /manual/ editing.

I thought that was a precondition of this discussion given all your  
talk about looking at the RDF.

> But, personally, I nearly never edit ontologies without a proper  
> tool (exceptions are sometimes trivial ontologies for demonstration  
> purposes in mailing list postings).

Then I don't understand why we are even having this conversation :)

> For example, I have just created an ontology with the Topbraid  
> Composer (TBC) ontology editor, containing a single statement 'i1 p  
> i2', and then I reified this statement (reification of statements  
> is directly supported by TBC in a pretty convenient way). Then, I  
> changed the name of individual 'i2' to 'i3'. This changed both, the  
> object name of the regular statement, and the rdf:object's value of  
> the reified statement. So no danger of getting out of sync here!

But then what do you care about the "big honking chunk of  
reification" in your ontology? The tool will take care of it.

> I still prefer the approach of having /always/ spo, and only  
> additional reification, if needed!


> >> So my XML serialization would be even /smaller/ in comparison with
> >> reification without the s p o triple included.
> >
> > Uhm....how is this smaller than just having the reified one using  
> the
> > syntactic trick? I'm missing something.
> AFAIK the ID trick only works with /existing/ spo statements.

My mistake. They do indeed generate both the triple and the  
reification of that triple. I misremembered that it only produced the  

> So in order to specify in RDF/XML a reification /without/ also  
> having the associated spo statement, you have to explicitly write  
> down the full form of reification. This will (in general) produce  
> larger serializations (measured in bytes), I suppose.


> BTW, Topbraid Composer also applies the "rdf:ID in properties"  
> trick of RDF/XML, when storing the created ontology into a file.  
> Though I think that this is in fact done by the Jena RDF/XML  
> serializer, which I think is used internally by TBC. Holger will  
> certainly know for sure (and Jeremy has already confirmed that Jena  
> uses the ID trick).

The ID sugar *is* very convenient and even for hand writing it. So  
yeah, given that, it's actually easier to keep them in synch by hand  
as well if you use that serialization.

I'm loathe to use reification in general, but if we do, then given  
this bit i see no reason for including both. I'm convinced enough to  
suggest that you file a bug report in the owl 1.1 issues list.

Received on Thursday, 19 April 2007 22:54:52 UTC

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