- From: Chimezie Ogbuji <chimezie@gmail.com>
- Date: Wed, 2 Feb 2011 12:14:59 -0500
- To: public-rdf-dawg-comments@w3.org, Leigh Dodds <leigh.dodds@talis.com>
Hey Leigh. See my response below. Note, this is not an official WG response, but my attempt to extract some actionable specifics from various points you raised below. On Wed, Feb 2, 2011 at 11:23 AM, Andy Seaborne <andy.seaborne@epimorphics.com> wrote: > ..snip.. > The Atom protocol is a good resource to draw on, not just in terms of > the simplicity of how the operations are documented for developers (of > both audiences), but also in terms of a basic model for the protocol > itself. The organization of the document is influenced by the Atom protocol. Do you have some examples of places in the specification that contrast the writing style (or protocol model) of the Atom protocol? > Ian raised the issue of describing operations on a dataset, including > listing graphs. In my view there ought to be a simple RESTful way to > interact directly with the dataset, treating it as a container of > graphs that can be added and removed, similar to Atom collections. Yes, the secondary POST operation (described in 5.3 HTTP POST) was directly motivated by the Atom collection use case (and from an earlier comment and request from you for this behavior, if I'm not mistaken). > I'm not convinced that the Service Description document fulfils that > particular role. As described in 5.3, when the request URI of an HTTP POST identifies the Graph Store, then the result will be the addition of a new graph to the store. Note the editor's note in the bottom of that section which seeks input from the community on this exact question. The idea currently is that an OPTIONS (or GET) request to the service directly will return an SD document, which could include statements about instances of sd:Dataset and the corresponding URL would be understood to be the URL of the Graph Store. Does this mechanism address the usecase you have in mind? > The current Working Draft suggests returning an > reference to a description document from an OPTIONS request. But I > think there are several issues with that: > * I may be misunderstanding, but Service Description documents are > accessible from the URI of a SPARQL endpoint. However I'm not sure > there's necessarily a 1:1 mapping between a GraphStore and SPARQL > endpoint. See above. The scenario is as follows. If the URL to the endpoint is http://example.com/sparql-endpoint then GET /sparql-endpoint HTTP/1.1 Host: example.com Then response (as N3/Turtle) could be: @prefix sd: <http://www.w3.org/ns/sparql-service-description#>. [] a sd:Service; sd:url <http://example.com/sparql-endpoint>; sd:defaultDatasetDescription <http://example.com/graph-store> . <http://example.com/graph-store> a sd:Dataset; sd:defaultGraph ..snip..; sd:namedGraph ..snip.. So, from this the client would glean that the URL of the Graph Store is http://example.com/graph-store and can then dispatch HTTP POST requests with an RDF document as the body in order to add an RDF graph to the Graph Store and have the service return the newly minted URL of the graph. Does this clarify the mapping for you? If an example like this was incorporated into the text, would it address your concerns about this relationship and usecase? The remaining points below will need to be addressed by the WG since it raises a larger issue of the relationship between an endpoint and the (possibly many) Graph Stores it manages as well as the issue of how to manipulate a named graph within a particular Graph Store. > * It's (still) not clear to me how GraphStore relates to Dataset. > * The service description document indicates that a SPARQL endpoint > may expose several datasets, so how does a client identify the correct > Service or Dataset in the description. > * If a GraphStore supports the creation and management of datasets, > then presumably these need to be identified so I can interact with it, > e.g. to DELETE it? If not then how do I add/remove graphs from a > specific dataset? > * From a Service Description document I should be able to find the URI > for manipulating a specific sd:Graph via the Uniform Protocol. It's > not enough to simply reference the URI of the service as that will > require URI construction on the client side. Chime
Received on Wednesday, 2 February 2011 17:15:56 UTC