W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2012

Re: "Fresh" blank nodes vs. RDF Merge in Update

From: Axel Polleres <axel@polleres.net>
Date: Tue, 12 Jun 2012 20:04:43 +0200
Message-Id: <82AA60A3-F37E-4E70-857A-84467B502763@polleres.net>
To: public-rdf-dawg-comments@w3.org
Hi Kjetil,

This is in reply to your comment 

While you are correct that the behaviour for InsertData on a single 
graph corresponds to RDF-merge, note the insert data operation is 
defined on QuadPatterns, i.e. allows the simulatanous update on updates 
of several graphs.


 INSERT DATA { GRAPH <g1> { _:b1 :p :o} GRAPH <g2> { _:b2 :p :o} }

would be perfectly fine.

As you will see, in the formal definition of the InsertData operation, cf.
it is defined in terms of 

   OpInsertData(GS, QuadPattern) = Dataset-UNION(GS, Dataset(QuadPattern,{},GS,GS))

where the Dataset(...) function, cf. 
takes care of bnode renaming.

So, while in the special case of inserting data into a single graph this amounts 
to the same as RDF/merge in RDF-MT is only defined in terms of graphs, but not in 
terms of graph stores or RDF datasets, we would prefer to keep explanatory 
the text "as is".

We would kindly ask you to acknowledge that you are happy with this response,

Axel, on behalf of the SPARQL WG 

 > All,
 > I came across the following sentence in the SPARQL 1.1 Update spec:
 > "Blank nodes in QuadDatas are assumed to be disjoint from the blank nodes 
 > in the Graph Store, i.e., will be inserted with "fresh" blank nodes."
 > This sounds like the same as doing an RDF Merge as specified in RDF-MT. The 
 > HTTP Graph Store spec says that a POST should be an RDF Merge, and it 
 > equates it to an INSERT DATA, which makes it even more likely that the same 
 > thing is meant.
 > Is that correct, and if so, wouldn't it be more appropriate to reference 
 > RDF-MT normatively instead?
 > Best regards,
 > Kjetil
Received on Tuesday, 12 June 2012 18:08:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:30 UTC