- 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>
Hello, 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 here: http://hadrian.aelius.com:8080/ Example of getting a graph: http://hadrian.aelius.com:8080/data/?graph=http%3A//moustaki.org/foaf.rdf 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? nick. http://www.bbc.co.uk/ 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 UTC