- 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