SPARQL 1.1 Update Review (part 1)

==== Review: SPARQL 1.1 Update (part 1)
Does not cover "4 SPARQL Update Formal Model" and beyond.


[**] Major
[*]  Minor
[]   Editorial

== 1 Introduction

[] Sentences 1 and 2 say much the same thing.

[*] Standard list of documents.

[] Remove "rationale" para. (it's not a REC, it is a time-sensitive 
document)

[*] Mention and link being related to SPARQL 1.1 Query

[] s/SPARQL 1.1 Uniform HTTP Protocol for Managing RDF graphs/SPARQL 1.1 
RDF Dataset HTTP Protocol/

[*] Be careful - links go to editors working drafts, not published versions


== 1.1.1 Language Form

[] s/This operations/The Operations/

[*] "informative excerpts from the formal grammar"

They aren't excepts of the formal grammar - they use their own notation 
and terminology.
Better: "illustrative forms" or some such.

[**] The SPARQL 1.1 Query grammar link goes to SPARQL 1.0 REC grammar.

[**] Language form shown:

WHERE is not optional with INSERT nowadays.

[**] First example is bad syntax.

INSERT ==> INSERT DATA


[] "Here, [] indicates an optional part of the syntax"
As ()* and ()+ is used, isn't it clearer to use ()?

== 1.1.2 Terminology

[**] <b>must</b>

Only the formal section needs the "must" etc language now.  All mentions 
in the explanatory parts can be made normal language.

There is use of <b>MUST</b>.

[*] Operation: single activity.

Because a request should be atomic, I found that describing this as a 
"single activity" confusing".
I was looking for a definition of 'activity'
Suggest: "Operation - an operation is the building block for request and 
is a single change unit e.g. ...."
Or just say "an operation is one of ..."
"action" also seemed like a good word.  "Activity" feels more ongoing.

[*] Request is one or more operations.

Should we allow zero operations? The empty string? Why not?

[*] Also used terminology:
<uri>
mean an absolute IRI according to RFC 3987.
Not a relative URI with string "uri".

== 2 Graph Store

[] "repository".  In the definition it's a "mutable container".  Should 
the same language be used?

[*] "unnamed graph"
Elsewhere it is "default". Need to be consist. "default" is better 
because the syntax uses "DEFAULT".

[*] "Like an RDF dataset"

A Graph Store is a collection of slots holding graphs.  An RDF dataset 
is a set of one graph and some pairs (<u>, G) so it's not a container. 
An RDF dataset is the value of a graph store at a moment in time 
(between requests).

[**] Unnamed graph as union.

I suggest removing all discussion of union because the doc does not 
define the actions on a UNION.  What happens when the union is updated? 
Where do the changes go? Only the union? Which named graph?

[*] "same pay level domain"
What does this mean?

[**] Simple case -> graph update language.

Not true - an operation can add a graph, either via INSERT...GRAPH or 
LOAD INTO.
Suggestion:
"SPARQL 1.1 Update" can be used as a graph update language."

== 2.1

[] service != endpoint.
A service may have several endpoints.

[*] Papa1: s/update operations/update requests/

[] s/MAY/<b>may</b>/

== 2.3 Entailment and Consistency

[*]  "An update is completed": request or operation?
Only requests matter - an impl could (carefully) do operations in a 
different order if the effect is the same as the textual order but 
inconsistency checking is different.

If it's request is completed, where does the exception go?

[**] Does this all tie to the SPARQL protocol?

== 3 SPARQL 1.1 Update Language

[**] Graph Management: add text to cover ADD, MOVE, COPY

[] "Multiple operations must be separated"
"Multiple operations are separated" -- it's a statement of fact about 
the grammar.

[**] Operations are executed in lexical order.
See above.
The effects are the same as being executed in lexical order.
I can see
LOAD <x1> INTO GRAPH <u1>
LOAD <x2> INTO GRAPH <u2>
LOAD <x3> INTO GRAPH <u3>
being cleverly done.

[*] Operations are executed in lexical order.
They aren't :-)

Requests are (logically)
   INSERT ... WHERE ...
and it does the WHERE first but it's later lexically.

== 3.1 Graph Update
[**] Graph update operations do not explicitly delete or create them.

What about this:
DROP GRAPH <g> ;
INSERT DATA { GRAPH <g> { <s> <p> <o> . }

is pretty explicit about a creation by context.

The text (bullet one) does immediately say this so the intro para is 
confusing.

[**] The fundamental pattern-based operations ... are INSERT and DELETE.

The fundamental operation is the INSERT..DELETE..WHERE operation.
Either s/operations/actions/ so INSERT and DELETE are actions (but as 
action is not defined this is not a nice change), or reword with 
INSERT..DELETE..WHERE being fundamental.

Given the activity comment above, defining "action" as an inserting or 
deleting and using that as the building block should work document-wide.

[**] "The CLEAR operation removes all the triples in a graph."

CLEAR ALL, CLEAR NAMED work on more than one graph.

== 3.1.1 INSERT DATA
[] s/Insert data into a graph/Insert triples into graphs/

It can work on more than one graph in one INSERT DATA.

[*] "graph_triples are defined".

Later, sec 3.1.2 they are "described".
Is this a definitive definition?
   If yes, then put in formal section and link.
   If no, don't say "defined"

[] Provide an example using GRAPH.
Don't rely on fwd reference to 3.1.2

[**] "Default graph of the graph store"

== 3.1.2 DELETE DATA

[] s/Delete data from a graph/Delete triples from graphs/

[**] "The graph_triples need to be matched to existing triples precisely"
graph_triples as a whole does not need to be matched.  It isn't 
"matched".  The formal section does not cover DELETE DATA but for DELETE 
it uses a set diff, so the triple does not need to exist.  It just isn't 
there afterwards.

I think it is really saying no variables, no patterns, but this is not 
clear.

[*] "processed" -- what does this mean?  Suggest removing the sentence.

Example 2:
"This .. expands ..." confusing - it uses different example data and 
patterns.

== 3.1.3 DELETE/INSERT

Suggestion: Make DELETE and INSERT are 3.1.3.1 and 3.1.3.2 respectively.
Suggestion: 3.1.3.1. and 3.1.3.2 are examples, and omit the descriptive 
text that repeats what went before.

[*] "defines a specific graph" -- confusing, it allows a variable so it 
(syntax) isn't a specific graph.

[**] General comment:
"This operation identifies data binding values to a set of variables."
This can be read as meaning one match, not a sequence of matches.  This 
language is also used elsewhere and reads as if there is one match only. 
  Should talk about sequences of solutions.

[*] Give a simple example of DELETE/INSERT before getting to discussing 
WITH, USING.
Overall, there is a lot of use of WITH/USING and I was left with the 
feeling this is preferred style or necessary style, but it isn't. 
Suggest removing from the majority of examples, where it isn't necessary 
for the point being made, would be clearer.

[**] "Any remaining portions of the GroupGraphPattern which are not 
assigned a dataset "

Assigned a graph?  Also, it isn't assignment.  Maybe "matched against".

[] s/inserted or deleted/deleted or inserted/ as that is action-order.

[*] "When WITH is not present, that fallback will be the default graph."

This over-emphasises the use/need for WITH.  It's not a fallback - it's 
the normal usage IMHO.

[*] "If an operation intends to create a graph"

Users can "intend", operations can't!

Seems a long an complicated way of saying

INSERT ...{ GRAPH <g> {} } ...
does not create <g>.

See also INSERT DATA.

[*] Example:

Immediately uses WITH.

[*] Show an example where the WHERE has multiple matches.

== 3.1.4.

Structural comment above.

[] s/SPARQL - Query/SPARQL 1.1 Query/

[*] "The resulting variable bindings" =>
"The resulting a sequence of solutions to the WHERE clause"

Example 2:

[**] Bad syntax
s/USING/WITH/ ??

[**] Bad action:
Unbound variables in the DELETE clause ==> no effect.

To be honest, I'm tempted to suggest that DELETE templates allow and 
match with unbound variables.  The case of

DELETE { ?x foaf:name ?name } WHERE { ?x foaf:mbox_sha1 ?foo }
for
DELETE { ?x foaf:name ?name } WHERE { ?x foaf:mbox_sha1 ?foo . ?x 
foaf:name ?name }
is reasonably compelling.

== 3.1.5

Structural comment above.

<http://example/bookx> dc:date "2002-01-01T00:00:00-2:00" .
[**]  No ^^xsd:dateTime
The WHERE clause does not match.

The book has date in 2002? 1948 surely!

And it's one "P" in "David Coperfield" by Edmund Wells.
http://www.inprint.co.uk/thebookguide/bookshop-skit.htm

This example is trying too hard.

== 3.1.6 DELETE WHERE

[] "Any templates" -- confusing as we are discussing a modify_template

[] Example 2.  Remove DOT after } -- correct but very unusual.

== 3.1.7 LOAD

[*] s/protocol/URI scheme/

[] Don't mention file: -- it's rather weakly defined and used in 
practice in ways outside the strict standard. Mentioning it is just trouble.

[**] "This URI could be a reference to a query"

It includes the query, it's not a reference.

Just remove discussion of using CONSTRUCT in a document URI.

[**] "In case no data can be retrieved."
What about an empty graph?

== 3.1.8

[] "all triples of all named"

Either use "triples in" or "triples of" but be consistent.  It was "of" 
in the first part of the sentence.  To me, "in" is better.

[*] Example:
If giving defining forms, please use one without short forms.

DELETE { GRAPH <uri> { ?s ?p ?o } } WHERE { GRAPH <uri> { ?s ?p ?o } }

[**] "far reaching implications"
Which are what?

Just don't discuss it - the spec is not defining the effect.

== 3.2 Graph Management

[**] "Graph management operations create and destroy named graphs in the 
Graph Store. "

Revise to include effects of ADD, MOVE, COPY.

DROP works on the default graph.

[] Format similarly to 3.1 with a list mentioning each operation in this 
section.

== 3.2.1 CREATE

"Stores that do not record empty graphs will always return success."

So if the store has graph <g> with triple <s> <p> <o> and the request is

CREATE GRAPH <g>

what has empty graphs got to do with it?  This sentence is out of place 
but I don't know what it's place should be.

== 3.2.2 DROP

[*] "removes the specified graph" => "removed the specified graphs"

DROP ALL acts on multiple graphs.

This has a MUST in upper case.  See earlier and the termininolgy says 
"must".

[**] Editors note in document must be removed before LC.

[*] Note that DROP DEFAULT is a clear.  This is only there in a 
confusing way.

== 3.2.3 COPY

Now, the notation is using (|) for alternation but this is not in 1.1.2

"Is equivalent to" example
includes "GRAPH DEFAULT" in the INSERT which is illegal in a template or 
pattern.

[**] "If the destination does not exist, it will be created"
Didn't we decide that some stores may require explicit CREATE, and 
that's why we have SILENT?

[*] Put more information into initial destination graph to make it clear 
it's lost by doing a COPY.

=== 3.2.4 MOVE

[] Inconsistent bold.  Now "[" and "]" are bold face.

[**] GRAPH DEFAULT again.

== 3.2.5 ADD

[**] GRAPH DEFAULT again.

Received on Wednesday, 9 March 2011 13:49:05 UTC