Re: SPARQL1.1 Update review part 2

On 7 Oct 2010, at 04:30, Andy Seaborne wrote:

> Alex,
> 
> I wasn't expecting changes in time for publication.
> 
> Personally, I don't think it warrants a red-box editors note.  An @@ at
> the start will do.

Both is fine with me, but it should be made clear that we don't consider this finished.

best,
Axel

> 
>         Andy
> 
> On 07/10/10 08:53, Alexandre Passant wrote:
> > Hi,
> >
> > As it will be too short to take both your comments and Andy's ones on update for tomorrow, I'll indeed stick to the editor note you suggest, that I've just added on top of the Formal Model section.
> > I'll check both of your comments in detail later.
> >
> > Alex.
> >
> > On 7 Oct 2010, at 04:58, Axel Polleres wrote:
> >
> >> Now here go my remaining comments for Section 4 http://www.w3.org/2009/sparql/docs/update-1.1/#sec_formalmodel
> >>
> >> Overall, I think that the formalisation needs rethinking and as it is written down at the moment, it gives an intuition, but is formally not waterproof in terms of being mathematically readable. I still think we can publish, but we should mark the whole section 4 as "under discussion" (see Summary at the end of the mail)
> >>
> >> Here's some details:
> >>
> >> 1) Definition GraphStore:
> >>
> >> a) minor comment: why "GraphStore" and not "Graph Store"?
> >>
> >> b) the definition looks bogus, what shall<i>  be? I suggest to reformulate this as follows:
> >>
> >> from:
> >>
> >> "A GraphStore GS is a mutable container of RDF graphs. It has one unnamed (default) slot and zero or more named slots identified by an IRI<i>. Each slot holds an RDF graph.
> >>
> >> GS = (DG, {(<i>, G_i)})
> >>
> >> where:
> >>
> >>      • DG is the RDF graph associated to the unnamed slot
> >>      • G_i is an RDF graph associated to the named slot identified by IRI<i>
> >> "
> >>
> >> we might at least want to change that to:
> >>
> >> "A GraphStore GS is a mutable container of RDF graphs. It has one unnamed (default) slot and zero or more named slots identified by an IRI<i>. Each slot holds an RDF graph. I.e.
> >>
> >> GS = (DG, {(<IRI_1>, G_1) ,  ... (<IRI_n>, G_n) })
> >>
> >> where:
> >>      • DG is the RDF graph associated to the unnamed slot
> >>      • for each 1<  i<  n,  G_i is an RDF graph associated to the named slot identified by IRI<IRI_i>
> >> "
> >>
> >> 2) Similarly, the definition of GraphStoreState has problems: GSS_t(GS) = (S_t(DG), {(<i>, S_t(G_i)}) only has a singleton named graph pair, also, note that at each graph store a graph with IRI_i can be present or not present, i.e. from one state to the next, the actual IRIs referrable to as named graphs can differ, i.e. I'd rather define Graph store Operations without this notion of Graph store state, i.e. just defining an UpdateOperation (BTW, why not "Update Operation"?) as follows:
> >>
> >> Definition: UpdateOperation
> >> An UpdateOperation Op transforms a Graphstore GS at time point t, denoted as GS<sub>t</sub>  to
> >> another Graphstore GS<sub>t+1</sub>, denoted as
> >>
> >>    Op(GS<sub>t</sub>,Args) = GS<sub>t+1</sub>
> >>
> >> where
> >>   GS<sub>t</sub>    = (DG<sub>t</sub>, {(<IRI<sub>t,1</sub>>, G<sub>t,1</sub>) ,  ... (<IRI</sub>t,n_t</sub>>, G</sub>t,n_t</sub>) })
> >> and
> >>   GS<sub>t+1</sub>  = (DG<sub>t+1</sub>, {(<IRI<sub>t+1,1</sub>>, G<sub>t+1,1</sub>) ,  ... (<IRI<sub>t+1,n_t</sub>>, G<sub>t+1,n_t+1</sub>) })
> >>
> >>
> >> etc.
> >>
> >> 3) The operations UNION , MINUS, etc. used in the following definitions aren't formalized yet. They aren't readable as normal set operations for similar notation problems as in points 1) and 2).
> >>
> >> As said in the beginning, overall, I think we have to mark this section and the formalization clearly as "under construction" or "under discussion"
> >>
> >> etc.
> >>
> >> Summary:
> >>
> >> I guess it is probably better to publish "as is" at this point than trying to fix this for the current version.
> >> The following editor's note in the beginning of Section 4 would be ok for me to publish now (i.e. no further changes needed):
> >>
> >> "The following formalization of the SPARQL update operations is a first draft, reflecting the intuition behind the different update operations, while not yet formalized completely in terms of precisely defining the pseudo-mathematical notation used. Future versions of this document shall provide a full formalization."
> >>
> >> best,
> >> Axel
> >
> > --
> > Dr. Alexandre Passant
> > Digital Enterprise Research Institute
> > National University of Ireland, Galway
> > :me owl:sameAs<http://apassant.net/alex>  .
> >
> >
> >
> >
> >
> >
> >
>

Received on Thursday, 7 October 2010 11:49:52 UTC