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

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