SPARQL Update to Complete RESTful SOA Scenario

Posted by Thomas Bandholtz on May 06, 2008

Community

SOA

Topics

Semantic Web ,

REST

Tags

Mashups ,

Collaborative Technologies ,

Update ,

Web 2.0 ,

W3C ,

RDF

The LinkingOpenData Community Project has accomplished a global RESTful SOA scenario giving access to over two billion interlinked statements (RDF triples) from some 50 distributed providers such as DBpedia, Geonames, MusicBrainz, WordNet, the DBLP bibliography, or the 2000 U.S. Census. All this data is published in the Resource Description Framework (RDF) format. Each data set is structured as a named graph which can be accessed by a "Cool URI", using a simple HTTP GET (see my previous posting). A detailled tutorial for contributors can be found in How to Publish Linked Data on the Web. As datasets are widely interlinked between different sources, all this makes a large (if not huge) machine readable Web. If the provider also implements a SPARQL endpoint, may be using RDBMS-based tools such as D2R Server, clients may use the powerful SPARQL Query Language for RDF against the data.

Even humans can get an impression using an RDF Browser such as the Tabulator Firefox add-on. The latest talk about LinkedData highlights more sophisticated application patterns like domain-specific LinkedData mashups, mobile geospatial entry-points, semantic search engines, data fusion, aggregation and drill down tools, which will certainly appear on the scene soon.

However, there one serious limitation so far: this stunning network provides read access only. Currently this is addressed by the upcoming SPARQL Update language. While SPARQL Query has been developed by the W3C RDF Data Access Working Group since 2004 and finally came to W3C Recommendation in January this year, several issues had to be postponed, among them aggregate functions, and the update language. Recently Andy Seaborne (well-known Jena developer) and Geetha Manjunath, both from HP, published version 5 of a language for updating RDF graphs, (also known as "SPARUL"), which may push this topic forward. This language draft provides the following facilities:

* Insert new triples to an RDF graph.
* Delete triples from an RDF graph.
* Perform a group of update operations as a single action.
* Create a new RDF Graph to a Graph Store.
* Delete an RDF graph from a Graph Store.

So this resembles to the missing PUT, POST, DELETE implementation of Linked Data. But what is a Graph Store? Defined as "a repository of RDF graphs managed by a single service" it serves as the endpoint to which any SPARQL statement will be posted. Remember that each graph is an RDF dataset which should be represented by a URI itself - so why not send a HTTP POST/PUT/DELETE to this "Cool URI" directly?

The draft from HP does not raise nor answer this question, but the SPARQL Update Wiki gives some hints in its Q&A section:

SPARQL is read-only and so can be mapped into URIs (and therefore GET) without breaking too many principles of Web architecture.
REST-style HTTP operations could play a bigger role in operations for adding, updating, and removing entire named graphs.
While PUT and POST are generally useful, neither REST nor the Web architecture precludes the use of other methods which might better facilitate "atomic updates to large graphs".
Please try to avoid making the same mistakes as Web services; application protocols were not made to be "bound onto", because doing so requires masking most of their value.

The concept of resources may not be the same in RDF and REST. This has been discussed from 2006 in the trouble with "binding" and REST without RDF is only half as bad as SOAP, until February this year in Bridging the semantic Web and Web 2.0 with REST without any final conclusion. Why is it important?

The so far certainly RESTful Web of Linking Open Data provides an outstanding real world pattern for RESTful SOA - as long as there is only read access. Imagine enterprises can easily publish their data internally in the same way, and so cross-enterprise organizations could do (assumed that security requirements are as well satisfied). When it comes to UPDATE in Linking Open Data, this most probably will be realized using SPARQL Update. While this is a language not an application protocol, it is based on assumptions on such a protocol, e.g. by addressing the Graph Store and not the Graph. So it might by worthy to "avoid making the same mistakes as Web services".

• Older >