- From: David Booth <david@dbooth.org>
- Date: Wed, 01 Aug 2012 11:52:04 -0400
- To: Paul Gearon <gearon@ieee.org>
- Cc: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
On Wed, 2012-08-01 at 10:47 -0400, Paul Gearon wrote: > David, > > Thank you for your comment. > > David Booth wrote: > > In Section 3.1.4 LOAD: > > http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#load > > where it says: "The LOAD operation reads an RDF document from a IRI and > > inserts its triples" and a little later where it says "the resulting > > triples will be inserted" I suggest s/insert/merge/ to be clear that > > existing triples are deleted when the new triples are LOADed. > > > > Thus those phrases would read: "The LOAD operation reads an RDF document > > from a IRI and merges its triples" and "the resulting triples will be > > merged". > > Since both "insert" and "merge" imply new data and do not suggest the > removal of information, then am I correct to presume that when you > said, "existing triples are deleted," that you actually intended to > say, "existing triples are not deleted"? Oops! Yes, sorry for that typo. :( > > When the LOAD operation is executed, new data is added to the existing > triples in a graph. No triples will be deleted from the destination > graph. We believe that the word "insert" in the informal prose implies > this. The use of the word "merge" would imply "RDF Merge". This may be > essentially what a LOAD does, however the operation is described > completely independently of RDF Merge. The formal definition of LOAD > is in section 4.3.4, but to make it clearer in the prose we have added > the following: > > "If the destination graph already exists, then no data in that graph > will be removed." Good. I am satisfied with this resolution. Thanks! David > > We would be grateful if you would acknowledge that your comments have > been answered by sending a reply to this mailing list. > > Regards, > Paul Gearon, > on behalf of the SPARQL WG. > > -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Wednesday, 1 August 2012 15:52:33 UTC