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

Re: [ACTION-33] Trying to sort the SPARQL/Update issues.

From: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>
Date: Wed, 27 May 2009 14:08:30 +0200
To: public-rdf-dawg@w3.org
Message-Id: <200905271408.30624.Kjetil.Kjernsmo@computas.com>
On Wednesday 27 May 2009 11:40:45 Steve Harris wrote:
> I'm not sure what the value of "several" is, but I'm one of those.

Me too.

> There are lots of usecases around having the RDF data locally, and  
> wanting to send it to the RDF store without parsing it into a big  
> INSERT statement. It also makes RDF stores behave in a more obviously  
> RESTful way.

Indeed, and it does make updating data trivially simple in many cases, both on 
the client and the server side. 

> When the stores PUT endpoint matches the start of the graph URI this  
> is trivial, eg for the endpoint http://store.example.com/graph/ you  
> can write to http://store.example.com/graph/data.rdf, trivially with
> PUT http://store.example.com/graph/data.rdf HTTP/1.1
> Content-type: ...
> [send data]

Yeah, but I wouldn't restrict it to endpoint URLs. It would be really trivial 
to write something that dealt with the HTTP stuff and interacted with a quad 
store deeper down, and I think implementers should be free to do that. They 
may not even choose to expose an endpoint, just allow people to PUT new 
graphs. 


> But there is also a sub-usecase (2b), where the graph URI does not  
> start with the URI of the endpoint, where it gets a bit tricky. This  
> is useful if you want to restore a RDF store from backups of it's RDF  
> graphs, which is something we do in Garlik, then you want to be able  
> to control the graph URI that the RDF data is restored to.

Yeah, this was the discussion I tried to start with my "Data loading cases" 
email on Monday. I'd like it too, the question is if this is something that 
should be done in the HTTP protocol or if INSERT DATA would be sufficient?

> Currently we use:
>    PUT http://store.example.com/graph/http://source.com/data.rdf
> for example to restore to http://source.com/data.rdf. But this is  
> fairly ugly, and probably a little strange.

Yeah, and a violation of "URI Opacity" best practise recommendation:
http://www.w3.org/TR/webarch/#uri-opacity
wouldn't it?

> Another option would be something like
>    PUT
> http://store.example.com/graph/?graph=http%3A%2F%2Fsource.com%2Fdata.rdf
> ...

Looks nice.

> [ This could also be reused to POST in data to be appended, as POST  
> has no obvious destination in its description. ]

Yep.

> Logically you would also expect
>    GET
> http://store.example.com/graph/?graph=http%3A%2F%2Fsource.com%2Fdata.rdf to
> do something equivalent to
>    CONSTRUCT 
[...]

Yep. 

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 Wednesday, 27 May 2009 12:10:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:39 GMT