Re: SPARQL 1.1 Federation Extensions

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