Andy Seaborne announces a first draft of SPARUL, the SPARQL/Update Language:
This document describes SPARQL/Update (nicknamed “SPARUL”), an update language for RDF graphs. It uses a syntax derived form SPARQL. Update operations are performed on a collection of graphs in a Graph Store. Operations are provided to change existing RDF graphs as well as create and remove graphs with the Graph Store. A binding of SPARQL/Update using HTTP POST is described.
Max Völkel and I did a very rough proposal for a similar language back last year. We received some criticism over this: Tunneling application protocols over HTTP is not an optimal use of the web. Case in point: the WS-* stack. I tried to work out the issues by asking how RESTful SQL would look like, a potentially illuminating analogy. I found the results inconclusive—I understand the concerns raised by REST proponents, but haven’t seen a better alternative.
The main question, I think, is one of scope: Is SPARQL Update intended as an SQL-like language that applications use to communicate with their local or nearby data store? Or is it intended as public web infrastructure, similar to Web 2.0 APIs and HTTP PUT?
The SPARUL proposal doesn’t really take a position here, although this might be interpreted as a nod towards the former:
An update service that is separate from the query service has the advantages that different security mechanisms can be applied and that the query interface remains a legal, SPARQL service.
So, public query service and local update service?
The intent is teh modest one of local update. Applications these days aren’t single programs, but several cooperating components connected by a local network even at a single site.
http://seaborne.blogspot.com/2007/03/sparqlupdate.html
Just out of interest, is HTTP PUT actually widely used? For uploading data, I usually use FTP, or a web based system that usually uses POST, if not even GET. I know, it is applicable in theory, but in what circumstances is it actually applied in practice?
@Denny: On the traditional web, updates are done mostly using FTP or POST through forms. HTTP PUT in its pure form is used almost nowhere, except in WebDAV which is fairly widely used among web pros. PUT has also seen some uptake in the context of REST, as part of Web 2.0 APIs.
On the SemWeb, the context is quite different, we want to be able to do updates in a fairly automated fashion without knowing much about the internals of the updated system. FTP is not good here. POST only works when you have a clear and explicit and machine-interpretable specification of what to send. On the traditional web, these specification are the HTML forms. I don’t know what the SemWeb equivalent will be. Semantic Web Services? Something like Mark Baker’s RDF Forms?
Isn’t the whole idea of RDF that it is clear and explicit and machine-interpretable?
@Denny: RDF is just the data format, i.e. payload. We are talking protocols here. We need a clear and explicit specification of what kind of message a certain service can process. POST itself doesn’t constrain the message in any way. PUT, on the other hand, provides a clear specification: The state of the document is to be replaced with the payload. Simple and clear, but unfortunately not applicable to all situations.
I am creating rdf files for mailitems.
Instead of recreating the entire RDF file is it possible to insert the rdfs for the newmail. Does such a query exixts