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

[GRAPHS] Re: RDF-ISSUE-25 (Deprecate Reification)

From: Sandro Hawke <sandro@w3.org>
Date: Mon, 11 Apr 2011 17:06:27 -0400
To: Richard Cyganiak <richard@cyganiak.de>
Cc: Pat Hayes <phayes@ihmc.us>, RDF Working Group WG <public-rdf-wg@w3.org>
Message-ID: <1302555987.6968.52.camel@waldron>
On Mon, 2011-04-11 at 12:14 +0100, Richard Cyganiak wrote:
> Sandro,
> 
> The modeling practice for n-ary relations is about describing *an n-ary relationship that exists in our domain model*.
> 
> The RDF reification vocabulary is about describing *RDF triples*.
> 
> Both approaches have one thing in common: They tackle the problem of describe something as triples that isn't naturally possible in triple form, by re-writing the thing in a clever way as triples.
> 
> The difference is that in one case, the “thing” is a relationship in the modeled domain. We turn something that “wants” to be a property into a class when we design our domain vocabulary. In the other case, the “thing” is the data model itself. We turn something that *already is* a triple (arc) into a resource (node).
> 
> In the former case, everything happens as part of the modeling process, before we even get to the point of using RDF. That's why it's ok.

Yes....

But what if your domain of discourse is the RDF graphs and triples
people are publishing, because you're a metadata management system, or a
trust reasoner?

That would seem to cross these lines.  Then your domain model does
include rdf:Statements, whether you call them that or not, or something
very much like them.

You end up being able to use RDF tools to do everything but this, if you
disallow this from RDF.   Maybe that's okay.

> The latter, on the other hand, is an operation that really ought to be part of the definition of the data model itself. To make effective use of RDF reification, one needs special APIs and stores with native reification support anyways, and one really wants formats that natively can serialize reification quads, for readability, writability, compactness, and efficient parsing. When one uses RDF reification, one has to deal with two ways of “reading” a graph: (a) by looking at subject-predicate-object triples, (b) by looking at reification quads and interpreting them as triples. None of the proposed alternatives (quads, named graphs, quoted graphs, graph literals) share that awkward property -- all of them allow making statements about statements/graphs without transforming the graph into a completely different shape.
> 
> In summary, by turning triples into resources, one gains the ability to (indirectly) say things about the triple, but one pays a high price. Hardly anyone is willing to pay that price, as evidenced by the low level of support for the reification vocabulary in tools and by data publishers.

I think it's also plausible that the lack of adoption is due to other
causes -- like that fact that's not sufficiently or properly defined or
documented.  

Anyway -- by all means lets see if we can use something like TriG to
address the GRAPHS uses cases.   I suspect reification will end up being
important for some of them, but I'm going to try to stop talking about
it.

    -- Sandro

> Best,
> Richard
> 
> 
> On 11 Apr 2011, at 05:50, 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?
> > 
> > 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?   Thanks.
> > 
> >     -- Sandro
> > 
> > [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0232.html
> > 
> > 
> 
> 
Received on Monday, 11 April 2011 21:06:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:41 GMT