RE: Review of SPARQL Update submisson (ACTION-54)



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Alexandre Passant
> Sent: 16 July 2009 16:26
> To: SPARQL Working Group
> Subject: Review of SPARQL Update submisson (ACTION-54)
> 
> Hi all,
> 
> With regards to ACTION-54 I just reviewed the SPARQL Update Member
> Submission [1].
> Here are a few comments / questions.
> 
> ## INSERT vs INSERT DATA
> 
> First, having INSERT / DELETE and INSERT DATA / DELETE DATA is imho
> not intuitive. I think we should provide a single operator whether
> data to be included / removed is a concrete set of data or a template
> + pattern. SPARQL+ from ARC2 uses the same operator for both [2]. Andy
> mentions the reasons for that choice during the first F2F, but I
> cannot remember it.

As explanation: the issue suggesting INSERT DATA is when there is a lot of inline data to upload.  This may be more than can conveniently be buffered in the processor before actually acting - a stream of data is needed.

The language was changed to have two INSERT operations that distinguished the two cases of inline data and templated additions.  At the beginning of INSERT DATA the processor can start adding triples to the graph as a stream.  

If it's the templated INSERT then the processor does not know this is a (variable free) template until it reaches the (absence of) the second clause.  BNodes (c.f. CONSTRUCT template) mean the processor can't merely put concrete triples into the target graph and forget them.

The DELETE DATA is for symmetry.

...

> ## The SILENT keyword
> 
> I would rather have the SILENT option not in the language itself, but
> in the protocol. Considering that SILENT can be used as a debugging
> mode, I'd prefer to simply add / remove a variable in the protocol
> calls rather than modifying all my SPARQL queries if I want to
> enable / disable that verbosity in existing applications using SPARQL/
> Update.
> BTW, if we keep that option, esp in the protocol, it would make sense
> to have it also for the SELECT.

The usage of SILENT to control whether the request continues to execute in the case of a graph existing or not.

CREATE SILENT GRAPH <uri>
INSERT DATA INTO <uri>

ensures it exists first. It depends on whether "...INTO <uri>" should autocreate a graph.
Because, for some store designs, distinguishing the empty graph and not having a graph at all would cost additional machinery, this is an area that needs rethinking.  The error state could be switched so it happens on "INTO <uri>" if the store refuses to handle that URI.

(and by using CREATE GRAPH <someLockURI> you can do locking - this was not by design!)

 Andy

> Best,
> 
> Alex.
> 
> [1] http://www.w3.org/Submission/2008/SUBM-SPARQL-Update-20080715/

> [2] http://arc.semsol.org/docs/v2/sparql+

Received on Monday, 20 July 2009 08:07:22 UTC