W3C home > Mailing lists > Public > www-rdf-interest@w3.org > August 2004

Re: Reification - whats best practice?

From: Sandro Hawke <sandro@w3.org>
Date: Thu, 26 Aug 2004 08:29:13 -0400
Message-Id: <200408261229.i7QCTD1R008930@roke.hawke.org>
To: Bob MacGregor <macgregor@isi.edu>
cc: Leo Sauermann <leo@gnowsis.com>, "'RDF interesting groupe'" <www-rdf-interest@w3.org>

> >While I'm fond of quad stores (eg in cwm and SWI prolog) and
> >agree they're generally the way to go -- how do you propose exchanging
> >quad-store data?   My store knows that source x said {a b c}, but how
> >do I publish that fact?
> >  
> >
> Easy.  You create a context C containing all of the triples that "x 
> said", and assert that
> "x said C".  If x said only one statement, then there is one context per 
> statement.  However,
> in practice, the things that "x said", or "x authored", or whatever, 
> tend to come in bunches,
> so contexts win out over reified statements almost always.

Sorry if I'm being dense, but how are you proposing that one agent
(Alice) "create a context C" for another agent (Bob), so that her
telling him "x said C" is useful?

The obvious approach I see is that Alice makes C available as a web
page; Bob can dereference the URI C and get the triples in the
context, if he wants to.  I think this is effectively what DanBri
suggested, although he's thinking of the URI as identifying a document
which is a serialization of the contents of C, and I think of the same
URI as identifying an RDF Graph, a representation (serialization) of
which can be obtained over the web.  Probably different words for the
same behavior.  I agree it's pretty simple and it works.  (My code
words that way, although I haven't actually got around to Alice and
Bob talking; I just have each server answer web requests for each
stored graph/context.)

But anyway -- that approach wont make everyone happy.  Is it good
enough?  (Maybe it only has to be better than RDF Reification, which
isn't hard.)

         -- sandro
Received on Thursday, 26 August 2004 12:25:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:52 UTC