W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: RDF-ISSUE-25 (Deprecate Reification)

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 11 Apr 2011 14:02:57 -0500
Cc: RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <F28DA835-D18D-426C-AC9F-AFF3075F5CFF@ihmc.us>
To: Sandro Hawke <sandro@w3.org>

On Apr 11, 2011, at 12:06 PM, Sandro Hawke wrote:

> On Mon, 2011-04-11 at 11:43 -0500, Pat Hayes wrote:
>> On Apr 10, 2011, at 11:50 PM, Sandro Hawke wrote:
>>> On Sat, 2011-04-09 at 08:49 -0500, Pat Hayes wrote:
>>>>> ] ISSUE-25 is about the RDF reification vocabulary, which is a
>>>>> ] built-in vocabulary for reifying *statements*. You are talking 
>>>>> ] about a common modeling practice in domain vocabularies for
>>>>> ] reifying *relationships*. That has nothing to do with ISSUE-25.
>>>>> Right, that was what I wanted to have explicitly clear. It's not the
>>>>> idea or practice of reification that is to be deprecated but the
>>>>> baked-in support for reifying binary relations.
>>>> No, really, you have this wrong. It IS the idea of reification that is
>>>> being deprecated; and this device that you have mentioned, of encoding
>>>> an n-ary relation using a bundle of binary 'role' relations, is NOT
>>>> reification. The two things are distinct. Using the name of one to
>>>> refer to the other is going to cause a lot of confusion. Reification
>>>> is using RDF to *describe* other pieces of RDF. 
>>> Pat, I'm a little confused here.   What I think William is saying sounds
>>> right to me, so I don't know why you're calling it wrong.
>>> If we have ternary relationship "showing", between a movie, a show-time,
>>> and a theater, and we want to represent that in RDF, we have (as you've
>>> both pointed out) several options.   If we have a lot of similar ternary
>>> relations, we might choose a  generalized representation like this:
>>> [ :ternaryRelation movie:showing;
>>>  :op1 "The Sound of Music";
>>>  :op2 "2011-04-11T12:40:00Z"^^xs:datetime;
>>>  :op3 eg:SomeTheater ]
>>> We could of course do something similar for any particular arity
>>> relation.   If we did it for the 2-ary case it would look exactly like
>>> 2004 RDF reification, wouldn't it?
>> No. Well, maybe it would LOOK like reification, but it would not BE reification. 
> Hmmm, that's not where I was expecting you to draw the line.
>> A reification of an RDF triple *describes the triple*. These constructions don't describe any RDF, they simply are ways to express in RDF (ie using only binary relations) an n-ary relationship. The resulting RDF does not refer to any RDF syntax, it is purely about the things like dates and theatres and movies. 
> Let me try bisecting the space again:  Is it fine if I say
>  [ :binaryRelation book:author
>    :op1 "Herman Melville"
>    :op2 "Moby-Dick"
>  ]
> I'm giving :binaryRelation/:op1/:op2 the obvious meanings.  That is,
> this RDF graph containing three RDF triples is saying: there exists a
> potential 3-way relationship between a 2-way relationship (author) and
> two other entities (the strings "Herman Melville" and "Moby-Dick",
> respectively).

Are you saying the relationship *exists*, or are you saying it is in fact *true*, ie the relationship holds in this case, between these two entities? Because the first claim is close to vacuous (either vacuously true if you are a Platonist, or vacuously false if you are a nominalist, but nothing to do with the particular facts, either way.) And the second is what the plain RDF triple 

:MobyDick  book:author "Herman Melville" .

would be saying. And the RDF reification vocabulary means the first, not the second. (Well, actually, it means that an RDF triple exists, in fact, rather than a relation exists, but whatever. It does not mean the same as the unreified triple, is the point. ) 

> Does that cause the same problems are RDF reification?

The issue is not so much that RDF reification causes problems as such, but that it gets mis-used and this mis-use causes problems. Plus, it has almost no real-life uses that in fact conform to its actual meaning, AFAIK. 

>> By the way,this basic idea, of re-expressing n-ary relationships as bundles of binary relationships, often called 'roles', pre-dates RDF by about half a century. It has been widely used in linguistic modeling because it provides for sentences like "He did it at midnight, in the kitchen, with a knife, carefully, silently,...." where one can pour on additional qualifications seemingly for ever, without changing the essential logical form. The fact that is is always possible (well known to people like Guha and Ora and others) was one reason people were willing to settle on a binary format for RDF in the first place. Just to emphasize that there is nothing exotic going on here.
> Well, I'm trying to find the line between this "nothing exotic" and
> pariah reification. 

To my mind, the fact that you seem to want to use it in a way that violates what the RDF specs say about it is itself a neat example of the dangers. 

>>> Now, William's example [1] was more like:
>>> [ a movie:Showing;
>>>  movie:title "The Sound of Music";
>>>  movie:showtime "2011-04-11T12:40:00Z"^^xs:datetime;
>>>  movie:theater eg:SomeTheater;
>>> ]
>>> ... but the difference between my two examples doesn't seem to me to
>>> cross a bright line, where the first is the evil reification and the
>>> second is recommended practice.  If you see a bright line there, could
>>> you try to make it more clear for me what exactly it forbids?   
>> RDF reification is using a specialized RDF vocabulary (not an open-ended vocabulary) to describe the *syntactic form* of other RDF triples. It is RDF used as a meta-language for RDF. 
> What if the RDF WG removes RDF reificaition from the specs, and the next
> week someone comes along and defines it all over again, rdft:Statement,
> rdft:subject, rdft:predicate, rdft:object.   
> Would that raise the same dangers?   

As long as they use it consistently in some way, and everyone else also uses it in that way, no problem at all. But I would like to see a case made out for having it around at all, as every example I have seen could be done better some other way.


>   -- Sandro
>> Pat
>>> Thanks.
>>>    -- Sandro
>>> [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0232.html
>> ------------------------------------------------------------
>> IHMC                                     (850)434 8903 or (650)494 3973   
>> 40 South Alcaniz St.           (850)202 4416   office
>> Pensacola                            (850)202 4440   fax
>> FL 32502                              (850)291 0667   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 11 April 2011 19:03:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:58 UTC