- From: Axel Polleres <axel.polleres@deri.org>
- Date: Tue, 26 May 2009 20:41:09 +0100
- To: 'RDF Data Access Working Group' <public-rdf-dawg@w3.org>
Hi all, I am trying hard to get my head around the various update issues. First of all, the conclusions we seem to have reached today (objections please now, if any!): 1) it seems that all agreed that we need more than PUT/DELETE alone is needed. 2) it seems further that several people think that fixing a PUT/DELETE semantics for inserting/deleting data still would be desirable. Then there are some other issues floating around, e.g. a two-phase approach as suggested by andy, i.e. a minimal SPARQL update spec that only defines INSERT, UPDATE on a graph, but not on a graph store/on named graphs. Several of the use cases presented today, seemed to need updates on specific graphs, so that distinction might not be enough. Does that mean that we can propose to close http://www.w3.org/2009/sparql/track/issues/17 ? Or maybe, we rather want a more fine-grained version of issue 17, i,e, a kind of priority list for update "features". That discussions so far made me come up with the following priority list (discussion welcome): Priority 1 (Minimal): Be able to insert and delete complete graphs in a one shot operation. 1. INSERT GRAPH INTO <uri> (i.e. insert excplicitly given graph - replacing) 2. CLEAR <uri> (i.e. delete all, delete graph) Basically, PUT and DELETE on HTTP level, seem to be a special case of that, except that insertion/clearing of named graphs are supported here, Priority 2 (plus partial delete and additive insert): Be able to insert and delete parts of graphs as well. 1.+2 as above plus 3. INSERT DATA INTO <uri> (i.e. insert excplicitly given graph - additive) 4. DELETE DATA FROM <uri> (i.e. delete certain triples from given graph) ISSUES which we need to resolve to get there: * http://www.w3.org/2009/sparql/track/issues/18 how to deal with concurrency issues? Is there anything we need to say regardnig concurrency ? * Also, the supporting system needs to guarantee that either all or none of the triples are inserted/deleted (atomicity)? * Can POST be viewed as a special case of INSERT DATA INTO? Priority 3 (all above + insert per reference): That is also allow insertion or complete load of a given graph 2.-4. as above. 1. additionally allowing a FROM clause: INSERT GRAPH FROM <uri> INTO <uri> or alternatively LOAD <uri> INTO <uri> ISSUES which we need to resolve to get there: * shall LOAD be replacing or additive? * http://www.w3.org/2009/sparql/track/issues/19 i.e., does insert per reference raises security issues, similar to quqery by reference? Priortity 4 (full insert delete) 1.-3. as above, but with WHERE part DELETE [ FROM <uri> ]* { template } [ WHERE { pattern } ] INSERT [ INTO <uri> ]* { template } [ WHERE { pattern } ] Priortity 5 (The full monty) all above plus WSDL protocol, MODIFY, CREATE, DROP graph ISSUES which we need to resolve to get there: * http://www.w3.org/2009/sparql/track/issues/20 graph awareness * http://www.w3.org/2009/sparql/track/issues/21 more complex change operations, e.g. MODIFY needs probably to guarantee transacitonality. * http://www.w3.org/2009/sparql/track/issues/22 SOAP/WSDL protocol Please feel free to re-prioritize, comment, add issues. Axel -- Dr. Axel Polleres Digital Enterprise Research Institute, National University of Ireland, Galway email: axel.polleres@deri.org url: http://www.polleres.net/
Received on Tuesday, 26 May 2009 19:41:47 UTC