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

On Thursday 04 June 2009 13:35:06 Simon Schenk wrote:
> Hi,

Hi! Sorry about the long ping times, I've been too busy on other fronts.

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

So, we are amongst the many who have not designed the graph names we use to be 
dereferencable, there hasn't been any reason to so far. I think we need to 
consider two different situations: 1) You can control the namespace URI, you 
just haven't designed them to be dereferencable, 2) You wish to use a graph 
name that is used elsewhere, where you do not control them. 

A good example of the latter is if you want to import local copy of DBPedia, 
and you wish to use the DPBedia graph name URI. I think that would be 
perfectly legitimate. I think that's the actual hard problem. 



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

No, it wouldn't. It would only require you support PUT on the Apache server 
there. Actually, I think this is the crucial point, as this is very simple.


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

OK, I do not understand what's unclear about the semantics here.

My idea is that if you want to operate with a SPARQL Endpoint in addition to 
just PUTting to the URI, you would indeed put some logic at  
http://www.uni-koblenz.de/~sschenk/foaf.rdf
that would replace, add or delete triples in the quad store underneath.

And I think I could write the code to do that in an hour, and it would be 
genuinely useful. So, even though we didn't design our graph URIs to be 
dereferencable, they would become with very little effort. 

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

I very much disagree. If we do a), we have something that with very little 
effort but in the spec phase and in implementations is genuinely useful, yet 
harder to achieve by other means.

The reason why I think b) should be a time-permitting feature is that you can 
do exactly the same thing with the language:

INSERT DATA INTO <http://www.uni-koblenz.de/~sschenk/foaf.rdf> {
 <#your> <triples/> </here>
}

or (in my above example):

INSERT DATA INTO <http://dbpedia.org> {
  <http://dbpedia.org/resource/SPARQL> dc:title "SPARQL Query Language for 
RDF" . 
}

so it is actually this one that doesn't give us that much. And considering the 
permathreads it will provoke, I think it should be time-permitting. It is not 
that I don't want it, it is just that I see a) as not only much more useful, 
it is also very simple to implement.



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 Tuesday, 9 June 2009 09:52:45 UTC