Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

BNode value not random enough #185

Closed
gjhiggins opened this Issue · 7 comments

4 participants

Graham Higgins Jörn Hees Gunnar Aastrand Grimnes Bertrand Croq
Graham Higgins
Owner

bcq.nng@gmail.com, 2011-12-23T16:13:30.000Z

When rdflib is used in a application that fork the current Python process, for exemple when using flup.server.*_fork, BNode's value generation in these processes:

  • share the same _prefix
  • use independant serial number generators that start with the same value

This means that the parent and child processes will all get the same BNode values.

I fixed this issue using

value = _unique_id() + str(random.randint(1, 99999999))

but there might be a cleaner solution.

Graham Higgins gjhiggins was assigned
Jörn Hees
Owner

Uhm, why not just use UUIDs?
For example uuid.uuid4()
http://docs.python.org/library/uuid.html#uuid.uuid4

Graham Higgins
Owner

Sound suggestion, IMO. I've covered this ground in a comment to issue #195 because using uuid4 BNode ids has the potential of supporting some of the set-theoretic graph operations.

uuid/4 was introduced in Python 2.5, so it has to be mimicked for 2.4

I set up a uuid solution (leaving the existing BNode private API undisturbed) and exercised it in a couple of tests, setting them to fail if the issue was solved:

https://github.com/RDFLib/rdflib/blob/master/test/test_issue200.py#L90 (issue 200 was the old gcode issue #)

So far, I haven't merged Bertrand's pull request because:

  1. the change in BNode private API results in the above-mentioned tests raising Exceptions (easily fixed)
  2. using the code in the pull request, the first of the two non-uuid fork tests continues to pass, thereby demonstrating a continued requirement for each forked process to initialise the random seed.

I do think the argument for a switch to uuid4 is fairly compelling.

Gunnar Aastrand Grimnes
Owner

Looking at this again I'd vote for UUIDs - do we have a source for a 2.4 compatible uuid faker?

Graham Higgins
Owner
  • do we have a source for a 2.4 compatible uuid faker?

There's a putative implementation here:

https://github.com/RDFLib/rdflib/blob/master/test/test_issue200.py#L17

where I created a solution for this issue using the tests as proof-of-concept.

All seems to be working according to the CI build, I think it's now just a matter of propagating the implementation back into the RDFLib source.

Bertrand Croq

I have just closed my pull request... my proposed fix was bcroq/rdflib@6e8aac9

Graham Higgins
Owner

Thank you for the proposed fix, Bertrand. It's great to see people pitching in.

BNode ids are declared to conform to NCName specs. Unadorned uuid4() won't the cut the mustard as a valid NCName due to its regrettable habit of randomly starting with an integer:

ParserError: None:6:2: rdf:nodeID value is not a valid NCName: 557cb5ba-9713-4b54-a2fb-65524e8154b1

My naive trial of a "urn:uuid:" prefix was also not valid:

ParserError: None:6:2: rdf:nodeID value is not a valid NCName: urn:uuid:a389b738-c914-42c0-06de-94e77112dabb

Comments in BNode.new assert:

# BNode identifiers must be valid NCNames" _:[A-Za-z][A-Za-z0-9]*
# http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/#nodeID

However, the NCName reference given in https://github.com/RDFLib/rdflib/blob/master/rdflib/namespace.py#L364 (as the implementation spec for RDFLib's is_ncname() test) no longer seems to describe the same specification as used in RDFLib. Is this worth looking at in more detail?

In the end, I used a deeply unimaginative "_" (underbar) prefix.

Graham Higgins
Owner

Fixed in commit #03c77ea0af

Graham Higgins gjhiggins closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.