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

Nicholas Humfrey's Review of "SPARQL 1.1 RDF Dataset HTTP Protocol"

From: Nicholas Humfrey <nicholas.humfrey@bbc.co.uk>
Date: Tue, 15 Feb 2011 13:50:08 +0000
To: Chimezie Ogbuji <chimezie@gmail.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-ID: <C9803510.362A3%nicholas.humfrey@bbc.co.uk>

This is my review of version 1.72 the SPARQL 1.1 RDF Dataset HTTP Protocol.

I would like to start by restating my support for this specification. While
much of is indeed based on other specifications and common sense, there are
multiple ways of bringing it all together and this specification does that.
It is also an excellent way for people less experienced in semantic web
technologies to understand and get started with a graph store.

Here are my observations:
1) In the examples in 5.2 and 5.4, shouldn't the header be 'Content-Type',
rather than 'Accept' to specify the mime type of the content that is being
sent to the graph store?

2) In the last example section 5.4, I think it would be helpful to provide
and example response to the POST request.

3) A default Content-Type (RDF/XML) is specified for when parsing a
POST/PUT. Perhaps there should also be a default Content-Type specified for
GETs too?

4) I was wondering if it would be helpful to use 'defacto' URLs in the
examples. Are there actually any graph store implementations using the URLs
shown in the example? I think it would be helpful if the examples worked on
at least one graph store implementation.

5) It is likely that quads based serialisations (N-quads, Trig etc.) will
become standardised. Perhaps some consideration should be put into how the
RDF Dataset HTTP Protocol should behave with quads?

6) I usually look forward to seeing a diagram in a specification because I
find them a quick way to understand what is being explained in the text.
However I didn't find these diagrams very easy to understand. Not a very
constructive comment, sorry!

I took the approach of trying to implement the specification while reviewing
it. RedStore used to behave a bit like 4store, but I have now updated it to
take the 'graph' parameter. There is a development build of RedStore online

Example of getting a graph:

Currently unimplemented features in RedStore:
- Using POST to create a graph with a graph store allocated identifier
- Getting / updating the default graph using the ?default parameter

This is how RedStore currently behaves:
GET /data   - Get all data in the store (useful as backup when nquads)
POST /data  - Insert data into the default graph.
              If data includes quads, it is inserted into appropriate graph
PUT /data   - Replace all data in the store - may include nquads.
DELETE /data  Remove all graphs and data from the store.

GET /graphs      - Return a list of named graphs in the store
GET /description - Return a service description of the store

I quite liked those URLs for their hierarchical tidyness, but I am going to
have to change them now because 'RDF Dataset HTTP Protocol' states that a
GET should return the service description. I know section 5.8 is only
Informative, but I wonder what its purpose is? By comparison GETting
/sparql/ doesn't return a service description?


This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
Received on Tuesday, 15 February 2011 13:50:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:45 GMT