- From: Paul Gearon <gearon@ieee.org>
- Date: Wed, 13 May 2009 12:06:40 -0500
- 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 UTC