- From: Paul Gearon <gearon@ieee.org>
- Date: Tue, 15 Mar 2011 12:56:58 -0400
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
I just thought I'm comment on the following email.... On Mon, Mar 14, 2011 at 8:11 AM, william greenly <william_greenly@hotmail.com> wrote: > Are there any plans to extend federation extensions to cover SPARQL Update. > > For nearly every example in the SPARQL Update WD, I can see a way to > incorporate federation extensions e.g: > > PREFIX dc: <http://purl.org/dc/elements/1.1/> > INSERT DATA { > SERVICE <http://example1/sparql> { > GRAPH <http://example1/bookStore> { > <http://example/book3> dc:title "Fundamentals of Compiler Design" > } > GRAPH <http://example1/bookstore2> { > <http://example/book3> dc:title "Fundamentals of Compiler Design" > } > GRAPH <http://example1/bookstore3> { > <http://example/book3> dc:title "Fundamentals of Compiler Design" > } > } > SERVICE <http://example2/sparql> { > GRAPH <http://example2/shop> { > <http://example/book3> dc:title "Fundamentals of Compiler Design" > } > GRAPH <http://example2/shop2> { > <http://example/book3> dc:title "Fundamentals of Compiler Design" > } > } > } > > I am sure the benefits would be huge. > > Many Thanks, > > William Greenly > Volkswagen UK Technical Lead I've run into this recently myself, so I'm interested to know what others think. Personally, I decided that it's better to connect directly to the endpoint where the modifications are to be made. The arguments around this are based on whether you are modifying one or more endpoints.: - For a single updated endpoint, then it is better to send the request to that endpoint and have it request data from any other endpoints using the SERVICE keyword. In many cases this will be more efficient anyway. Offering SERVICE in the destination does not provide any new functionality. - For multiple updated endpoints, then the operation may as well be executed as separate operations anyway. SPARQL has no concept of transactions, meaning that there can't be any guarantee of integrity across endpoints no matter what we do. It could be argued that the WHERE clause could be resolved into a single image that is used for consistent updates across stores, which may make integrity more likely, but it still can't be guaranteed. In either case, this is ignoring security. Many stores will have some kind of security protecting the Update endpoint, typically using HTTP access and authorization. This can be negotiated outside of SPARQL, and so doesn't need to enter into the query language or protocol descriptions directly. However, accessing a remote Update endpoint in the proposed way would require credentials to be sent, and the SERVICE keyword currently doesn't address this issue (I would not be happy with using username/passwords in HTTPS URLs). Regards, Paul Gearon
Received on Tuesday, 15 March 2011 16:57:31 UTC