Re: Review of SPARQL 1.1. Update editors' draft

Hi Lee,

Thanks a lot for your feedback.
Here are some first answer regarding your comments / queries.
I'll let Paul complete some points, and we'll get back to you re. other unanswered comments

On 16 May 2010, at 03:53, Lee Feigenbaum wrote:

> This mail discharges ACTION-229.
> 
> I do not see any issue that should prevent us from publishing the current editors' draft as a public Working Draft.
> 
> That said, I do have a lot of feedback that I hope is helpful to the editors:
> 
> ~~ May, 2010 Review of SPARQL 1.1 Update Editors' Draft ~~
> 
> == Structure ==
> 
> * I'd expect us to have a Conformance section near the end of the document. (Similar to http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#conformance)

done

> 
> * I'd suggest removing 1.1. There are a lot of things that SPARQL Update is not (e.g. a fully transactional update language), and I don't think we need to enumerate those.

Right - I however think that it might be useful to reference some of them. 
Is that somehow the purpose of the overview doc ? If so, I'm ok for removing that part

> 
> * 3.2 "An implementation must target SPARQL queries on updated graphs if the SPARQL and SPARQL 1.1 Update end points are the same." This sounds like it belongs in the protocol document, not in the update document.

right - removed that sentence. Should it go in 2.1 of the protocol document ?

> 
> * 3.2.1. I think this belongs in section 5 -- this is the start of a formal model for update.

done - section moved

> 
> * 3.2.2 I think this does not belong in this document. Perhaps in the entailment document, or else not in the SPARQL 1.1 documents at all?

I think it's important to mention it. I'd prefer it there but I'm fine as well if it goes in the entailment one and if we then refer to it from that Update document.
I haven't change anything here so far.

> 
> * 4. A single Graph Update operation can add/remove triples from multiple graphs, right?
> 

Yes, considering for instance a DELETE/INSERT operation. I changed to "addition and removal of triples from some graphs within the graph store"


> * 4 "Syntax" - I feel like the title of this section should be "SPARQL 1.1 Update Language" or something like that. It's far more than syntax.
> 

right - title edited

> * The subsections within 4.1 and 4.2 ought to all be named consistently--either with the names of the statements (as in 4.1) or with a short description of the operation (as in 4.2).

Edited with names of statements.

> 
> 
> ==Substantive==
> 
> * We need to determine which parts of the specification are normative and which are informative.

Right - I guess it's worth a larger discussion in the group - or between editors first and then ack. by the group ?
I don't recall how it was done for other docs.

> 
> * We haven't closed ISSUE-37, but I would propose that:
>  PROPOSED: Close ISSUE-37 noting that SPARQL 1.1 will not address basic federated update in any way, no change needed.

I agree with the proposal but I haven't seen such proposal in minutes of previous TC. 
Could it be addressed in tomorrow's t-con ?

> 
> * 3. I think that the definition of a Graph Store is confusing. In particular, I don't understand the difference/relationship between the unnamed graph and the default graph. (This confusion applies for me throughout the document.)

Could you elaborate on the confusing aspects here ?

> 
> * 3. What is an update service?

I guess that's a "SPARQL Update endpoint" ?
That's reference several times in the doc so I'll let Paul confirm before doing any change.

> 
> * 4. The fact that one operation's failure aborts the rest of the operations within a request seems to be a normative conformance aspect of the language. As such I'd suggest s/will abort the sequence/MUST abort the sequence/.

right - done

> 
> * 4.1 "Graph update operations change existing graphs in the Graph Store but do not delete them." Given the provision that empty graphs can be removed after any operation, this statement is not strictly true, right?

indeed, I'd suggest "Graph update operations change existing graphs in the Graph Store and may delete graphs when DELETE/DELETE DATA operations lead to graph(s) with no triples."
Haven't changed anything so far.

> 
> * 4.1.1/4.1.2 Is it purposeful that a single INSERT DATA or DELETE DATA operation can only act on a single named graph? I believe the operations would be equally streamable if graph_triples was graph_triples*.
> 
> * 4.1.3. I think the treatment of WITH and USING / USING NAMED is still unclear. In particular, what's the relation between the two? The text about WITH seems in conflict with the text about USING. Also I think that we need to be explicit about what USING and USING NAMED do, rather than just asserting that their behavior is identical to FROM and FROM NAMED from SPARQL Query.
> 
> * 4.1.3. "Recall however that for any clause that stipulates its own GRAPH or USING modifiers, then the WITH will be ignored for that clause." This doesn't seem strictly true... Can't a DELETE or INSERT clause contain both triples within a GRAPH clause _and_ unadorned triples (that would be affected by WITH)?
> 
> * 4.1.3. "It is legal for an operation to attempt to delete from a graph that does not exist" - Does this mean the result of this is success? Also, probably would be better to avoid the phrase "it is legal" in non-de-jure standards. :-)
> 
> * 4.1.6. LOAD <...> INTO GRAPH DEFAULT sounds weird. Could we make that case just be LOAD <...> INTO DEFAULT? (This also relates to the general confusion between unnamed graph and default graph and the Query notion of a default graph.)
> 
> * 4.1.6. LOAD needs more explanation of what documentURI means. Do I need to dereference this URI? Is it an indirect relationship between the URI and the triples to be loaded (a la FROM/FROM NAMED)? That is, can I ever do LOAD <urn:TheGraph> INTO GRAPH <...> ?
> 

I'd suggest to replace documentURI by remoteGraphURI, adding that : "The remoteGraphURI has to be dereferenced and the retrieved triples should be added in the Graph Store into the specified graph or the default graph"
Will it be explanatory enough ?

> * 4.1.7 Same comment regarding "GRAPH DEFAULT" sounding weird.
> 
> * 4.1.7 "This operation does not remove the graph from the Graph Store." - This is not strictly true given the ability for implementations to remove any empty graph at any time, right?
> 

right - proposed: "This operation does not remove the graph from the Graph Store, but implementation may decide to do so."

> * 4.2 What does it mean that graph management operations are optional? How should a conformant implementation behave that doesn't want to create/remove graphs?
> 
> * 4.2.1 "The graph store does not record empty graph" -- What does this mean? I thought we agreed to deal with these implementations by allowing stores to (theoretically) remove empty graphs at any time, in which case this sort of store would just be a normal success, followed by a silent removal of the empty graph. (In which case this does not need to be called out specially here.) Similarly, the failure modes can be simplified to failing to create a graph or the graph already existing. Similarly for section 4.2.2.
> 
> * Section 5: As we've discussed, we need a formal model for the update language. I think it needs to cover (perhaps among other things), Graph Store, transformations on a graph store, transformations on a graph, what it means to "process" a triple, success and failure criteria for each operation, what it means to optionally remove an empty graph between operations, what it means to abort later operations in the face of failure of one operation, the relation between Graph Stores and RDF datasets, the relationship between the unnamed graph and default graph, the processing model of DELETE/INSERT statements ...
> 

So far, I moved previous 3.2.1 here, and added a note re. the upcoming formal model.


> ==Editorial==
> 
> * We ought to update the editors to include Alex.

done

> 
> * Abstract: "It uses a syntax derived from SPARQL." -> "It uses a syntax derived from the SPARQL Query Language for RDF."

done

> 
> * Introduction: The first paragraph tries to justify the language's existence. I think it would be better off left out. If it's kept, I do not think that SPARQL Update is a "mechanism by which updates to a remote RDF Store can be described, communicated, and stored." The language does not rely on a remote store, and it does not talk about storing updates. As far as I can tell, it's a language for specifying and executing updates to an RDF graph store.
> 

I'd liketo keep such an introduction sentence / paragraph.
Yet, based on your comments, I rephrased to "It is intended to be a standard language for specifying and executing updates to RDF graphs in a Graph Store"

> * Introduction: s/RDF Graph/RDF graph/

done

> 
> * Introduction: s/query processors/SPARQL endpoints  --  though once Axel and I get around to writing an overview document, we might merge these two paragraphs with the content of the overview document to help readers understand how the specifications fit together.

done

> 
> * 1.2.1. What is a SPARQL request? Better as "SPARQL Update statement"? Or perhaps "SPARQL Update request"?

Replaced by "SPARQL Update requests"

> 
> * 1.2.1. s/derived from SPARQL/derived from SPARQL Query/
> 

done

> * 1.2.1. It may just be my OS/browser setup, but I have a very hard time telling the bold fixed-width font from the non-bold fixed width font.
> 
> * 3.1 The second two sentences are confusing. I think they're trying to say:
> 
> """
> A query service MAY offer an RDF dataset formed from graphs that are part of an update service's Graph Store. The graphs in the query service's RDF dataset MAY be a subset of the graphs in the update service's Graph Store. Furthermore, the query service's RDF dataset and the update service's Graph Store may use different names for the same graphs.
> """
> 
> * 3.1 Note -- there's nothing in 2.1 that seems related to this any longer?
> 
> * 3.2 I think we should strike "SPARQL 1.1 Update services are provided over the SPARQL 1.1 Protocol for RDF." The protocol layers on top of the Update spec (as with query)--Update can be used via other mechanisms rather than the protocol (e.g. an API), so the Update spec. should not need to make reference to the protocol.
> 

are -> may ?
 
> * 3.2 What does "This requirement should address concurrency issues." mean? I don't think we need to explain why an implementation might not satisfy a SHOULD condition.
> 
> * 4. s/must Be/must be

done

> 
> * 4. s/will be terminated/is terminated

done

> 
> * 4. I think we probably should simply refer to operations resulting in either success or failure, rather than talking about returning state. In the absence of an access mechanism such as the protocol, it feels a little strange to talk about _returning_ results. (Not sure how strongly I feel about this or not.)

Fair enough.
Note that I also updated the failure sections to remove any reference to the number of added / removed triples as part of the answer.

> 
> * 4.1. Re-format as a bulleted list? I might move these descriptions out of this summary area and into the subsections on the specific language statements.
> 
> * Throughout the document, I think it would be helpful for examples to be more complete, showing the Graph Store before the operation and then again after the operation.
> 
> * 4.1.2. The example here does not separate operations with a semicolon.

done

> Also, the example is written in a way that implies to me that the PREFIX declaration applies to all of the operations in the request, when I thought the intent was that PREFIX was attached to a single operation.

Indeed, the current SPARQL Query grammar (currently referred to in SPARQL Update) indicates that PREFIX definitions apply for a single operation.
I personally like having the PREFIX definition shared between operations when there are several operations in the same request.
When adding the UpdateOperation in the SPARQL grammar, it could be done as follow to solve this issue

Query	  ::=  	Prologue
( SelectQuery | ConstructQuery | DescribeQuery | AskQuery | UpdateQuery* )

> 
> * 4.1.3. What does the comment "# UPDATE outline syntax : general form:" mean?
> 
> * 4.1.3. I think this section would benefit from being re-formatted as a numerical list of steps outlining the processing model. I find it hard to internalize the process described by the prose.
> 
> * 4.1.3. Is the example improved by removing "?person foaf:firstName 'Bill'" from the WHERE clause? It's not necessary, right?

> 
> * 4.1.3/4.1.4/4.1.5. I think this might be clearer if 4.1.3 made DELETE and INSERT optional, and then 4.1.4 and 4.1.5 _only_ presented and talked about the shortcut forms.
> 
> * 4.1.5 The last example in this section needs a semicolon to separate operations.

done

> 
> * References don't seem to be accurate.
> 
> Lee
> 

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Monday, 17 May 2010 11:39:03 UTC