Re: SPARQL 1.1 Update Review (part 2)

On 28 Mar 2011, at 22:19, Axel Polleres wrote:

[...]

> 
> 
>> 
>> [**]
>> 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]"

+1, I'll add that

> 
> 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.

I'm not sure what you mean here, you want to give examples and show how it works with the formal model ?

Alex.

> 
> 
>> == 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 Friday, 29 April 2011 21:34:46 UTC