CommentResponse:KK-15

Hi Kjetil,

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.

e.g.

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. http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#def_insertdataoperation it is defined in terms of

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

where the Dataset(...) function, cf. http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#def_datasetQuadPattern 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