Web of Data formats such as linked data, RDFa and microformats are read-only technologies. The issue of updating Web data directly from an RDF-based environment has so far gained limited attention. We present a preliminary report on the idea of \pushing back" modi cations of RDF data to the original source, focusing on the speci c case where data resides behind site-speci c Web APIs.
Let us take a look at a concrete use case. Sean is browsing the Web of Data using Tabulator. While sur ng the Web of Data, he nds a bookmark from his delicious.com account. When Sean rst bookmarked the URI, he assigned a few general tags. As he has gained more experience in the eld since, he now wants to update the bookmark at hand (in terms of tags, description, etc.|cf. also Fig. 1). Sean logs into the delicious.com Web application, locates the bookmark, performs the desired changes and eventually the RDF representation will be updated. When reviewing the actions necessary to complete Sean's \update" task, one may wonder if there are not more e cient means to do so. This is even more evident if Sean wants to keep his tags synchronised between several Web 2.0 sites, or if he wants to do mass updates to his bookmarks.
Thus, the key question is: How can data residing behind site-speci c APIs e ciently be manipulated from an RDF-based environment? In this work, we focus on the issue of mapping from RDF-based update operations to invocations of site-speci c API operations. The key challenge is the mismatch between the RDF model and the local semantics of site-speci c APIs.
Based on the concept of write-wrappers introduced in Section 2 we elaborate on design issues in Section 3. Then, in Section 4 we report on an experimental implementation of a write-wrapper. We review related work in Section 5 and eventually discuss our ndings in Section 6. 2
As we have reported in [
There are di erent alternatives for conveying the input operation and data. Options include: { RESTful HTTP interfaces, which use the four uniform HTTP methods GET,
POST, PUT, DELETE. { XML-RPC interfaces. { SPARQL Update4.
The output-interface of the write wrapper, on the other side, is determined by the site-speci c API. The write-wrapper needs to handle a variety of cases, depending on the style of the API (RESTful, XML-RPC, etc.), the o ered authentication mechanisms, error handling and so forth. However, these cases can be seen as implementations of the same basic steps. Therefore, it should be possible to employ a generic mechanism to perform the mapping and API access.
RDF clients can already update triple stores through SPARQL Update [
3. An output interface that is able to call Web services and pipe results back to the client.
As an initial step towards a generic pushback solution, in this paper we discuss design considerations for the components of a pushback and further discuss an experimental implementation for a speci c case. 3
The rst component of a pushback is the SPARQL Update input interface. SPARQL Update is at time of writing under standardisation, hence a moving target. Beside this, the SPARQL Update is straight-forward to implement; an array of existing libraries and platforms, for example, ARC25 (for PHP) or ARQ/Jena6 (for Java) exist.
Type of Operation. Essentially, we have identi ed two options to encode the
operation in a request from the RDF-based client, that is, the update request
semantics. First, one can use the SPARQL Update operations such as INSERT,
DELETE, etc. to convey the semantics. Second, one can use the RDForms
vocabulary7 over SPARQL Update. The second approach is described in detail
in [
The second module of a pushback, the mapping mechanism for both the data and operations could take many forms. We have contemplated the following options: 1. Rules expressed in an appropriate dialect of the Rule Interchange Format (RIF)8, 2. Embedded scripting language fragments that directly invoke the target API, 3. An extension of the Web Application Description Language (WADL)9, 4. The creation of a new declarative mapping language.
This area is subject to further research, as we are only starting to understand the requirements and possible limitations of the candidate languages. So far we have identi ed the following functions that a mapping mechanism must support in order to be used in a pushback: 1. Map input operations to target function call(s) of the site-speci c API; 2. For each of the target function calls, map input data elements to function call parameters; 3. Validate the parameter values against the contract of the API (required, optional, etc.); 4. Declare how users are authenticated to the site-speci c API; 5. Identify whether an API function call has succeeded or failed, and represent error messages or conditions.
We will give an example of a simple mapping in the following. Assuming that the input operation is based on RDForms over SPARQL Update and that the site-speci c API is an XML-RPC-style one, the 1:1 mapping could look like the following: CRUDOperationCreate{ method: POST call: https://api.del.icio.us/v1/posts/add? url.key : &url description.key : &description extended.key : &extended tags.key : &tags dt.key : &dt replace.key : &replace shared.key : &shared } Parameter Validation Site-speci c API method calls usually encode a number of parameters. Table 1 illustrates, by example, some parameters characteristics for the add function call10 of the delicious.com API. Explicitly, the
&description parameter, referring to the bookmark's title, is required and unstructured, whereas the &dt parameter (date stamp of the bookmark) is optional, but structured because it requires a full ISO860111 date format. These parameters have to be checked against their characteristics by the pushback. Note that some parameters are not updatable. The RDForm will not display a eld for such parameter.
We note further that every site-speci c API provides potentially di erent methods of authenticating users and returning error messages. We will discuss this in greater detail below.
Authenticating users In the context of Web services, authentication of a client is performed by a server to determine the identity of the requesting agent. In order to perform authentication, one needs to know about the identity of an agent. Site-speci c APIs support di erent authentication schemes, such as HTTP Basic, Digest, or API keys.
Error Handling Site-speci c APIs signal errors in very di erent ways. For example, the delicious.com API only returns <result code='done'> in case the call was successful and <result code='something went wrong'> otherwise. The site-speci c mapping must be su ciently expressive to tell these situations apart. 3.3
Eventually, the third component, the Web service output interface, poses some challenges on its own, as it very much depends on the type of Web service. We have identi ed the following forms, a site-speci c API function call may be performed: 1. For RESTful APIs, one can use generic libraries and tools such as curl ; 2. Based on a mapping that is rooted in an interpreted language such as PHP, one can directly execute the scripts, with the data as well as the operations supplied as parameter; 3. Utilising WADL|WADL provides a machine processable description of RESTful Web applications and services. Using WADL, the implementation is not tied to a speci c programming language. There are tools available12 that generate code automatically out of a WADL description. 11 http://www.cl.cam.ac.uk/~mgk25/iso-time.html 12 http://tomayac.de/rest-describe/latest/RestDescribe.html
In this section, we provide a qualitative evaluation of an experimental implementation of a pushback against a simple API access: Simple API access The rst implementation is our evaluation base-line. In this implementation the call to a site-speci c API is done directly through a basic programming script. The input data, arguments, operation and user credentials are hard-coded in the application.
API access from the Web of Data The second implementation accesses a site-speci c API through a write wrapper. For the sake of completeness, the input is an RDForm. The data of the RDForm is gleaned into a SPARQL Update operation. The output is the call to a Web service. The call to a Web service takes the language speci c script form. Moreover, this implementation includes form validation, secure on line log in and operation expressed using only the RDForms vocabulary. This approach uses only the SPARQL INSERT query.
Our evaluation purpose is to compare the complexity vs. the performance of the two approaches. While the second approach is obviously more complex than the rst one, it is interesting to nd out the di erence between the processing time for both approaches. First, we will compare the two implementations by their feature characteristics. Second, we will measure the processing time for the both implementations for several consecutive accesses to a site-speci c API.
The second approach includes error handling because it validates the user given elds' values. Although the authentication transparency su ers in the second approach, the security risk is minimal compared to the rst approach. Lastly, none of the two approaches o ers data integrity, that is, transaction support for concurrent editing operations.
The chart in Figure 4 shows the performance of the two implementation approaches. For the evaluation we chose the delicious.com API. Due to the restriction of \at least one second between queries" required by delicious.com, we set up a two seconds throttle between requests. The terms \create" and \delete" refer to the type of the request: \create a bookmark", respectively \delete a bookmark". We observe that the time grows linearly with the number of requests performed for both approaches and both types of requests. Moreover, the create request for the second implementation approach takes twice as much to process than the create request for the rst approach. The delete request takes about the same time for both implementations. While the create request encodes seven elds in the SPARQL request and thus more information to process, the delete request encodes only one eld for the URL parameter, which leads to the same processing time for both approaches when the number of requests is low.
The experiment shows that a write-wrapper does not add a lot of overhead
which provides evidence for the feasibility of the overall approach.
Basic Update Mechanisms. Three basic update mechanisms are available in
the Web of Data context, (i) native HTTP methods, (ii) WebDAV, and (iii)
SPARQL Update. The HTTP protocol [
RDF Mappings. Relational-to-RDF (RDB2RDF) mapping approaches [
Alternative Update Approaches. The Tabulator data browser
implements an update protocol based on per-triple update [
Semantic web services. Major work towards connecting web services to
languages such as RDF and OWL has been undertaken in the Semantic Web
Services (SWS) eld. In SWS terminology, the area addressed in our work is
Service Grounding : how to invoke a service given some input that is expressed
in terms of a domain ontology, and how to interpret the results in terms of the
domain ontology. This is typically achieved by referring to a WSDL le plus
lowering and lifting transformations, which map semantic information to and
from the message syntax expected by the service. This approach is standardized
in the SAWSDL [
A SAWSDL-annotated WSDL le contains all necessary information for conguring a write wrapper around the service. But the preferred method of documenting RESTful APIs is prose text, and WSDL les are rarely provided by service operators. Setting up a write wrapper thus requires manual authoring of a WSDL le, an extremely tedious activity even for simple services, especially when compared to creating a WADL le for the same service. Thus, an extension of WADL with annotations similar to those in SAWSDL seems like a more attractive alternative. We also want to further explore alternatives to XSLT for expressing the mappings, because processing RDF/XML input with XSLT is awkward, and input and output of RESTful services are often not expressed in XML.
SA-REST [
We have argued in this paper that there is a growing need in accessing sitespeci c APIs from an RDF based environment. We have introduced the concept of a pushback, a SPARQL Update-based write-wrapper that is able to translate RDF data into site-speci c API calls. Further, we have elaborated on the design of the three main components of a pushback, the SPARQL update interface, the generic mapping mechanism, and the output interface. For each one of them we have provided an initial design solution and implementation. Moreover, we have highlighted the limitations of the proposed design. Finally, we have compared direct access to a site-speci c API and a prototype implementation of our approach. In this paper we are not claiming to o er a comprehensive answer to our initial question how can site-speci c APIs e ciently be accessed from an RDFbased environment?, but discuss possibilities and limitations, building a basis for our further research. We have, for example, not yet addressed issues around concurrent data updates and plan to elaborate as well on transactions to ensure data integrity. Finally, we plan to have a deeper look into the handling of results and how to pipe back errors to the client.
Our work has partly been supported by the European Commission under Grant No. 217031, FP7/ICT-2007.1.2, project \Domain Driven Design and Mashup Oriented Development based on Open Source Java Metaframework for Pragmatic, Reliable and Secure Web Development" (Romulus).