Review of Update Document (Re: ACTION-554)

Sending again due to poor email title the first time.

Thanks,
Matt

-------- Original Message --------
Subject: 	Re: ACTION-554
Date: 	Mon, 05 Dec 2011 17:28:10 -0500
From: 	Matthew Perry <matthew.perry@oracle.com>
To: 	W3C SPARQL Working Group <public-rdf-dawg@w3.org>



Hi,

My review of Update follows. The document is in very good shape overall.

Thanks,
Matt

======== More substantive comments ===========

The following phrase is used in many places (3.1.4, 3.1.5, 3.2.2. 3.2.3, 3.2.4, 3.2.5)
"the SPARQL 1.1 Update service is expected to return failure"
It should have a more normative wording [is expected to ==>  should/must?]

4.2.1
I think the dataset merge operation should defintely be dropped. It's confusing to have an unused definition. From my understanding, the use of sku(TriplesTemplate) will effectively make Dataset-Merge equivalent to Dataset-UNION.

4.2.3
Unbound Vars:
I have a question about cases like the following when variables are unbound:
INSERT
{ ?a :p3 ?b .
   ?a :p4 ?c }
WHERE
{ ?a :p1 ?b
   Optional {?a :p2 ?c}}

I assume the phrase "all valid RDF triples" means that no triple will be inserted for ?b :p4 ?c for a solution with an unbound ?c.

I think it would be worthwhile to explicitly point out such cases with an example somewhere in Section 3.

======== Minor comments and typos ==========

Abstract
Operations are provided to update, create [and, =>  and] remove RDF graphs in a Graph Store.

Section 2
Unless overridden (for instance, by the SPARQL protocol), [then ==>  delete then] the unnamed graph for the store will be the default graph for any operations on that store.

Section 2.1
Furthermore, the query service's RDF dataset and the update service's Graph Store [may ==>  should be bold print for consistency] use different names for the same graphs.

In general, may, should and must are not consistently bolded.

Section 2.2
However, using SERVICE in the WHERE clause of operations in an Update request does not guarantee atomicity. [The meaning of SERVICE here is not totally clear to me. I assume this is the SPARQL 1.1 SERVICE keyword for federated queries. This should be clarified a bit.]

3.1.1
where QuadData are formed by TriplesTemplates, i.e., sets of [triples ==>  triple] patterns, optionally wrapped into a GRAPH block.

3.1.2 Example 4:
Data before does not match example update statement.

3.1.3
In the presence of one or more graphs referred to in [USING ==>  wrong font] clauses, the default graph will be the merge of these graphs, meaning that the graph in a WITH clause will be ignored while evaluating the WHERE clause.

Again, QuadPatterns are formed by TriplesTemplates, i.e., sets of [triples ==>  triple] patterns, optionally wrapped into a GRAPH block, where the GRAPH clause indicates the named graph in the graph store to be updated;

3.1.3.3 Example 11:
Data after looks wrong

3.1.5&  3.2.2
No textual description of GRAPH IRIref option

Example 12, 13, 14
Should use a separate box for each graph for consistency with previous examples.