- From: Paul Gearon <pgearon@revelytix.com>
- Date: Tue, 15 Nov 2011 21:57:08 -0500
- 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 UTC