W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2011

Re: Review of Update

From: Paul Gearon <pgearon@revelytix.com>
Date: Tue, 15 Nov 2011 21:57:08 -0500
Message-ID: <CAOQ8B2G-pzbP+m_-fS=3wgj6nwPF8k+o8iF3BdDhgEEVVDsxnQ@mail.gmail.com>
To: Olivier Corby <Olivier.Corby@sophia.inria.fr>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
On Mon, Nov 14, 2011 at 11:38 AM, Olivier Corby
<Olivier.Corby@sophia.inria.fr> wrote:
> Hi,
>
> Here is my review of SPARQL 1.1 Update (action 555)
> http://www.w3.org/2009/sparql/docs/update-1.1/
> version of 2011-11-08
>
> Best regards,
>
> Olivier
>
> _________________
>
>
>
> W3C Working Draft 12 May 2011
> -> To be changed
>
> The end date of the Last Call review period is 29 July 2011.
> -> To be changed
>
>
> 2 The Graph Store
>
> Unless overridden (for instance, by the SPARQL protocol), **then** the
> unnamed graph for the store will be the default graph for any operations on
> that store.
> ->
> Unless overridden (for instance, by the SPARQL protocol), the unnamed graph
> for the store will be the default graph for any operations on that store.
>
> (remove "then")

Done.

> -- Comment: graph store should be written Graph Store in a consistent way.

Replaced all instances of "graph store" with "Graph Store".

> In the simple case, where there is one unnamed graph
> ->
> In the simple case where there is one unnamed graph
>
> (remove ",")

Done.

> 3.1 Graph Update
>
> The INSERT DATA operation adds some triples, given inline in the request,
> into a graph. This will create the destination graph if it does not exist.
> ->
> The INSERT DATA operation adds some triples, given inline in the request,
> into a graph. This **should** create the destination graph if it does not
> exist.

Done. Also added "If the graph does not exist and it can not be
created for any reason, then a failure MUST be returned."


> 3.1.2 DELETE DATA
>
>
> QuadDatas that contains variables or blank nodes is disallowed
> ->
> QuadData that contains variables or blank nodes is disallowed

Done.

> Blank nodes are not permitted in the QuadData, as these cannot match any
> existing data.
> ->
> Blank nodes are not permitted in the QuadData, as these **do not** match any
> existing data.

I prefer cannot here as it is more explanatory, I have made the change though.


> Example 3: Removing undesired triples from a graph
> ->
> Example 3: Removing triples from a graph

Done.


> Example 4:
>
> The query replaces an occurrence of "Desing" by "Design" but the Data before
> does not contain an occurrence of "Desing". So the example is misleading
> (although not false).

The data does contain this. Therefore I think that no change is required.


> 3.1.3 DELETE/INSERT
>
>
> The bindings for each solution are then substituted into the DELETE template
> to remove triples, and then in the INSERT template to create new triples.
>
> -> Explain what happens if a variable in the template has no value in a
> solution: this is processed as in construct-where ...

Added the following:
"Variables in the template that have no binding in a solution are
equivalent to a blank node. This will create a new node in an INSERT
template and result in no effect in a DELETE template."

> If no data is to be inserted, then no graph will be created, even if
> applying the operation to a different dataset would result in data being
> inserted.
>
> -> This sentence is not clear.

I'm presuming that it is the second part of the sentence that leads to
confusion. I have changed it to:
"If no data is to be inserted, then no graph will be created."


> -- Question:
>
> INSERT WHERE: what happens if INSERT has two graph patterns that insert the
> same blank node in two different graphs:
>
> INSERT {
> graph <g1> {?x ?p ?v}
> graph <g2> {?x ?p ?v}
> }
> WHERE {
> ?x ?p ?v filter (isBlank(?v))
> }

Originally, my understanding was that this would create two new blank
nodes. However, I believe that this may have now changed (I forget the
specifics of the conversation).


> Example 11:
>
> This example request removes both statements naming some resource "Fred" in
> the graph http://example.com/names, and also statements about that resource
> from the graph http://example/addresses (assuming that **any subject** in
> the graph http://example.com/names has corresponding triples in the graph
> http://example/addresses).
>
> ->
>
> This example request removes both statements naming some resource "Fred" in
> the graph http://example.com/names, and also statements about that resource
> from the graph http://example/addresses (assuming that **some of these
> resources** in the graph http://example.com/names have corresponding triples
> in the graph http://example/addresses).

Done.

> Example 11:
> Data after:
>
> # Graph: http://example.com/names
>
> This triple should be removed:
>
> <http://example/fred> foaf:givenName "Fred" .

Done. Also removed:

<http://example/fred> a foaf:Person .


> 3.1.4 LOAD
>
> The load operation is designed for RDF 1.0 where there is no syntax for
> named graphs.
> In the future, what will happen if the RDF document loaded from the URI
> contains named graph(s) ?
> In this case, load may not modify the default graph, and it may conflict
> with the "into graph" clause.

Question to be dealt with by the working group.

> Also, there is no indication of the format supported by LOAD: RDF/XML ?
> Turtle ? ...

This should be unambiguous in the file (the wrong format would be an
error). I presume that the file type should always have a MIME type?


> Note:
> For services which form the default graph from the unions of other graphs
> then CLEAR DEFAULT may have further implications which we leave unspecified
> here.
>
> ->
>
> Note:
> For services which form the default graph from the **union** of other
> graphs, CLEAR DEFAULT may have further implications which we leave
> unspecified here.
>
> (and replace  "then" by ",")

Done.

> 3.2 Graph Management
>
>
> support persistent empty named graphs
>
> -> the term "persistent" is used nowhere else in the document, it is not
> defined.

Changed to:
"... since Graph Stores are not required to record the existence of
empty named graphs."

Is this acceptable?


> 3.2 Graph Management
>
>
> # The ADD operation reproduces all data in one graph into another.
> ->
>
> # The ADD operation reproduces all data **from** one graph into another.

Done.


> 3.2.3 COPY
>
>
> Notation '' below is not clear:
>
> ( GRAPH IRIref_to | '')

Changed to:
  ( GRAPH IRIref_to )?


> Example 12:
>
>
> Data before:
>
> # Graph http://example.org/named
>
> -> should be in bold font
> -> prefix foaf: is missing

Already correct, like example 11 was. Perhaps someone has fixed the
examples before I got to look at this.


> Note that the original content in http://example.org/named is lost by a COPY
> operation.
> ->
> The "COPY" keyword is in capital with a size greater than other keywords in
> the doc.

Was not marked up as "code". Fixed.


> 3.2.4 MOVE
>
>
> Notation '' below is not clear:
>
> ( GRAPH IRIref_to | '')

Changed to:
  ( GRAPH IRIref_to )?


> As for COPY, if the destination graph does not exist, it will be created. By
> default, the service is expected to return failure if the input graph does
> not exist.
> ->
> "is expected" is ambiguous,
> prefer the service should or must

Added the word "MAY", since the destination not existing is the common
case. Returning a failure is only likely to be a desired option for
this systems that record the existence of empty graphs.


> Example 13:
>
> Note that the original content in http://example.org/named is lost by a MOVE
> operation.
> ->
> The "MOVE" keyword is in unusual king size capital.

Fixed.


> 3.2.5 ADD
>
>
> Notation '' below is not clear:
>
> ( GRAPH IRIref_to | '')

Changed.

> By default, the service **is expected to** return failure
> -> must or should

Changed to MAY (as per COPY).


> Example 14:
>
> Data before:
>
> # Graph http://example.org/named
>
> -> sould be in bold

Done.


> 4 SPARQL Update Formal Model
>
>
> Definition: Graph Store
>
> each named slot is pair of a graph
> ->
> each named slot is **a** pair of a graph

Done.


> 4.2 Auxiliary Definitions
>
>
> The Dataset-MERGE definition is currently not needed, we might drop it in
> the final recommendation.
>
> -> Drop this ?

Not dropped yet. Axel, are you happy for me to remove this?


> 4.2.1 Dataset-MERGE
>
> Gj for iri = iri'j such that irij in graphNames(DS') \ graphNames(DS)
>
> ->
>
> Gj for iri = iri'j such that iri'j in graphNames(DS') \ graphNames(DS)
>
> (replace irij by iri'j)

Done.


> 4.2.2 Dataset-UNION
> Definition: Dataset-UNION
>
> The Dataset-UNION between DS and **Ds'** is defined as follows:
> ->
> replace Ds' by DS'

Done.


> # Gj for iri = iri'j such that **irij** in graphNames(DS') \ graphNames(DS)
>
> ->
>
> replace irij by iri'j

Done.


> 4.2.4 Dataset( QuadPattern, mu, DS, GS )
>
> Add something like:
>
> We need to distinguish DS and GS  because, among others,  in case of  USING
> [NAMED] clauses, DS and GS may differ.

I have added: DS is distinguished from GS as they may differ, for
instance, due to the use of USING [NAMED] to modify DS.


> Let mu be a solution mapping, DS={DG} union {(irii, Gi) | 1 <= i <= n} be
> and RDF Dataset and GS be the current state of the graph store.
> ->
> Let mu be a solution mapping, DS={DG} union {(irii, Gi) | 1 <= i <= n} be
> **an** RDF Dataset and GS be the current state of the graph store.

Fixed. This was also present in the previous section.


> valid RDF triples
> -> Give a reference to define what is a valid RDF triple

Linked to http://www.w3.org/TR/rdf-concepts/#xtocid103646


> 4.2.5 Dataset( QuadPattern, P, DS, GS )
>
>
> Dataset(QuadPattern, P, DS, GS ) =
> Dataset-UNION( { Dataset(QuadPattern, mu) | mu in eval'(DS(DG),P) )
>
> ->
>
> Dataset-UNION( { Dataset(QuadPattern, mu, **DS, DG**) | mu in
> eval'(DS(DG),P) **}** )

Already done.


> Data before:
>
> # Default graph
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:b a foaf:Person .
> :s  a foaf:Person .
>
> prefix ":" is undefined

Defined to http://example.com/


> 4.3.5 Clear Operation
>
>
> and OpCleardef for clearing all graphs including the default graph.
> ->
> and OpClear**all** for clearing all graphs including the default graph.

Done.


> 4.4.2 DropOperation
>
> OpDropnamedfor dropping
> ->
> OpDropnamed for dropping

Done.


> 4.5 Mapping Update Requests to the Formal Model
>
>
> Table 1: Mapping from Update Requests to Update Operations
>
> CLEAR (SILENT)? DEFAULT    OpCleardef(GS, IRIref)
> CLEAR (SILENT)? NAMED    OpClearnamed(GS, IRIref)
> CLEAR (SILENT)? ALL    OpClearall(GS, IRIref)
>
> DROP (SILENT)? DEFAULT    OpDropdef(GS, IRIref)
> DROP (SILENT)? NAMED    OpDropnamed(GS, IRIref)
> DROP (SILENT)? ALL    OpDropall(GS, IRIref)
>
>
> should be:
>
>
> CLEAR (SILENT)? DEFAULT    OpCleardef(GS)
> CLEAR (SILENT)? NAMED    OpClearnamed(GS)
> CLEAR (SILENT)? ALL    OpClearall(GS)
>
> DROP (SILENT)? DEFAULT    OpDropdef(GS)
> DROP (SILENT)? NAMED    OpDropnamed(GS)
> DROP (SILENT)? ALL    OpDropall(GS)

Done.


> B Internet Media Type, File Extension and Macintosh File Type
>
>
>
> sparql update
> ->
> SPARQL Update
>
> (twice)

Done.

Regards,
Paul
Received on Wednesday, 16 November 2011 02:57:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:47 GMT