Re: Review of Update Document (Re: ACTION-554)

Hi Paul,

The changes look good. All my comments have been addressed.

Thanks,
Matt

On 12/13/2011 1:44 PM, Paul Gearon wrote:
> On Tue, Dec 6, 2011 at 8:11 AM, Matthew Perry <matthew.perry@oracle.com <mailto:matthew.perry@oracle.com>> wrote:
>
>     Hi,
>
>     My review of Update follows. The document is in very good shape overall.
>
>     Thanks,
>     Matt
>
>
> Thanks Matt. Responses below.
>
>     ======== 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?]
>
>
> Changed to "should".
>
>     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.
>
>
> The only time that the word "Merge" is used outside of this section is in relation to a graph merge. Since it never come up in any definitions, I agree that it shouldn't be there. Removed.
>
>     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.
>
>   
>
> There is text in 3.1.3 (DELETE/INSERT) that covers this:
>
> "If any solution produces a triple containing an unbound variable or an illegal RDF construct, such as a literal in a subject or predicate position, then that triple is not included in the output RDF graph."
>
> However, 3.1.3.2 (INSERT - Informative) is about clarifying the usage of INSERT, so I'm happy to include an example like this.
>
> I've included the following text (adapted from the CONSTRUCT text in the Query document):
> "If any instantiation arising from the solution sequence produces a triple containing an unbound variable or an illegal RDF construct, such as a literal in subject or predicate position, then that triple is not inserted. The template can contain triples with no variables (known as ground or explicit triples), and these will also be inserted, providing the solution sequence is not empty."
>
> I have also added a new example 9 (thus shifting all subsequent examples up a number).
>
>     ======== Minor comments and typos ==========
>
>     Abstract
>     Operations are provided to update, create [and, =>  and] remove RDF graphs in a Graph Store.
>
>
> Done.
>
>     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.
>
>
> Already done from prior review.
>
>     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.
>
>
> If any of these words do not appear in bold, then they should not be interpreted according to RFC2119. They are legitimate words to use in standard english, so there will be occasions where their use is required, without the need for the RFC2119 interpretation.
>
> There do appear to be a few cases where marking these words as RFC2119 makes sense, so I've tried to change this where I think it's appropriate. One thing to point out is that the word "should" appears numerous times in Appendix A (Security Considerations - Informative). As this is just an informative section, I didn't think it was appropriate to mark any usage of this word to be interpreted as for RFC2119.
>
>     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.]
>
>
> Changed the word SERVICE to say "the SERVICE keyword" and provided a link into the Federated Query document.
>
> Also "does not guarantee atomicity" seemed to imply (to me) that atomicity may be expected, but cannot be guaranteed. However, since SERVICE almost certainly removes any expectation of atomicity, I decided to change this text to "will usually result in a loss of atomicity".
>
> (I said "usually" because a clever store that detects loopbacks may be able to ensure atomicity in those situations)
>
>     3.1.1
>     where QuadData are formed by TriplesTemplates, i.e., sets of [triples ==>  triple] patterns, optionally wrapped into a GRAPH block.
>
>
> Done
>
>     3.1.2 Example 4:
>     Data before does not match example update statement.
>
>
> Already done from prior review.
>
>     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.
>
>
> Done. Also fixed font for links to INSERT and DELETE.
>
>     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;
>
>
> Done.
>
>     3.1.3.3 Example 11:
>     Data after looks wrong
>
>
> Already fixed. It was fortunate that you made me look at this again, as the update operation was incorrect.
>
>     3.1.5&  3.2.2
>     No textual description of GRAPH IRIref option
>
>
> Added.
>
>     Example 12, 13, 14
>     Should use a separate box for each graph for consistency with previous examples.
>
>
>  Done.
>
> Regards,
> Paul