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

Re: Reification - whats best practice?

From: Bob MacGregor <macgregor@isi.edu>
Date: Wed, 25 Aug 2004 08:48:49 -0700
Message-ID: <412CB4E1.9050906@isi.edu>
To: Leo Sauermann <leo@gnowsis.com>
CC: "'RDF interesting groupe'" <www-rdf-interest@w3.org>

Leo Sauermann wrote:

> Hello,
> I need reification in gnowsis.org, so I wonder:
> - What is the recommended way to do reification in RDF/XML?
> - When I want to reify masses of statements (f.e. using Jena) the 
> storage space explodes (when using plaintext RDF/XML files). This is 
> awful, as reification would be real useful sometimes. Any best practice?

Reification in RDF is basically a huge mistake.  As you noted, storage 
space explodes.  Furthermore,
queries quickly become unreadable when using reification.  The RDF 
language would be healthier if
reification had never been introduced, because as it has now been cast, 
it points the way to a
technical deadend.

The right solution is to use contexts.  Contexts can be implemented 
using quads instead of triples,
or by using a scheme for encapsulating groups of statements, as is done 
in the Triple system.
The DAWG committee is taking baby steps towards contexts by including a 
SOURCE element
in BRQL.  If you substitute the term "context" for "source" in a BRQL 
query, then you have quads.
Some of us are planning to "abuse" BRQL by treating the sources as if 
they are contexts.  I would
not be surprised if members of the DAWG committee have that in mind (but 
I can't speak for them).

At some point in the future, quad stores are likely to become 
commonplace--there are a few
already.  Meanwhile, representation of provenance data in RDF is 
next-to-impossible from a
practical standpoint.

Cheers, Bob

Bob MacGregor
Chief Scientist

	Siderean Software Inc
5155 Rosecrans Ave, #1078
Hawthorne, Ca 90250 

bmacgregor@siderean.com <mailto:bmacgregor@siderean.com> 	
tel: 	+1-310-491-3424
fax: 	+1-310-491-3338




Received on Wednesday, 25 August 2004 15:49:28 UTC

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