[ACTION-33] Trying to sort the SPARQL/Update issues.

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