Review: SPARQL 1.1 Federated Extensions

This review discharges my ACTION-385.

Overall: I think this specification still needs a fair amount of work 
before it is ready for Last Call. Please see my detailed comments below.


* Title: Since we've moved BINDINGS to the query document, should we 
change the name of this document, since there are not multiple 
"Extensions"? Perhaps "SPARQL 1.1 Federated Query"?

* Status of this Document -- this should be updated to reflect the fact 
that this is now an active WG editor's draft. That said, this isn't that 
important since the SotD gets replaced when we publish as a WD.

* 1. Introduction. Suggest rewording the first few sentences like:

"""
This specification defines the syntax and semantics of the SERVICE 
keyword for SPARQL 1.1. The SERVICE keyword extends SPARQL 1.1 to 
support queries that merge data distributed across the Web.
"""

* 1. Introduction. Replace the listing of other documents with the full 
set of documents or a pointer to the overview document.

* 1.1.1 The only prefix listed here that's used elsewhere in the 
document is "xsd:".

* 1.1.2 I don't think the formal definition of "binding" helps much. If 
you do want to keep it, it should be in section 1.1.3 Terminology.

* 1.1.3 No need to repeat the information about IRIs. I'd remove the 
first paragraph.

* 1.1.3 "and used in SPARQL" => "and reused in this document" ?

* 2.2 BINDINGS needs to be removed. It can be referenced informatively 
from this document, but should not have its own section. Once this is 
done, Section 2 needs to be restructured so that it is all about the 
SERVICE keyword

* I think there needs to be at least an informative, informal 
explanation of the SERVICE keyword before diving in with examples. 
Perhaps the examples should all come after the syntax and semantics 
sections.

* I think the example should be more consistent both in presentation and 
content. Specifically, the example in 2.1.3 specifies that the data is 
part of the default graph for the endpoint, but the previous examples 
don't specify that. More troubling is the fact that the data in 2.1.3 
uses blank node subjects whereas the previous examples use URIs. It 
seems to me that all the examples could use a common set of endpoints 
and data which could be presented upfront before the examples. This 
might be easier to work with and less distracting as you read from one 
example to another.

* In 2.1.4, is this an appropriate use of dcterms:subject?

* I haven't tested this, but I think there's a syntax error in the 2.1.4 
example - there should be a "." after the "void:sparqlEndpoint" triple 
pattern, right?

* What is the status of variables in SERVICE? There is still an 
editorial note by the example in 2.1.4 that says this is unresolved. We 
need to clarify this before Last Call.

* 2.1.5 Why is returning no results considered a failure condition? I 
would omit that.

* 2.1.5 This text needs to be cleaned up to be more prescriptive. In 
particular, it should not say that "we propose" something or other. It 
should say something like "The SILENT keyword indicates that error 
encountered while accessing a remote SPARQL endpoint should be ignored 
while processing the query. The failed SERVICE clause is treated as if 
it had a result of a single solution with no bindings."

* 2.1.5 This section is presenting examples. It should not talk about 
algebra constructs such as the Service(...) construct.

* 2.1.5 The example should be improved. It should include valid data at 
the endpoint and indicate the comparative results when there is an error 
at the remote endpoint and when there is not an error. To make this as 
clear as possible, there should be another part to the query that just 
accesses the local default graph.

* 2.1.6 This section needs to be rewritten. It is very hard to 
understand. Here are some of the issues with is:
   * There is no example.
   * I don't understand the comparison with GRAPH.
   * The terminology needs to be tightened to align with terminology 
used in SPARQL query. (E.g., what is a "querying system"?)
   * As with 2.1.5, the text here should be more prescriptive, and less 
speculative sounding.

* 3 Syntax - I don't think all of these examples are necessary. I think 
that one sentence about the SERVICE clause would suffice, along with the 
grammar rules. That would be more consistent with how SPARQL 1.1 Query 
presents syntax.

* This section should include the SILENT keyword.

* Remove 3.2.

* 4.1 I don't think this should restate the text from SPARQL 1.1 Query. 
It should only include the new additions to the algorithm, along with a 
clear reference to where the new bit is inserted.

* 4.1 This doesn't seem to take SILENT into consideration.

* 4.1 The algebra expression given for an example seems to be completely 
incorrect. Can this be checked?

* 4.1. I think the definition is unclear as written. Specific questions 
I have are:
   * What is "B"?
   * What does "if IRI is a SPARQL service" mean?
   * What is omega?

* Remove 4.2.

* I'm unclear as to how 4.1 relates to 4.3?

* Remove 4.4

* 4.5 needs to be explained in the context of 4.1 and 4.3.

* The conformance section needs to be tuned specifically to federated query.


Lee

Received on Tuesday, 15 February 2011 04:00:42 UTC