W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > March 2010

Re: Suggestion on modifying update in SPARQL 1.1.

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 31 Mar 2010 22:07:26 +0100
Cc: public-rdf-dawg-comments@w3.org
Message-Id: <9CCBC30D-E7B6-43B9-A0DD-6AB45108D071@deri.org>
To: Nikolai Anissimov <anisimov@fiztech-usa.net>
Dear Nikolai,

thanks for your suggestion. We have discussed the issue of combined Update Queries with SELECT parts at the group's recent face-to-face meeting. The group has resolved at this stage to go forward with a design where Update queries can only return success or failure [1].

Although the general spirit of your proposal combining query parts with updates is interesting, 
we will not be able to take this extension it on board with the resources and time remaining, 
following the group's charter. [2]

with best regards, Axel, on behalf of the WG

1. http://www.w3.org/2009/sparql/meeting/2010-03-25#resolution_5

2. http://www.w3.org/2009/05/sparql-phase-II-charter.html

On 17 Mar 2010, at 20:02, Nikolai Anissimov wrote:

> Hello,
> 
> I'm reading a proposal SPARQL 1.1/Update (http://www.w3.org/2009/sparql/docs/update-1.1/gen.html#t413).
> My impression that DELETE/INSERT construct is incomplete. I suggest to add to this construct SELECT. It will use the same WHERE as DELETE and INSERT simultaneously. One could use it for returning results about execution of update which are intreseted for application.
> Now the construct will look like:
> 
> # UPDATE outline syntax : general form:
> [ WITH <uri> ]
> SELECT {...}
> DELETE { modify_template [ modify_template ]* }
> INSERT { modify_template [ modify_template ]* }
> WHERE GroupGraphPattern
>  
> One can specify what was added/deleted to RDF database.
> One more benefit is it would clarify what to return back after updating.
>  
> Reagards,
> Nikolay Anisimov
> Software Architect at FrontRange Solutions
> Email: anisimov@computer.org
> 
> 
> 
> 
Received on Wednesday, 31 March 2010 21:08:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 31 March 2010 21:08:01 GMT