- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 09 Mar 2011 13:48:26 +0000
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
==== 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