- From: Chimezie Ogbuji <chimezie@gmail.com>
- Date: Thu, 17 Feb 2011 23:54:23 -0500
- To: Nicholas Humfrey <nicholas.humfrey@bbc.co.uk>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Hello, Nicholas. See my response inline below. On Tue, Feb 15, 2011 at 8:50 AM, Nicholas Humfrey <nicholas.humfrey@bbc.co.uk> wrote: > ..snip.. > 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? Yes, I have made this change as well as to other parts where Accept is mistakenly used instead of Content-Type. > 2) In the last example section 5.4, I think it would be helpful to provide > and example response to the POST request. I've fleshed out that example to have an HTTP response > 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? I've added text in that location indicating that the default media-type to return an RDF document if Accept is not specified is RDF/XML > 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. Unfortunately, I'm not sure I know what you mean by defacto URLs? > 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? The one situation that comes to mind where a quad-based serialization would make sense would be for a PUT to a graph store. In an earlier email, I mentioned why this behavior is less well-defined than the POST scenario. Also, I'm not sure how appropriate it would be to use quads based serialization examples given their (current) standardization status. > 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! Ok, I'll look into modifications to them that might help with this. > ..snip.. > 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? To provide a mechanism for discovering the Graph Store URL, primarily. > By comparison GETting > /sparql/ doesn't return a service description? Does that identify a Graph Store? -- Chime
Received on Friday, 18 February 2011 04:55:17 UTC