- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 14 Dec 2011 10:00:20 +0000
- To: sparql Working Group <public-rdf-dawg@w3.org>
(from this week's telecon - this email picks off this one point in the hope of "divide-and-conquer" progress) The GET on a graph store URI is defined to return the service description. We didn't understand why. The RDF-WG is (likely to) define formats for n-quads and TriG that can represent an RDF datasets. GET <uri> returns a representation of the resource at <uri>. So returning n-quads seems natural (an implementation can 403 it if it's too big). A service description describes a service and its endpoints. It connects a service to a dataset with sd:defaultDataset. If GET of the graph store URI is the SD then don't we have: <uri> sd:defaultDataset <uri> . A graph store is a container of graphs (unnamed and named). It is not a general RDF processing service. It might be that the graph store URI is overloaded with ?query= and ?request= functionality but it is overloading the service endpoints with the resource itself. In this case alone, does returning the SD make complete sense to me. I can see why returning a description of the graph store makes sense and the SD vocabulary has language for that but that's only a part of the service description. 1/ Should the return at least be a description of the graph store (using the sd:defaultGraph sd:NamedGraph etc vocab)? 2/ Could we allow GET on a graph store URI return quads? Andy
Received on Wednesday, 14 December 2011 10:03:18 UTC