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

Re: Reflections on Update

From: Paul Gearon <gearon@ieee.org>
Date: Wed, 13 May 2009 12:06:40 -0500
Message-ID: <a25ac1f0905131006x359687b0n5e37e1bf3cbf9bd8@mail.gmail.com>
To: Alexandre Passant <alexandre.passant@deri.org>
Cc: "Seaborne, Andy" <andy.seaborne@hp.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
On Wed, May 13, 2009 at 10:26 AM, Alexandre Passant
<alexandre.passant@deri.org> wrote:
<snip/>
> IMHO, LOAD should be also part of the core (unless you considered it can be,
> via HTTP and not within the language ?)
> This is clearly needed for stores that act as repositories of remote RDF
> graphs (e.g. personal data management, enterprise middleware, etc.)
> Hence, ability to add / remove RDF graphs in the store is imho something
> that should be included in SPARQL/Update - core.

While I do agree that we need a standard for loading, there are issues
to be considered before putting it in the language.

How would the location of the data file be specified? I presume by
URL. In that case there are 2 primary URL protocols that will be used:
file and http.

Several SPARQL clients are run from a command line, in a kind of
client-server arrangement. Will file URLs refer to a path on the
server, or on the client? Specifying it on the server may be useless
from the perspective of most clients. Specifying it as being on the
client means that there needs to be some protocol interaction to get
the data to the server. If it needs protocol interaction anyway, then
why put it in the language?

Similarly, LOAD commands sent via a SPARQL-Update query over HTTP will
have no control over files hosted on the server (making server paths
useless), and local paths will mean nothing either. In this case,
"local" files would mean packaging the data up as a MIME attachment,
and so we touching on the protocol again.

So that's file: URLs. What about http: ?

If we are using the http protocol in the URL  to be loaded then
everything is being transferred by http protocol anyway, so why
confuse the issue by including a "command" in the transfer? It also
makes it awkward for the client that wants to send a file to the
server, but doesn't have an HTTP server on hand to respond to an HTTP
request for the file to be loaded. (This particular scenario also
requires two connections, when one would suffice)

I'd like to see a standard for POSTing a file to a graph on a server,
as this can be done easily with code or even a web form. Personally, I
also like having a command that does a load (we have one in Mulgara)
but the issues that I described make it seem difficult to standardize
in a way that will be suitable for any type of configuration.

Please feel free to correct me on any of the above points. :-)

Regards,
Paul Gearon
Received on Wednesday, 13 May 2009 17:07:16 GMT

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