Re: SPARQL 1.1 Update Review (part 2)

On 29 Apr 2011, at 23:54, Axel Polleres wrote:

> Hi Alex,
> 
> short sync-request ...
> 
> On 29 Apr 2011, at 22:34, Passant, Alexandre wrote:
> 
>> 
>> 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
> 
> Now that I've put all the mappings from syntax to semantics in one separate subsection 4.5
> I'd rather suggest to just add a sentence in the beginning of Section 3, saying that the formal semantics of 
> those operations is covered in Section 4.5 below.

Done

Alex.

> 
>> 
>>> 
>>> 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.
> 
> This is exactly what Section 4.5 is for.
> 
> best,
> Axel
> 
>> 
>> 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 Monday, 2 May 2011 22:47:24 UTC