# SPARQL1.1 Update review part 2

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 6 Oct 2010 23:58:04 -0400
Message-Id: <8A8B1495-DAB7-4911-867C-988CB68E9998@deri.org>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
```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
```
Received on Thursday, 7 October 2010 04:06:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:02 UTC