W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Comments on SPARQL 1.1 Update (3)

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 01 Sep 2010 23:47:43 +0100
Message-ID: <4C7ED80F.3010404@epimorphics.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
4.1.3 DELETE/INSERT

[[
If an operation tries to insert into a graph that does not exist, then 
that graph *must* be created.
]]

Surely this is wrong? For stores that distinguish empty graphs from 
non-existent graphs, we have CREATE GRAPH.  Automatic creation is at 
odds with that setup.

[[
Deleting triples that are not present, or from a graph that is not 
present will have no effect and will result in success.
]]

seems inconsistent - why can't an error be generated for this case when 
stores do different graph existence from emptiness?


4.1.4 DELETE

[[
The DELETE operation is similar to the DELETE/INSERT
   operation without an INSERT section.
]]

s/is similar/equivalent/ ?


4.1.5 INSERT

----
The INSERT operation is equivalent to the DELETE/INSERT
   operation without a specified DELETE section.
----

It's not equivalent as specified.  The WHERE clause has been made 
optional and it isn't for DELETE/INSERT or DELETE.

I think the WHERE clause should be mandatory for consistency and because 
we have INSERT DATA for inserting data (the only use of INSERT without 
WHERE).

A plain INSERT is hard to parse efficiently - this is why INSERT DATA 
was added into the pre-submission SPARQL Update.  The system can't know 
that it is encountering an all data INSERT, with no WHERE clause, during 
parsing.  Adding data this way may be important.

Inserted data can be very large - knowing it's INSERT DATA allows the 
system to handle it specifically, e.g. stream the data somehow, which is 
very difficult if it's plain INSERT because it's not known to be all 
data until after the end of parsing the operation.

4.1.5 INSERT

[[
This example copies records from one named graph to another named graph 
based on a pattern.
]]

editorial:
"copies records" -> "copies data about specific books"

editorial:
"2000-01-01T00:00:00-2:00" -> "2000-01-01T00:00:00-02:00"

(add a zero to -2:00 => -02:00)

timezone offset must be HH:MM

XML Schema part 2: 3.2.7.3 Timezones
[[
The lexical representation of a timezone is a string of the form: (('+' 
| '-') hh ':' mm) | 'Z', where
]]

	Andy
Received on Wednesday, 1 September 2010 22:48:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:43 GMT