Re: SPARQL 1.1 Update Review (part 2)

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.

> 
> >
> > 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 Friday, 29 April 2011 22:54:49 UTC