- From: Chimezie Ogbuji <chimezie@gmail.com>
- Date: Sat, 5 Feb 2011 00:27:08 -0500
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Okay. So, if I'm not mistaken, currently the Dataset Protocol is the only protocol that allows a client to access the graph store and the only kind of access currently sanctioned is POST which is used to add a named graph to it and allow the service to allocate a graph URI for it (ala. the Atom Pub collection usecase). On Fri, Feb 4, 2011 at 4:23 AM, Andy Seaborne <andy.seaborne@epimorphics.com> wrote: > ..snip.. > This matters because GET behaves differently: > > GET <service> -> service description > > GET <graphStore> -> TriG for the store if allowed. This behavior is not currently specified. > Looking forward, with the new RDF WG, we do need to leave the possibility of > the graph store having a URL and GET/PUT to that URL. Where do you envision this method would be specified (in which specification)? > There may be multiple services (endpoints) on one graph store. > In Fuseki, I currently have both a service URI and a graph store URI > > If the graph store is: http://host/dataset > > The services are: > > # RDF Dataset HTTP Protocol > http://host/graphstore/data > ..snip.. > My preference is for http://host/graphstore?graph=... to mean that > http://host/graphstore is the graph store. 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.. 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) > 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. -- Chime
Received on Saturday, 5 February 2011 05:28:01 UTC