On 18/07/11 20:47, Andy Seaborne wrote:
On 18/07/11 19:47, Benson Margulies wrote:
Asking a tdb model to list reified statements, I see two:
urn:jug:1a2b3c#rr1=>[urn:jug:global#per1,
http://jug.basistech.com/2011/01/rex-entity#coOccurInSentence,
urn:jug:global#per2]
urn:jug:2b3c4f#rr1=>[urn:jug:global#per2,
http://jug.basistech.com/2011/01/rex-entity#hasSibling,
urn:jug:global#per2]
i then call removeReification on [urn:jug:global#per2,
http://jug.basistech.com/2011/01/rex-entity#hasSibling,
urn:jug:global#per2], and BOTH reifications are deleted.
Does this make any sense, or is it time for a JIRA?
Could you reduce it to a test case with data?
TDB has it's own reification which is supposed to be equivalent to
Standard (com.hp.hpl.jena.sparql.core.Reifier2) which works by using
only information stored in the base data.
Chris and I think (or at least at the time!) this is the better
long-term future for reification. Come Jena3, we might put reification
in only in the Resource API, remove from the graph/storage layer. That's
what Reifier2 is supposed to do.
Your use case is possible one of the few where reification makes sense -
many of the rest of the usages for provenance work on more on one triple
so reification becomes unmanageable.
The Jena reification mechanisms don't always work out very well because
they depend on state in the reifier, which is bad on persistence.
Reifier2 is an attempt to have stateless but useful reification handling.
It was an old-fashioned bug in Reifier2, rather a problem of reification
and storage.
Andy
