- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Sun, 06 Feb 2011 22:30:46 +0000
- To: Chimezie Ogbuji <chimezie@gmail.com>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
> Currently, http://host/graphstore is considered the Dataset HTTP > Protocol service. There is an assumption that the service location is > known apriori and the graph store URI is described in its service > description document. So the follow-your-nose pattern of discovery > is: > > GET .. dataset protocol service URL .. HTTP/1.1 > Host: ..hostname.. > > returns > > @prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> . > @prefix sd:<http://www.w3.org/ns/sparql-service-description#> . > > [] a sd:Service; > sd:defaultDatasetDescription<http://host/graphstore> > <http://host/graphstore> a sd:Dataset; ..snip.. But this says: http://host/graphstore a sd:Dataset ; and [] a sd:Service; which is odd to return from Dataset HTTP Protocol service http://host/graphstore If it said: <> a sd:Service; or <http://host/graphstore> a sd:Service; then it's a service and a dataset. Should it be: <> a sd:Service . <http://host/graphstore/dataset a sd:Dataset . > It is not clear to me what capabilities allowing other verbs (beyond > POST) would provide that you wouldn't already have (albeit at a level > of granularity no larger than a single graph) Looking to the possibility of RDF3-WG doing named graph, or something around that, and the existence of N-Quads and TriG already, the HTTP verbs have a natural meaning on the dataset/graph store as a whole. While I acknowledge this is to-be-decided-elsewhere, the formats exist today. Uses include dump and restore. >> There will be other URIs for >> services (query, update) anyway so leave this as the graph store and put the >> service description with a service URI. > > It seems more intuitive to me to have that be the service since that > already has a self-describing document format, is assumed to have a > location that is known apriori, and there seems to be less use cases > that motivate direct access to the graph store. It seems to me to be just as natural in a REST view-point that the things is the graphstore. If I think in service-style, then as a service works, but it seems just as valid to think in terms of having the graphstore itself named. I'm undecided on this currently. Andy
Received on Sunday, 6 February 2011 22:31:23 UTC