[Mulgara-dev] Re: JRDF and blank nodes

[Andrew Newman]

On 10/20/06, Andrae Muys <andrae at netymon.com> wrote:
>
> I've been looking at the JRDF code to evaluate how to integrate it
> with the new transaction architecture.
>
> It appears the only place the JRDF code messes with transactions is
> in JRDFGraphElementFactory::createResource().
>
> Specifically this attempts to either resume or start a new
> transaction, and then creates a new blank node - persists it
> (allocates it a node-id from the node-pool), and returns it.
>
> What I am struggling to understand is why it needs to persist it in
> the first place?  What is the reasoning behind this?
>
> Particularly curious is the case where it starts a transaction in
> order to persist the blank-node; as the transaction is immediately
> terminated after this point, the node-id in the blank-node is
> invalidated and relying on it in anyway is an error anyway.
>
> Any insight you could provide would be greatly appreciated.
>
> Andrae
>

You are correct, blank node ids only have scope within a transaction
but automatically comitting and invalidating the blank node id would
prevent being able to offer a JRDF interface (or any graph like
interface that I know of).  It's the ability to generate or retrieve a
blank node id and keep the transaction that's important.

The uses cases I can remember are:
* Using a blank node across more than one triple insert, and
* Doing a find and then using that to do a subsequent find/insert/delete.

For instance, inserting triples in JRDF is a matter of: creating
nodes, creating a triple and then inserting them.  I'm not sure how to
offer a graph API that is implemented in another way.

I'm not sure I understand the difference between JRDF operations and
iTQL operations, iTQL operations allow inserts and insert/selects of
blank nodes.  To me, they are both, "do stuff in a transaction".