RE: Reflections on Update



> -----Original Message-----
> From: gearon@gmail.com [mailto:gearon@gmail.com] On Behalf Of Paul
> Gearon
> Sent: 13 May 2009 18:07
> To: Alexandre Passant
> Cc: Seaborne, Andy; SPARQL Working Group
> Subject: Re: Reflections on Update
> 
> 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.

LOAD would be a good idea - I think it just slipped because CLEAR is there.

> 
> 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.

Servers should be allowed to (and encouraged?) to reject "file:".  Technically, much like "FROM <file:...>" but with worse consequences.

> 
> 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)

The number of web hops the data takes is important.  With LOAD <url> the data flows from the URL to the server, and does not flow via the client.
 
A use case I have in mind is the ability to collect data from a number of places with an update script of 

LOAD <url1> 
LOAD <url2>
LOAD <url3>
...

> 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

Good point about the use case for a simple POST-data and POST-from-form which look compelling so we're being to tease out the requirements for update.
 Andy

Received on Friday, 15 May 2009 10:03:02 UTC