Review of SPARQL 1.1. Update editors' draft

This mail discharges ACTION-229.

I do not see any issue that should prevent us from publishing the 
current editors' draft as a public Working Draft.

That said, I do have a lot of feedback that I hope is helpful to the 
editors:

~~ May, 2010 Review of SPARQL 1.1 Update Editors' Draft ~~

== Structure ==

* I'd expect us to have a Conformance section near the end of the 
document. (Similar to 
http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#conformance)

* I'd suggest removing 1.1. There are a lot of things that SPARQL Update 
is not (e.g. a fully transactional update language), and I don't think 
we need to enumerate those.

* 3.2 "An implementation must target SPARQL queries on updated graphs if 
the SPARQL and SPARQL 1.1 Update end points are the same." This sounds 
like it belongs in the protocol document, not in the update document.

* 3.2.1. I think this belongs in section 5 -- this is the start of a 
formal model for update.

* 3.2.2 I think this does not belong in this document. Perhaps in the 
entailment document, or else not in the SPARQL 1.1 documents at all?

* 4. A single Graph Update operation can add/remove triples from 
multiple graphs, right?

* 4 "Syntax" - I feel like the title of this section should be "SPARQL 
1.1 Update Language" or something like that. It's far more than syntax.

* The subsections within 4.1 and 4.2 ought to all be named 
consistently--either with the names of the statements (as in 4.1) or 
with a short description of the operation (as in 4.2).


==Substantive==

* We need to determine which parts of the specification are normative 
and which are informative.

* We haven't closed ISSUE-37, but I would propose that:
   PROPOSED: Close ISSUE-37 noting that SPARQL 1.1 will not address 
basic federated update in any way, no change needed.

* 3. I think that the definition of a Graph Store is confusing. In 
particular, I don't understand the difference/relationship between the 
unnamed graph and the default graph. (This confusion applies for me 
throughout the document.)

* 3. What is an update service?

* 4. The fact that one operation's failure aborts the rest of the 
operations within a request seems to be a normative conformance aspect 
of the language. As such I'd suggest s/will abort the sequence/MUST 
abort the sequence/.

* 4.1 "Graph update operations change existing graphs in the Graph Store 
but do not delete them." Given the provision that empty graphs can be 
removed after any operation, this statement is not strictly true, right?

* 4.1.1/4.1.2 Is it purposeful that a single INSERT DATA or DELETE DATA 
operation can only act on a single named graph? I believe the operations 
would be equally streamable if graph_triples was graph_triples*.

* 4.1.3. I think the treatment of WITH and USING / USING NAMED is still 
unclear. In particular, what's the relation between the two? The text 
about WITH seems in conflict with the text about USING. Also I think 
that we need to be explicit about what USING and USING NAMED do, rather 
than just asserting that their behavior is identical to FROM and FROM 
NAMED from SPARQL Query.

* 4.1.3. "Recall however that for any clause that stipulates its own 
GRAPH or USING modifiers, then the WITH will be ignored for that 
clause." This doesn't seem strictly true... Can't a DELETE or INSERT 
clause contain both triples within a GRAPH clause _and_ unadorned 
triples (that would be affected by WITH)?

* 4.1.3. "It is legal for an operation to attempt to delete from a graph 
that does not exist" - Does this mean the result of this is success? 
Also, probably would be better to avoid the phrase "it is legal" in 
non-de-jure standards. :-)

* 4.1.6. LOAD <...> INTO GRAPH DEFAULT sounds weird. Could we make that 
case just be LOAD <...> INTO DEFAULT? (This also relates to the general 
confusion between unnamed graph and default graph and the Query notion 
of a default graph.)

* 4.1.6. LOAD needs more explanation of what documentURI means. Do I 
need to dereference this URI? Is it an indirect relationship between the 
URI and the triples to be loaded (a la FROM/FROM NAMED)? That is, can I 
ever do LOAD <urn:TheGraph> INTO GRAPH <...> ?

* 4.1.7 Same comment regarding "GRAPH DEFAULT" sounding weird.

* 4.1.7 "This operation does not remove the graph from the Graph Store." 
- This is not strictly true given the ability for implementations to 
remove any empty graph at any time, right?

* 4.2 What does it mean that graph management operations are optional? 
How should a conformant implementation behave that doesn't want to 
create/remove graphs?

* 4.2.1 "The graph store does not record empty graph" -- What does this 
mean? I thought we agreed to deal with these implementations by allowing 
stores to (theoretically) remove empty graphs at any time, in which case 
this sort of store would just be a normal success, followed by a silent 
removal of the empty graph. (In which case this does not need to be 
called out specially here.) Similarly, the failure modes can be 
simplified to failing to create a graph or the graph already existing. 
Similarly for section 4.2.2.

* Section 5: As we've discussed, we need a formal model for the update 
language. I think it needs to cover (perhaps among other things), Graph 
Store, transformations on a graph store, transformations on a graph, 
what it means to "process" a triple, success and failure criteria for 
each operation, what it means to optionally remove an empty graph 
between operations, what it means to abort later operations in the face 
of failure of one operation, the relation between Graph Stores and RDF 
datasets, the relationship between the unnamed graph and default graph, 
the processing model of DELETE/INSERT statements ...

==Editorial==

* We ought to update the editors to include Alex.

* Abstract: "It uses a syntax derived from SPARQL." -> "It uses a syntax 
derived from the SPARQL Query Language for RDF."

* Introduction: The first paragraph tries to justify the language's 
existence. I think it would be better off left out. If it's kept, I do 
not think that SPARQL Update is a "mechanism by which updates to a 
remote RDF Store can be described, communicated, and stored." The 
language does not rely on a remote store, and it does not talk about 
storing updates. As far as I can tell, it's a language for specifying 
and executing updates to an RDF graph store.

* Introduction: s/RDF Graph/RDF graph/

* Introduction: s/query processors/SPARQL endpoints  --  though once 
Axel and I get around to writing an overview document, we might merge 
these two paragraphs with the content of the overview document to help 
readers understand how the specifications fit together.

* 1.2.1. What is a SPARQL request? Better as "SPARQL Update statement"? 
Or perhaps "SPARQL Update request"?

* 1.2.1. s/derived from SPARQL/derived from SPARQL Query/

* 1.2.1. It may just be my OS/browser setup, but I have a very hard time 
telling the bold fixed-width font from the non-bold fixed width font.

* 3.1 The second two sentences are confusing. I think they're trying to say:

"""
A query service MAY offer an RDF dataset formed from graphs that are 
part of an update service's Graph Store. The graphs in the query 
service's RDF dataset MAY be a subset of the graphs in the update 
service's Graph Store. Furthermore, the query service's RDF dataset and 
the update service's Graph Store may use different names for the same 
graphs.
"""

* 3.1 Note -- there's nothing in 2.1 that seems related to this any longer?

* 3.2 I think we should strike "SPARQL 1.1 Update services are provided 
over the SPARQL 1.1 Protocol for RDF." The protocol layers on top of the 
Update spec (as with query)--Update can be used via other mechanisms 
rather than the protocol (e.g. an API), so the Update spec. should not 
need to make reference to the protocol.

* 3.2 What does "This requirement should address concurrency issues." 
mean? I don't think we need to explain why an implementation might not 
satisfy a SHOULD condition.

* 4. s/must Be/must be

* 4. s/will be terminated/is terminated

* 4. I think we probably should simply refer to operations resulting in 
either success or failure, rather than talking about returning state. In 
the absence of an access mechanism such as the protocol, it feels a 
little strange to talk about _returning_ results. (Not sure how strongly 
I feel about this or not.)

* 4.1. Re-format as a bulleted list? I might move these descriptions out 
of this summary area and into the subsections on the specific language 
statements.

* Throughout the document, I think it would be helpful for examples to 
be more complete, showing the Graph Store before the operation and then 
again after the operation.

* 4.1.2. The example here does not separate operations with a semicolon. 
Also, the example is written in a way that implies to me that the PREFIX 
declaration applies to all of the operations in the request, when I 
thought the intent was that PREFIX was attached to a single operation.

* 4.1.3. What does the comment "# UPDATE outline syntax : general form:" 
mean?

* 4.1.3. I think this section would benefit from being re-formatted as a 
numerical list of steps outlining the processing model. I find it hard 
to internalize the process described by the prose.

* 4.1.3. Is the example improved by removing "?person foaf:firstName 
'Bill'" from the WHERE clause? It's not necessary, right?

* 4.1.3/4.1.4/4.1.5. I think this might be clearer if 4.1.3 made DELETE 
and INSERT optional, and then 4.1.4 and 4.1.5 _only_ presented and 
talked about the shortcut forms.

* 4.1.5 The last example in this section needs a semicolon to separate 
operations.

* References don't seem to be accurate.

Lee

Received on Sunday, 16 May 2010 02:00:41 UTC