- From: Axel Polleres <axel.polleres@deri.org>
- Date: Mon, 28 Mar 2011 21:19:37 +0100
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: "SPARQL Working Group" <public-rdf-dawg@w3.org>
I continue with the points addressed in part 2 of Andy's review.
Thanks again for the thorough and detailed feedback!!!
Axel
On 10 Mar 2011, at 16:48, Andy Seaborne wrote:
> ==== SPARQL Update (part 2)
> This completes my review.
>
> Covers section 4 onwards but also ..
>
> === 3.1.1 INSERT DATA
>
> [**]
> """
> INSERT DATA { graph_triples }
>
> Graph triples are defined as:
>
> graph_triples ::= TriplesBlock | GRAPH <uri> { TriplesBlock }
> """
> This disallows:
>
> INSERT DATA { :s :p :o . GRAPH :g { :s1 :p1 :o } }
> INSERT DATA { GRAPH :g2 {:s :p :o } . GRAPH :g { :s1 :p1 :o } }
>
> Is there a reason for this?
> The grammar allows it.
>
done. This is changed now in Section 3 (and also the Formal model should allow arbitrary QuadPatterns
> Its seems unnecessary to force the application to separate out the triples.
>
> This is repeated:
> = 3.1.2 DELETE DATA
> = 3.1.3 DELETE/INSERT
> modify_template ::= ConstructTriples | graph_template
> = 3.1.4 DELETE
> = 3.1.5 INSERT
all done.
>
>
> == Section 4:
>
> [**]
> I suggest a section on how certain forms map to other forms, then must
> define the fundamental forms.
>
> Rewrites for ADD, COPY, MOVE (some text exists elsewhere but should be
> in the formal section)
> DELETE WHERE, DELETE {} WHERE, INSERT {} WHERE
>
> Maybe CLEAR as well.
>
> then define DELETE{}INSERT{}WHERE{}, LOAD, CREATE, DROP, INSERT DATA,
> DELETE DATA.
>
> Something on WITH and USING to formalise them as syntactic features.
> There is material elsewhere but I feel the formal section should be
> self-contained able to cover all SPARQL Update.
I see, you mean, some kind of "core" language,
I see... At the moment, the formal definitions of 4.3.4 ,4.3.5, 4.3.6 are
indeed superfluous and if we defined DELETE WHERE, DELETE, INSERT in terms of rewritings,
then that would safe superfluous formal definitions. (at the moment, the "rewriting" is done in terms of
the definitions themselves, which all re-use the def of DeleteInsertOp)
I am not sure yet, though, whether I can find time to restructure that, do you think this
could go to LC without such re-structuring or do you think it's crucial?
I'd hope this shouldn't be a roadblock for LC.
>
> [**]
> Need an account of how the syntax maps to the operations. It's fairly
> obvious but probably should be said.
* Open: Agreed, I haven't yet tackled that, but how about the following:
1) In each of the subsections of Section 3, say in one sentence: something like
"The formal semantics of [Operation] is covered in [pointer to respective subsection of section 4.3]"
2) After the formal definitions of update operations in subsections 4.3 in each subsection,
say how the syntactic operations of Section 3 map to those update Operations.
> == 4.1.1 Graph Store
>
> [] s/associated to/associated with/
done.
>
> [*] Say the IRIi are distinct.
done.
> [] It says: "1 <= i <= n" but nothing about n
done.
> == 4.1.2 Update Operation
>
> The "t+1" notation isn't used anywhere.
>
> As the state of a store only depends on the previous state and the
> operation and not t-2, it's not necessary.
>
> Is this definition used anywhere? I could immediately see that it's
> needed and wondered if it is historical now.
>
Well, yes, I also think it is kind of historical now, but it illustrates the shape in which all the operations are defined... so I'd like to keep it, but I replaced t, t+1 with simply GS and GS', and renamed the definition/subsection to "Abstract Update Operation"
so, I consider this done as well from my side.
> == 4.2 Auxiliary Definitions
> == 4.2.1 Dataset-UNION
>
> [*] An RDF dataset is a set { DG, (<u_i>, G_i)} -- write it same as
> query has it, not "DG' union {(iri'j, G'j) | 1 <= j <= m})"
done. I think the way I write it now works { } were missing around DG'
> [**] Not merge - this must be a union. not rename blank nodes apart.
> Otherwise one operation followed by another will not update the same
> bNode. And datseta-diff is not going to work.
done.
>
> == 4.2.2 Dataset-DIFF
>
> [*] dataset comment as dataset-union.
> [**] Its says "merge" (bullet 3). Should be set-difference or minus.
done.
> [] G_j should be G sub j.
done.
>
> == 4.3.1 Insert Data Operation
>
> """
> graph_triples, i.e. either a dataset consisting of a single named graph
> and an empty default graph
> """
> [**] As we have defined dataset-union, I think this should be dataset
> union, nor limited to one graph. See also the graph_triples issue above.
>
done. this is all changed now to QuadPattern.
> == 4.3.2 Delete Data Operation
>
> [**] graph_triples
>
done. this is all changed now to QuadPattern
> == 4.3.3 Delete Insert Operation
>
> """
> Triples are identified as they match a particular Group Graph Pattern P.
> """
> [**] The triples here are the ones to be deleted or inserted - they are
> not identified by matching - there is a template stage in between.
done. this has changed significantly.
> [**] Define modify_template sub DEL and modify_template sub INS
>
done. this has changed significantly.
> [**] Dataset(modify_template, P)
>
> Write this out formally:
>
> Dataset(modify_template, P) = { instantiate(modify_template) | μ a
> solution of P }
>
> instantiate(modify_template) = ....
>
done. this has changed significantly.
>
> These are superseded if there is an abbreviated forms section:
> == 4.3.4 Delete Operation
> == 4.3.5 Insert Operation
> == 4.3.6 Delete Where Operation
>
* Open: Agreed, but no time yet to address those. Suggest to leave 'as is' for the moment, not a roadblock for LC, IMO.
>
> == 4.3.7 Insert Where Operation
> [**] What's this used with?
> "Insert Where ... are *deleted* from the Graph Store"
>
done. this was copy-paste nonsense, subsection dropped.
> == 4.4.1 Create Operation
>
> [*] Either something on what happens about empty graphs or, in the
> section intro, say the definitions assume we can have empty graphs. the
> latter is probably better.
* done? Added:
"<p>Note: Since (non graph-aware) graphstores may remove graphs that are left empty, for such graph stores any CreateOperation may be viewed as immediately followed by a DropOperation, cf. next subsection.</p>"
after the definition. Added a similar sentence in Section 4.3.8.
However, don't feel entirely happy with that... I would also need to make a similar remark in the delete and deleteData sections?
> == 5 Conformance
> [*] remove / update name to "RDF Dataset HTTP Protocol"
done. I changed the name now uniformly to "SPARQL 1.1 Graph Store HTTP Protocol"
Received on Monday, 28 March 2011 20:20:16 UTC