- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 27 May 2009 11:09:35 +0000
- To: Steve Harris <steve.harris@garlik.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Steve Harris
> Sent: 27 May 2009 10:41
> To: RDF Data Access Working Group
> Subject: Re: [ACTION-33] Trying to sort the SPARQL/Update issues.
>
...
> 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.
>
> 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.
>
> Another option would be something like
> PUT
> http://store.example.com/graph/?graph=http%3A%2F%2Fsource.com%2Fdata.rdf
> ...
>
> [ This could also be reused to POST in data to be appended, as POST
> has no obvious destination in its description. ]
>
> 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 { ?s ?p ?o }
> WHERE {
> GRAPH <http://source.com/data.rdf> {
> ?s ?p ?o
> }
> }
>
> So, how many people want something like (2) above, and how many also
> want something like (2b)?
I want 2B. I don't like restricting the graph naming by the service endpoint.
Andy
>
> - Steve
>
> --
> Steve Harris
> Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
> +44(0)20 8973 2465 http://www.garlik.com/
> Registered in England and Wales 535 7233 VAT # 849 0517 11
> Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10
> 9AD
Received on Wednesday, 27 May 2009 11:11:26 UTC