Re: a blank node issue

>>>>> Jonathan Rees <jar@creativecommons.org> writes:

 >> There is already a convention/standard for skolemising blank nodes:
 >> just use a URI instead.

 > Richard's exactly right, and there's a very nice lightweight (and
 > registered!) URI scheme that would work for this purpose, namely tag:
 > - http://www.ietf.org/rfc/rfc4151.txt

 > I think that would serve well here. You just need an install step for
 > any software generating these things that provides it with a suitable
 > collision-avoiding prefix (email address or domain name). Then it can
 > use a combination of time and spin count to generate these
 > URIs.

 My personal preference would be to use RFC 4122 (urn:uuid:)
 instead, as it requires virtually no configuration.  (It will
 embed the hardware address of one of the Ethernet NIC's, which
 are unique, into UUID's, iff time-based UUID's are requested.)

 > You'd want to review the security implications, but they're probably
 > not too bad.

 … Moreover, there's a provision for content-based UUID's, which
 means that, as per, e. g., [2], such URI's may be generated for
 entire (sub)graphs.  In particular, an URI may be generated,
 based on the (sorted?) sequence of (predicate, object) pairs
 associated with a particular blank node.  Which relieves some of
 the associated security implications.

 (Yet, it has to rely on a particular canonical representation
 for RDF graphs.  And none was proposed so far.)

 > If you're worried about turning them back into bnodes on reading in a
 > graph, then perhaps a new URI scheme registration is needed, or maybe
 > a special convention for use of tag: can be agreed on. Interesting
 > problem.

[1] http://tools.ietf.org/html/rfc4122
[2] http://www.hpl.hp.com/techreports/2002/HPL-2002-216.pdf

-- 
FSF associate member #7257