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

Review of SPARQL 1.1 Protocol (part 1 - up to end of section2)

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Thu, 17 Nov 2011 11:19:23 +0000
Message-ID: <4EC4EDBB.7090404@epimorphics.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
=== Review of "SPARQL 1.1 Protocol for RDF"
Version of 16/Nov/2001

** Overall

Nothing major; some clarification and some editing.

Mentioning the target of an update is a Graph Store should be done.

The references need sorting out.

** Title

Remove " for RDF"

It adds nothing.  Not all results are RDF; queries and updates aren't 
RDF.  Is there a " for SomethingElse"?

It's a hangover from SPARQL 1.0 when it was "query for RDF"

** Abstract

"for conveying SPARQL queries and updates to a SPARQL
processing service"

It says "queries and updates to ... *a* ...service"

This reads as if it's one service for query and update. It's two 
services (it is possible for one endpoint to implement both but not 
presumed to do so).

** Introduction

"conveying SPARQL queries and updates from clients to query processors."
"conveying SPARQL queries and updates from clients to SPARQL services."

It's not just query processors these days.

** Introduction

Exapand the note about graph store protocol.
A separate document describes the SPARQL 1.1 Graph Store HTTP Protocol.			
A separate document describes the SPARQL 1.1 Graph Store HTTP Protocol 
which describes the use of HTTP operations for the purpose of managing a 
collection of graphs in the REST architectural style.

(this extra text is copied from that doc)

** Introduction

Ref to [SPARQL-Update] needed.

SPARQL query link is to http://www.w3.org/2009/sparql/docs/query-1.1/

** Introduction

We were going to have a consistent list of documents in all docs.

The set of SPARQL documents comprises:

* SPARQL 1.1 Query
* SPARQL 1.1 Update
* SPARQL 1.1 Protocol for RDF  (this document)
* SPARQL 1.1 Graph Store HTTP Protocol
* SPARQL 1.1 Entailment Regimes
* SPARQL 1.1 Service Description
* SPARQL 1.1 Federation Extensions
* SPARQL 1.1 Conformance Tests
* SPARQL 1.1 Query Results JSON Format
* SPARQL Query Results XML Format

** Terminology

Does this need "graph store" as well?

** Section 2
What is an operation?

Each operation is defined via one or more combinations of HTTP requests 
and responses.
I don't understand the idea of "one or more" here - isn't it one HTTP 
request and one response always.  The response is at least the status code.

The terminology section has:
SPARQL Protocol operation
An HTTP request and response that conform to the protocol defined in 
this document.
which is right.

** Section 2.1

"The query operation may be invoked with either the HTTP GET or HTTP 
POST method."

"A query operation MUST be invoked with either HTTP GET or HTTP POST"

(consistence with the update description in 2.2)

The current wording could read as allowing PUT as it says "may be 
invoked with" (not a RFC "may") which does not rule out anything else.

** Section 2.1.X

There are two unusual cases:

+ GET with a body [2.1.1]

I'd like this to be explicitly not allowed.

+ POST with a query string and form body [table & 2.1.2]

I think this is legal HTTP (but not common and I may be wrong about it 
being legal). A processing layer, like servlets, would just handle it.

What I'm not sure about is whether HTML forms can or do use the feature. 
  If it's used, we ought to allow it so plain-old HTML forms just work.

** Section 2.1.4

Move the sentence about protocol and query descriptions to the first 
para; make the note on rejecting it's own paragraph.

That is:
A SPARQL query is executed against an RDF Dataset. The RDF dataset for a
query may be specified either via the default-graph-uri and 
named-graph-uri parameters in the SPARQL Protocol or in the SPARQL query 
string using the FROM and FROM NAMED keywords. If different RDF datasets 
are specified in both the protocol request and the SPARQL query string, 
then the SPARQL service must execute the query using the RDF dataset 
given in the protocol request.

Note that a service may reject a query with HTTP response code
400 if the service does not allow protocol clients to specify the RDF 

** section 2.1.5

There's an @@ (it's the only one I could find)

** Section 2.1.7

"if the query string"
This is correct but there are two meaning of "query string"; HTTP query 
string from the URL itself and SPARQL query string.

Suggestion: "query string" => "SPARQL query"
The "string" isn't needed because of the following text about sequence 
of characters.

** Section 2.2.X

The target of an update is a graph store but it does not say this 
anywhere in the document.  The only use of "graph store" is in the 
reference to the Graph Store protocol.

2.2.3 talks about the dataset for the WHERE clause.

I think the doc needs 2.2.3 to discuss the graph store then 2.2.3->2.2.4 
for the dataset and WHERE discussion.

** Section 2.2.3

What about "WITH"?

** Section 2.2.5

See comment on 2.1.7 about "query string" + it's not a query.

"query string" => "SPARQL Update request"

"provide both human-readable and machine-processable"
"provide human-readable or machine-processable or both"

i.e. allow one or the other - not both.

** Section 2.3


"SPARQL query string"
"SPARQL query"

because "query string" has two uses.

Remove SOAP envelope and xml:base sentence.


PS References

While I appreciate the reference to "Aho, Sethi and Ullman" (the Red 
Dragon book), it's not mentioned in the doc.

Quite a lot of the references aren't mentioned.

e.g. IETF BCP 47, ISO/IEC *, Clark, ...

There's a mention of [UNISEC] in the text that isn't in the refs.

And [SPARQL] isn't in the references :-)
Received on Thursday, 17 November 2011 11:20:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:05 UTC