Review of "SPARQL 1.1 Update"

== Review of SPARQL 1.1 Update
Version of 18 December 2009

= Overall

1/ We have
"SPARQL 1.1 Update"
"SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"
"SPARQL 1.1 Protocol for RDF"

Somewhere there needs to be an explaination of the three specs that 
relate to this area.  I suggest we have another doc which is a guide to 
SPARQL 1.1 documents.

For this publication:
SPARQL 1.1 Update and SPARQL-HTTP need to have some text relating them.

2/ The term "SPARQL-Update" is used frequently but that isn't the name 
any more.
e.g. Abstract

"This document describes SPARQL-Update"
"This document describes SPARQL 1.1 Update"

3/ The language is ambiguous and really could do with fixing (or, at the 
very least, noting the fact)

4/ Fix INSERT DATA and DELETE DATA to take GRAPH and not use FROM/INTO. 
  Fixing now will reduce confusion later.

= Main review

== Related work

Spec don't need to have a related work section so it is no longer needed 
(and will quickly date and pointing to a wiki from a frozen document is 
Remove. Instead link to

Add an explaination of relationship to
"SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"
(and copy the text into SPARQL-HTTP!)

Add an explaination of relationship to
"SPARQL 1.1 Protocol for RDF"
if that's where POSTing update requests wil go.

For this publication, at least add text to give the framework via links. 
  Detailed explaination can come later.

== 1.2 Document Conventions

Need to discussion PREFIX and BASE somewhere.

Maybe a "structure of an SPARQL Update Request section" that also uses 
the material about multiple operations in one request, defines some 
terminology: Graph store (already described) , operation, request, 
modify_template and other terms used.

Maybe the final section "2 Terminology" depending on how section 6 
(defintions) works out.

== 2 Relation to new features in SPARQL 1.1
Rename as "editors working notes" or "Outstanding Issues" or soethign to 
make clear from the title it's not permanent.

== 2.3 Property Paths
Using property paths in Update seems to lead to quite a lot of 
complexity quite quickly.
Reads as opinion - could do with explanation or remove.
Can be read as if the problem is paths in the modify_template, which 
they aren't.

== 3 Examples

s/RDF Store/Graph Store/

I suggest placing the examples with the descriptions of each feature.

Example (e)
"move" by insert-delete.
Be good to say that explicitly somewhere.

This can be done in a single operation, which is better style if 
operations and not request are atomic in some system.

== 4 The Graph Store

Add ref to section 6 SPARQL-Update Definition
even if it's not finished because otherwise sec 4 feels like the defn of 
graph store.
The link to RDF datasets should go to the definition box in SPARQL 1.0 
Query "12.1.2 RDF Dataset"

== 4.1 Note
Protocol/Syntax does not allow it.

== 4.2
"In the case of two different update services, "
and also connection to SPARQL-HTTP.

A system shoudl be able to provide an update service at:

and PUT/POST with

== 5.1 Graph Update

5.1.1 (INTO), 5.1.2 (FROM), and WITH in 5.1.3, 5.1.4, 5.1.5
We have three mechanisms for the same thing which is confusing.

It's weird it's:
   DELETE DATA FROM <uri> { :x :p 123 . }
but equivalent in effect to:
   WITH <uri> DELETE { :x :p 123 . }
   DELETE { GRAPH <uri> { :x :p 123 . } }

Shouldn't DELETE DATA use GRAPH?
   DELETE DATA { GRAPH <uri> { :x :p 123 . } }
and eliminate FROM and INTO.

2/ Ambiguity.
This sequence of tokens:

WITH <uri>
DELETE { ?x :p ?v }
INSERT { ?x :q ?v }
WHERE { ?x :q 123 }

can be parsed at least 2 different ways:

As two operations:
WITH <uri>
DELETE { ?x :p ?v }
# followed by a separate operation
INSERT { ?x :q ?v }
WHERE { ?x :q 123 }

or as
# All one operation
WITH <uri>
DELETE { ?x :p ?v }
INSERT { ?x :q ?v }
WHERE { ?x :q 123 }
# WITH and WHERE included


Insert data into a graph:

{ triples }

That's insert into one or more graphs.  But replace with restricted 
modify_template* anyway.

Same for DELETE

5.1.5 INSERT

If the WHERE clause is not present, then the insert template is also 
treated as the pattern for the effective WHERE clause. Because a 
template used in this way must also be a valid pattern, it may not 
contain blank nodes.

Isn't INSERT on it's own without WHERE always a no-op?
If modify_template = pattern, the WITH must changes the default graph 
for both.
If so, then I suggest banning it.

The INSERT operation is similar to the general INSERT/DELETE operation 
with an empty DELETE template.
It is a general operation with an empty DELETE so "similar" is confusing.

What's a "DELETE template" - wouldn't that be the modify_template of a 
DELETE? Terminology needs sorting out.

5.1.7 CLEAR

# Remove all triples.
CLEAR [ GRAPH <uri> ]
It has the same effect as:

# Remove all triples.
DELETE [ <uri> ] { ?s ?p ?o } WHERE { ?s ?p ?o }

Isn't it
   [WITH <uri>] DELETE { ?s ?p ?o } WHERE { ?s ?p ?o }

== 6 SPARQL-Update Definition
"Note" - Need for operator
See "substitute" in SPARQL 1.1 Query.

== B SPARQL-Update Grammar
Out of date.
Better to remove it and leave a placeholder note. than to publish 
conflicting information.

Received on Tuesday, 22 December 2009 11:57:38 UTC