Re: Blank nodes and SQL sequences

On 07/09/12 13:53, Richard Cyganiak wrote:
> Jena, I believe, assumes “one big universal sequence of blank nodes in the sky”, and the uniqueness of values within the sequence is only stochastically guaranteed.

(digression)

Yes, it assumes it although the implementation is currently weak in one 
place.  It will be soon be universal.

((
Our test case is can you take a (triple using a) bNode out of one graph, 
use it in another, then put it back in the original graph and it be the 
same (API calls only).  It makes subgraphs work. In the API, the bNode 
retains it's identity.
))

Teh internal id is based on a java.net.UID so they are guaranteed unique 
per machine give or take messing around with the clock.  (Java RPC 
relies on them.)

They are not quite strong enough in theory and only moderately 
statistically unique across JVMs.  But as you can't move them from one 
JVM to another without using an RDF serialization, it is not observable.

On 07/09/12 14:55, Steve Harris wrote:
 > Well, my impression is that Jena uses something closer to a UUID.

It will be a UUID based "soon" -- we have both v1 and v4 generating code.

Richard:
> (I believe in Jena, API users can assign their own non-UUID labels, so the situation might be more complicated there.)

Yes, but the parsers in normal operation do not do this.

There are ways of bypassing it for debugging purposes - there is a way 
to get internal ids allocated as 1,2,3,4,...  If the system allocates 
them in a multi-run safe manner (as normal), then their hashes change 
each program run ... and the order in hash tables changes ... so order 
of encountering when enumerating set membership is non-deterministic 
behavior.  Which is tricky.

The ways of creating controlled internal ids are not for normal operation.

	Andy

Received on Saturday, 8 September 2012 15:44:24 UTC