SPARQL Protocol Review and Comments

Hi all,

I reviewed [1], which at the time was the current version, pointed to  
by  [2].


   It is my (personal) opinion that this document is not ready for  
publication until the WSDL 2.0 compliance issue in Section 2.2 is  
resolved.  The phrase "DAWG acknowledges the risk inherent in  
describing its protocol in an illegal variant of WSDL 2.0" is not  
sufficient to relieve the working group of its responsibility for  
interoperability.  Indeed, if this specification were to be published  
without resolution of this issue, I think it is quite likely that  
WSDL 2.0 implementations would not change to reflect it.  That would  
materially damage the SPARQL Protocol's likelihood of uptake.

   I understand that the DAWG has approached the Web Services  
Description Working Group on this issue and I wish them well in  
resolving it.

   My suggestion for resolution is to comply with the final WSDL 2.0  
specification (now in Last Call).  If the requirement for a single  
return type is not changed, then I suggest the DAWG create a new,  
lightweight XML format for query Out Messages to wrap query results  
in a single Internet Media Type.  The new format could hold an SRD,  
N3, etc.  Although I recognize the loss of efficiency that this  
entails, I believe that it is preferable to failing to comply with  
WSDL 2.0.  Similarly, the work should be done to address the (easier)  
WSDL 2.0 compliance issues in the presented binding before publication.

   I applaud the DAWG for catching the possibility for ambiguous RDF  
datasets between protocol and query language and resolving it cleanly.

2.  Important/Technical

   ERROR: In the first paragraph of Section 2.1.2, "called st:query- 
result" should be changed to "called st:query-request".

   ERROR:  The element name "query-result" in Figure 1.1, "XML Schema  
fragment", should be changed to "query-request".

   OMISSION: In the "Malformed Query" paragraph of Section 2.1.4, it  
is unclear what behavior is expected from a query processing service  
if a malformed query does not result in a MalformedQuery fault.  One  
way to solve this is to make such a fault mandatory ("must" instead  
of "should").  If that is not done, the document should say what kind  
of behavior to expect (is a QueryRequestRefused OK?  How about  
returning nothing?).

   SUGGESTION:  Section 2.2 says "if a SPARQL Protocol service  
supports HTTP bindings, it must support the bindings as described in  
sparql-protocol-query.wsdl.  A SPARQL Protocol service may support  
other interfaces."  If I am reading that correctly, it says that if I  
only want to have a RESTful interface and not WSDL, I am not  
compliant.  I don't like that in theory or in practice, especially  
since sparql-protocol-query.wsdl is currently broken rather badly.

   SUGGESTION:  The use of a diminutive ("Little Jo") in Section may be taken as insulting (or, worst, racist) by some and  
should therefore by changed to something else (e.g. "Jo").

   SUGGESTION:  Section 3.0, "Policy Considerations", states that  
query services MAY refuse to process certain query requests.  In that  
case, I suggest making it clear that they MUST do so as defined in  
Section 2.1.4.

   SUGGESTION:  In Section 3.0, the phrase "may be constrained by law  
in some countries" should be changed to "may be constrained by law in  
some jurisdictions".

   QUESTION:  In the first paragraph of Section 2.1.2, could the  
phrase "represented in the message schema by query" be deleted  
without changing the intention?  Does the reference to the "message  
schema" refer to another document?

   QUESTION:   There are references to both IRIs and URIs in this  
document.  Does that represent the state of IRI uptake or an error?

   QUESTION:  Was the Content-Type of the example query intended to  
be "application/x-www-form-urlencoded"?

   QUESTION:  I noticed that the SPARQL Query Language for RDF  
working draft [3] (as of Revision 1.390  2005/06/13 13:37:19) removed  
references to bnodes in results.  Should the bnode used in Section in the example result be removed?

3.  Formatting

   ERROR: The title of Section 2.1.2, "query-result In Message"  
should be changed to "query In Message" to be consistent with the  
titles of Sections 2.1.1, 2.1.3 and 2.1.4.

   SUGGESTION:  The "PREFIX foaf: <>" lines  
in the SPARQL example queries in Sections, and are not used and should be deleted.

4.  Nits

   SUGGESTION:   The <documentation> section of Figure 1.0, "WSDL 2.0  
fragment" in Section 2.1.1 ends in two periods (full stops for those  
who learned English in the Commonwealth) instead of one.

   SUGGESTION:  In the first paragraph of Section 2.1.4, I suggest  
deleting the words "described here".

   SUGGESTION:  In the "Malformed Query" paragraph of Section 2.1.4,  
I suggest changing "should be returned, but an HTTP" to "should be  
returned.  An HTTP".



Received on Tuesday, 20 September 2005 21:49:49 UTC