W3C home > Mailing lists > Public > semantic-web@w3.org > May 2015

Re: deterministic naming of blank nodes

From: David Booth <david@dbooth.org>
Date: Wed, 20 May 2015 17:55:30 -0400
Message-ID: <555D02D2.5000804@dbooth.org>
To: Gregg Kellogg <gregg@greggkellogg.net>, "henry.story@bblfish.net" <henry.story@bblfish.net>
CC: ahogan@dcc.uchile.cl, semantic-web@w3.org
Hi Gregg,

On 05/20/2015 05:07 PM, Gregg Kellogg wrote:
[ . . . ]
> Using a PATCH, you can’t reference existing BNodes. You _might_ be
> able to in an UPDATE, as I indicated. A PATCH is typically described
> as a series of deletes and adds (depending on the particular format);
> for most cases SPARQL Update probably covers the use cases better.
> My interpretation is that the deletes of a PATCH can’t really
> reference BNodes in any way, unless the entire graph is removed.
> Updates can, but they’ll always create new BNodes and can’t match
> against existing ones.

If both client and server are working from the same known base-point, 
and the PATCH is viewed as operating on the canonical *serialization* of 
an RDF graph, such as in N-Triple, then it should work fine, just as 
with any other text file.

However, currently there would be a problem in applying that PATCH to 
RDF that is stored in a SPARQL server, because currently there is no 
standard way to directly refer to a bnode from a separate SPARQL 
operation.  This is a known problem already with SPARQL, which causes 
grief when doing followup queries.  But if SPARQL servers were enhanced 
to (optionally) enable subsequent queries or update operations to refer 
directly to blank nodes by their *original* labels, then both PATCH and 
followup queries would work on SPARQL servers.  (In the case of implicit 
bnodes generated by Turtle/SPARQL [] or () notation the server would 
assign an original label.)  This seems like a good route to take, though 
it means adding that feature to SPARQL.  I'll send this to the SPARQL list
to see what others there think.

David Booth
Received on Wednesday, 20 May 2015 21:56:02 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:42 UTC