W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

Re: [ISSUE-30] Suggestions for HTTP protocol updates

From: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>
Date: Thu, 4 Jun 2009 12:45:33 +0200
To: public-rdf-dawg@w3.org
Message-Id: <200906041245.33445.Kjetil.Kjernsmo@computas.com>
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/


Computas AS  PO Box 482, N-1327 Lysaker | Phone:+47 6783 1000 | Fax:+47 6783 
Received on Thursday, 4 June 2009 10:47:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:55 UTC