- From: Leigh Dodds <leigh.dodds@talis.com>
- Date: Fri, 11 Feb 2011 12:06:05 +0000
- To: Chimezie Ogbuji <chimezie@gmail.com>
- Cc: public-rdf-dawg-comments@w3.org
Hi Chimezie, Thank you for the considered response, and apologies for being slow to respond. I've inlined answers to your questions and some additional comments. On 2 February 2011 17:14, Chimezie Ogbuji <chimezie@gmail.com> wrote: > 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? The Atom Protocol spec leads directly with the different types of resources being managed, and clear diagrams and illustrations of the HTTP protocol. The Uniform Protocol spec instead largely maps things to SPARQL Update operations. >From a user-developer perspective I'd prefer to see some clear examples of how the protocol is intended to operate, complete with HTTP operations, right from the outset. >From an implementor-developer perspective, the mapping to SPARQL Update operations is a useful guide to how this protocol could be implemented as a layer over that language. But that's really just one approach, so perhaps should be moved to a non-normative section. My other area of concern relates to the lack of "Dataset" as a resource that is managed by this protocol. My view is that this is a specific type of resource, analogous to an Atom Collection, that I should be able to RESTfully manage. >> 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). Yes that's correct, I did suggest that enhancement. But that feature supports client's submitting data without wanting to or needing to care about the graph URI. It also supports servers in deciding to manage their own graph identifiers. However my comment relates to management of Datasets, not graphs. I think it would be useful to be able to: * Add/Remove Datasets * Add/Remove Graphs from Datasets The specification already discusses the addition and removal of Graphs. Datasets added via a RESTful interface might then be available via a SPARQL endpoint that shares the same backing store. This seems me to map onto the model that's implicit in the Service Description documentation which indicates that a SPARQL endpoint might have several datasets, and that those datasets contain graphs. However at present the Uniform Protocol does not describe how to create datasets. >> 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? I've commented on your specific example, below. >> 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? This is a good example and helps focus the discussion. I think a number of my issues relate to confusion between the Uniform Protocol and the Service Description document. As a general point I think the Service Description definitely needs more examples. Some further questions: >From your example it appears that a "Graph Store" IS a sd:Dataset, which is defined to be a SPARQL Dataset. So why use the term Graph Store at all, why not say, explicitly in the Uniform Protocol that its a protocol for managing datasets? That is much clear, IMO If I perform an HTTP GET on <http://example.com/graph-store> what is returned? I'd expect to retrieve a description of the dataset, i.e. a list of the graphs, that it is made up of. From a REST and Linked Data perspective, I'd expect to be able to access the resources directly, not have to refer to a Service Description document. How do the sd:defaultGraph and sd:namedGraph predicates in the Service Description document relate to the uniform protocol? The only example shows these as blank nodes, with sd:name giving the URI of the graph to be used in a SPARQL query. However I'd expect these predicates to refer to resources accessible via the Uniform Protocol, i.e. so I can GET/PUT/DELETE the graphs. The Service Description document defines a concept of Graph Collection (http://www.w3.org/TR/sparql11-service-description/#sd-GraphCollection) its not clear to me what this is for, and whether it relates to the uniform protocol. If "Graph Store" == Dataset, then how does a Dataset get added/removed from a SPARQL endpoint? You may decide this is outside scope of the specification, but it could perhaps be acknowledged as a potential extension > 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. OK, understood. I think most of my confusion relates to that area. The Service Description document seems to have been written purely as an attempt to describe useful metadata about a SPARQL endpoint. The Uniform Protocol addresses exposing collections of graphs (or datasets?) via HTTP. But there are areas of overlap that are unclear to me (at least). It also seems to me that I should be able to implement the Uniform Protocol without necessarily exposing a SPARQL endpoint or using SPARQL Update to manage the graphs. Cheers, L. -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.dodds@talis.com http://www.talis.com
Received on Friday, 11 February 2011 12:06:39 UTC