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



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Axel Polleres
> Sent: 26 May 2009 20:41
> To: 'RDF Data Access Working Group'
> Subject: [ACTION-33] Trying to sort the SPARQL/Update issues.
> 
> Hi all,
> 
> I am trying hard to get my head around the various update issues.

Agreed.  I don't yet have a clear sense of the sweet spot.  Different people's experiences with their current systems seem quite divergent.

> 
> 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.

Yes - although what more was not clear.

> 
> 2) it seems further that several people think that fixing a PUT/DELETE
> semantics  for inserting/deleting data still would be desirable.

My hope is to find a language of operations then map HTTP Verbs.  
We should make this two-way (the operations reflect the verbs).

The HTTP naming remains an issue.

I am now more convinced that just HTTP is insufficient because (a) in practice, there isn't always an HTTP server and (b) some operations are very painful to fit into this style (e.g. DELETE by pattern).

> 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".

I didn't hear strong support for phasing the work because several people want graph stores, not single graphs, to be updateable.

> 
> 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)

What's the data?  In-band?  Or like:

Like LOAD <U> INTO <U> as per the submission? (removing the need to say <U> twice would be nice).

LOAD => read from somewhere on the web
INSERT DATA => triples in-line (rename as "ADD"?)
INSERT {} WHERE {} => insert based on pattern (CONSTRUCT/INSERT).

> 2. CLEAR <uri>                 (i.e. delete all, delete graph)

Is there an assumption creeping in here? 

CLEAR to me means empty the graph - there may be issues around implicitly deleting it and recreating it on the next insert because there may be associated state with a graph (e.g. management stuff like access control info, version history).

Also, may want more control over graph creation than just "some triples arrive" e.g. restrictions on names of graph supported at this service point.

> 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,

We need to get clear about "graph store" and the relationship between graph stores, service endpoint service and naming of graphs in a graph store.

> 
> 
> Priority 2 (plus partial delete and additive insert):

Partial deletes seem more important (e.g. change an address).

>     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)?

"guarantee" is very strong - given (hopefully) the range of implementations, exact characteristics are best expressed in service description.

>    * Can POST be viewed as a special case of INSERT DATA INTO?

No.

> 
> 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.


I have been trying to find groups of operations so we can be clear about what does what:

Tentative suggestion:

1/ Graph store management: Create/removal of graphs (names of graphs) from the graph store.

2/ Whole graph operation (graph exists - may have implicit create/delete): clear, replace contents

3/ Changes to (nameable) graph: load data into (add triples), delete data, insert data, delete by pattern, insert by pattern (this seems less significant)

 Andy

> 
> 
> 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 Wednesday, 27 May 2009 11:16:10 UTC