Re: Use cases for Reification in RDF Triple stores

> --Apple-Mail-2-1029770486
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> 	charset=US-ASCII;
> 	format=flowed
> Our experience with Jena has exposed some glaring performance weaknesses
> in its implementation of reified statements. We hope that these problems
> will be rectified in the upcoming Jena 2.0. However, the issues that
> surface will have to be addressed by any triple store implementation.

I doubt it.  Straightforwardd implementations of RDF 1.0 reification is almost 
guaranteed to be non-scalable.  We ran into this problem years ago, which is 
just one of the reasons I avoid reification like th eplague.  There are 
actually even more important reasons to avoid reification, as I've posted here 
often enough.

> In some of our applications the truth of a statement (triple) is 
> relative
> instead of absolute, ranked according to a probability or to a degree of
> trust.


> Secondly, there should be a 'bit' that API users can use to mark
> statements as true or not. However, it really should be 'wider' than a
> single 'bit'. Give us enough bits (e.g., make it a resource), and we can
> use such an attachment to build our own context mechanisms.

4Suite, the RDF processor I use and co-develop provides this in the form of 
scopes.  This is similar to what others call contexts and other things: 
basically another item in te statement tuple which can be any resources.

This sounds like what you're looking for, and rightly so.  In almost every 
case where I've seen reification use, inclouding managing truth and confidence 
values, I use conjoining blank nodes or scopes instead.  More scalable, more 
sound from a modeling POV.

Uche Ogbuji                                    Fourthought, Inc.
A Python & XML Companion -
XML class warfare -
MusicBrainz  metadata -

Received on Monday, 6 January 2003 11:05:53 UTC