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

Hi,

Am Donnerstag, den 04.06.2009, 12:45 +0200 schrieb Kjetil Kjernsmo:
> ught 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.

Jep. But the problem is, I do not think, that a high percentage of
SPARQL endpoints (or graph stores) available at http://my.server/sparql
restrict the valid graph names to http://my.server/sparql*. Hence, while
a) is architectually very nice and clean, I doubt it has much practical
use. There will not be many graphs, which could be modified that way. 

Now consider the following example: If I wanted to update
http://www.uni-koblenz.de/~sschenk/foaf.rdf, then that would require
http://www.uni-koblenz.de/~sschenk or http://www.uni-koblenz.de to be a
graph store endpoint. OK, fair enough. But we already have a properly
configured Apache there, to I do not need a SPARQL/update spec to get
the desired behaviour. But I have an endpoint at
http://demetrios.isweb.uni-koblenz.de/openrdf-sesame/, which contains
this graph. If I want to update the graph in the store. Unfortunately,
in this case the semantics is not as clear. Hence, I need a spec here. 

I think it makes more sense to spend our time on something, which is
broadly usable, though maybe more complicated, than on a feature, which
only works under certain assumptions. If we only support a) I guess we
can as well save time and drop REST support altogether (which would be a
pity). 

> > 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.

I guess, yes. The reason is: requiring a) does not seem sensible to me,
as I explained above, and b2) is the common case, which should be
addressed.

Best regards,
Simon

-- 
Simon Schenk | ISWeb | Uni Koblenz
http://isweb.uni-koblenz.de
http://www.uni-koblenz.de/~sschenk