- From: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>
- Date: Thu, 4 Jun 2009 12:45:33 +0200
- To: public-rdf-dawg@w3.org
On Wednesday 03 June 2009 11:45:01 Simon Schenk wrote: > Hi, > > I thought a bit about the design space for the RESTful protocol. I guess > we have to distinguish the following cases: > > a) A graph is accessible at the URI, which also happens to be it's name. > Some standard Webserver might be sufficient here. For SPARQL/Update this > is just a corner case. In what sense is it a corner case? Indeed, for SPARQL/Update, the URI is just a name and not different from any other name, but for the HTTP server it is what makes it simple and straightforward from a Webarch and REST perspective. > b) A SPARQL endpoint holds a set of named graphs and a default graph. > > b1) We talk about a dataset in the SPARQL/Query sense. There can be many > such datasets available at the endpoint. We need to identify the dataset > as well as the graphs in the dataset. > > b2) We talk about a graph store, consisting of a default graph and a set > of named graphs. > > I propose to ignore a), as it is a corner case. > I propose to ignore b1), as it becomes complicated, once we start > talking about datasets as first class objects. > > My thoughts about b2): This is, if I understand you correctly, almost the opposite of my proposal. I think that a) should be the requirement, b1) ignored, and b2) mostly left to the language, but a time-permitting feature if we can find a way to gracefully reconcile it with Webarch and REST. Kind regards Kjetil Kjernsmo -- Senior Knowledge Engineer / SPARQL F&R Editor Mobile: +47 986 48 234 Email: kjetil.kjernsmo@computas.com Web: http://www.computas.com/ | SHARE YOUR KNOWLEDGE | Computas AS PO Box 482, N-1327 Lysaker | Phone:+47 6783 1000 | Fax:+47 6783 1001
Received on Thursday, 4 June 2009 10:47:04 UTC