[Mulgara-general] Jena-Mulgara connector

Paul Gearon gearon at ieee.org
Sun Jan 13 21:54:49 UTC 2008

On Jan 13, 2008, at 2:03 PM, Seaborne, Andy wrote:
> Andrae Muys wrote:
>> If the problem reusing a blanknode from a query for an insert, as
>> long as you perform the query within the same write-phase you will be
>> fine.  Mulgara's understanding of insert/delete is as functions from
>> graphs to graphs, ie:  insert :: Triple -> Graph -> Graph.
> Let me just check my understanding: if the app (from iTQL or from the
> remote API) inserts a bnode in an operation, deletes said bnode in a
> second operation, then it's id can be reused even inside the same
> transaction in some later operation.

Let me explain a little more.

All statements in Mulgara are a quad of gNodes (graph nodes).  The  
fourth is a URI for a graph, and can effectively be ignored in most  

gNodes fall into 3 categories.  They can be mapped to URIs, they can  
be mapped to literals, or they are mapped to nothing.  If they are  
mapped to nothing, then they represent a blank node.  We convert this  
into a string (for output) with the format _:nnn (where nnn is the  
gNode value).  A blank node CANNOT be referred to with this syntax.   
It is for output only.

When any resource is "released" (meaning that the last statement using  
this resource has been deleted) then the gNode for this resource is  
made available again.  Any new resource that is allocated will need a  
gNode, and the released values are picked up before new ones are  
allocated.  Note that this gNode can now refer to ANY resource, not  
just a blank node!

Also, any gNodes released in the current phase are preferentially re- 
allocated first.  Without that particular heuristic, a process that  
rapidly alternates between inserting and deleting data will create  
significant load on the system.  So when you say that a bnode's ID  
*can* be reused inside the same transaction, I would change that to  
say that it is almost certain that the ID *will* be reused.

However, once a newer transaction exists, any released gNodes are not  
available again until all old read operations have closed.

> If a trasnaction (i.e. handle to one graph at one point in time) does
> nothing but read operations, then the bnode id is stable.


>> In other words our current semantic is that the result of an update
>> operation on a graph is a new graph, and as such blank-nodes from the
>> pre-update graph are not necessarily the same as the blank-nodes on
>> the post-update graph.
>> So a mulgara instance consists of a sequence of 4-uniform hypergraphs
>> defined as the graphs produced by a sequence of unification and
>> restriction operations starting with an empty graph, and we call the
>> resulting ordinal number of a given graph a phase.
>> This idea of graph immutability (operations don't change the graph,
>> but produce a new one) has formed the basis of our thinking regarding
>> blank-nodes and their interaction with transactions and queries.  As
>> a result your blank nodes remain valid for the duration of a
>> transaction, for the moment that means holding the write-lock,
>> however over the next few weeks we will be introducing the ability to
>> obtain read-only transactions which will help alleviate some of your
>> blank-node problems.
> Sounds interesting - any description of the read-only transactions  
> features?

Andrae has much more to say, but I'll put in my 2c worth (or 2p for  
you UK types).  Up until now, an answer from any kind of read  
operation would always come from the latest version of the database.   
This would always be consistent, and is attached to a phase on disk.   
However, there was no way to get another read to come from that same  
phase, unless you happened to be holding the write lock.  The new  
transaction code lets you keep hold of a read-only phase to perform  
queries on.  This lets you get multiple consistent reads without  
holding the write-lock.  "Consistent" here also means that the ID  
associated with a bnode will not change from one read to the next.

> I've already added basic graph pattern support to JenaMulgara so that
> conjunctive triple patterns are sent as a single operation.  That
> reduces the bnode effects so that if the app sticks to the Mulgara way
> of doing it, it can ask BGPs.
> ------
> Are there plans to support language tags and handle xsd decimals  
> (where
> they contain a fractional part)?

Language tags: no, but that's more because it's been overlooked.  The  
XA2 design is still being finalized, so this should be added, if it's  
not there already.  (Andrae?)

XSD decimals: the full floating point value is stored and retrieved  
already.  Or are you referring to rational numbers?  The answer to  
that would be no.  Maybe you mean the string version of the decimal  
value?  (since this often must be approximated in a binary  
representation).  Again, the answer would be no.  Or am I missing the  
point in this question?


More information about the Mulgara-general mailing list