Re: deterministic naming of blank nodes

On 2015-05 -20, at 23:55, David Booth <david@dbooth.org> wrote:

> 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.

But you can of course in practice reference them indirectly with a path in a WHERE clause.
There are lots of different reasons why this works in different cases.

- You can make a patch which must be applied to to the original graph only -- or you can make a patch which usefully applied to different versions of the same graph.
- You can use knowledge of things being functional properties to guarantee that a path is universally unambiguous -- or not use it
- You can build systems where an attempt to delete a subgrah which does not exist is an error -- or where it isn't 
- and so on

But in general SPARQL Update is pretty useful.   So is the new patch format from LDP.
So what seems reasonable is to have utility code which takes a set of triples to delete a set of triples and add a set of triples, where the triples can include bnodes, and have the library create the necessary WHERE clause, with options to address some of the options above.  

(All this of course much discussed in 2001 in http://www.w3.org/DesignIssues/Diff )



>  (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
> https://lists.w3.org/Archives/Public/public-sparql-dev/
> to see what others there think.
> 
> David Booth
> 
> 
>