W3C home > Mailing lists > Public > public-rdf-wg@w3.org > September 2012

Re: Scope of blank node labels in TriG/N-Quads

From: Steve Harris <steve.harris@garlik.com>
Date: Thu, 6 Sep 2012 18:52:03 +0100
Cc: Sandro Hawke <sandro@w3.org>, public-rdf-wg@w3.org
Message-Id: <2D023B09-685C-41CB-9BC5-2017B3574E18@garlik.com>
To: Richard Cyganiak <richard@cyganiak.de>
On 2012-09-06, at 14:36, Richard Cyganiak wrote:

> On 6 Sep 2012, at 04:21, Sandro Hawke wrote:
>>> First, backups/restores of graph stores. This can be addressed using skolem IRIs.
>> What if the graph store already has both Skolem IRI nodes (acquired from Web crawling) and blank nodes?   How can you make the backup/restore faithful?
> [[
> Systems may wish to mint Skolem IRIs in such a way that they can recognize the IRIs as having been introduced solely to replace a blank node, and map back to the source blank node where possible.
> ]]
> http://www.w3.org/TR/rdf11-concepts/#section-skolemization
> IOW, a store can mint the skolems in a way that allows it to tell apart its own skolems from crawled skolems. That's easy enough to do. I believe Steve said that 4store or 5store already implement it this way.

Correct, but that's back to exactly the same store (with the same UUID). Offhand I'm not sure what would happen if you restore back to a store with another UUID (e.g. a mirror, or fresh hardware), I don't think it would work. I think the Skolem constant URIs will have the same scope as bNode labels.

It could be made to work, by giving them different scope, but it would be a little funky.

At the risk of repeating myself: the idea of scoping bNode labels to the document makes me a little uneasy, but I doubt it will be the end of the world (our community has made much worse decisions) and consistency is more important.

- Steve

Steve Harris, CTO
Garlik, a part of Experian
+44 7854 417 874  http://www.garlik.com/
Registered in England and Wales 653331 VAT # 887 1335 93
80 Victoria Street, London, SW1E 5JL
Received on Thursday, 6 September 2012 17:52:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:07 UTC