BackSWS-XG position paper and discussion draft
SA-REST: Semantically enhancing REST services
Karthik Gomadam*, Ajith Ranabahu,
Amit Sheth
Kno.e.sis Services Science Lab,
Wright State University, Dayton, OH-54324
* Contact Person and Editor and can be reached at karthik dot gomadam at
Last published April 4 2008
The objective of this document is to initiate discussion within and solicit participation from SWS community members possible work on semantically enhancing REST service descriptions. This document is a outcome of our continuing research on SA-REST and Smashups and is primarily based on SA-REST and (S)mashups : Adding Semantics to RESTful Services and SA-REST: Semantically Interoperable and Easier-to-Use Services and Mashups.
Table of Contents
- Introduction
- SA-REST: Foundations and Annotations
- Current Research using SA-REST and annotations
- Summary
Introduction
Services based on the REpresentational State Transfer (REST) paradigm, a lightweight implementation of a service-oriented architecture, have found even greater success than their heavyweight siblings, which are based on the Web Services Description Language (WSDL) and SOAP (Reconciling Web Services and REST Services). By using XML-based messaging, RESTful services can bring together discrete data from different services to create meaningful data sets; mashups such as these are extremely popular today.
Although mashups fully embrace the idea of customization on the Web, read-write is another story. The complexity of application development using javascript makes it hard for average developers to create new mashups and to customize the existing ones. To solve this problem, several companies are developing tools for mashup creation that require little or no programming knowledge. These tools, exemplified by Yahoo! pipes, IBM's QEDwiki and Google's Mashup Editor, facilitate the selection of some number of RESTful Web services or other Web resources and chain them together by piping one service's output into the next service's input while filtering content and making slight format changes.
One drawback of these tools is that they're limited in the number of services with which they can interact - typically, they deal with services internal to the company that created them (for example, Google Mashup Editor can use Google Maps) or to services that have standard types of outputs such as RSS or Atom. Anyone with experience in data interoperability and integration also knows that it's hard to integrate data through purely syntactic and structural means — semantic techniques are required. If a company developing a mashup tool wanted to add a new service that didn't have a standard output or that wasn't internal to their tool, it could modify its existing tooling in order to incorporate the new service's interface. However, this solution isn't scalable because of the rate at which new services are coming online. The need to change the tool itself also negates the idea of a customizable Web.
How, then, to address these limitations and find a less complex yet scalable approach? Reuse and data mediation have led to several proposals for Semantic Web services, leading to the W3C recommendation for the Semantic Annotation of WSDL and XML Schemas. But adding semantics to REST is more challenging than adding semantics to WSDL. Unlike WSDL, REST-based services are often embedded in Web pages written largely in XHTML. Although WSDL was specifically created to capture service descriptions and has a supporting schema for doing so, XHTML is a more general-purpose language that adds semantic annotations only to those page elements that wrap a service or a service description.
For an open, flexible and standards based approach to add semantics to RESTful services, we built the SA-REST description by borrowing the idea of grounding service descriptions to semantic metamodels via model reference annotations from SAWSDL. The key difference between SAWSDL and SA-REST is that while SAWSDL annotations were added to formal service descriptions in WSDL, SA-REST annotations will have to be added to the services that are usually described in web pages composed in HTML. Consequently, SA-REST uses RDFa and Gleaning Resource Descriptions from Dialects of Languages to add and capture annotations.
SA-REST: Foundations and Annotations
Following several efforts to add formal semantics to traditional Web services, the W3C recommendation for SAWSDL has became the baseline for developing a Semantic Web service based on WSDL. SA-REST borrows the idea of model reference, first presented in in our work on WSDL-S and then adapted in SAWSDL. The annotation of a concept in SAWSDL or SA-REST ties that concept to an ontology or a conceptual model. As with SAWSDL, SA-REST doesn't enforce the choice of language for representing an ontology or a conceptual model, but it does allow the use of OWL or RDF that are now accepted as preferred and standards based approaches to represent ontologies.
In SA-REST descriptions, we embed semantic annotations in RDFa into the HTML page that describes the service, thus making the page both human and machine readable and creating a single place to make an update if the service changes. SA-REST leaves it up to the user as to how and where to embed triples. The triples can be intermingled with the HTML or clustered together and not rendered by the Web browser. The triple's subject should be the URL at which the service is invoked; the predicate of the triple should be sarest:input, sarest:output, sarest:operation, sarest:lifting, sarest:lowering, or sarest:fault where sarest is the alias to the SA-REST namespace. The triple's object should be either a URI or a URL to a resource, depending on the predicate. A detailed example of an SA-REST document for a Web service to search for houses on craigslist.com is given below.
Using GRDDL
To build in more flexibility and lower the barriers to entry, SA-REST also allows the use of GRDDL for attaching annotations. To annotate an HTML page with GRDDL, the author must first embed the annotations in a microformat. The author adds a profile attribute to the <head> tag in the HTML document. This attribute is the GRDDL profile's URL, which tells the agents coming to the HTML page that it was annotated with GRDDL. The final step is to add a link tag inside the head element that contains the translation document's URL. Although you can use any format to add annotations to this page, the data extracted after translation must result in RDF triples identical to those that would be generated via RDFa embedding. In other words, a page annotated with GRDDL must still produce triples whose subject is the URL used to invoke the service, whose predicate is the type of SA-REST annotation applied, and whose object is the URI or URL of the resource to which the predicate refers.
GRDDL's advantage is that it's less intrusive than RDFa, and it lets the user embed annotations in whatever way is most convenient to them. RDFa's advantage is that annotations are self-contained in the HTML page, so the user only needs to create and maintain a single document (GRDDL forces the user to create two documents, the HTML page and the translation document). RDFa also has the advantage of being a standardized microformat, which makes it simpler for a developer to maintain and understand a page created by someone else.
Current Research Using SA-REST and Annotations
The concepts of SA-REST have been used in our current work in Mediatability.
Summary
The current approaches to mashups and mashing up of services, based on the REST paradigm of SOA falls short when it comes to customizability and scalability. We propose an approach to semantically enhance the descriptions of REST based services and posit that such an approach can address the shortcomings. It is our belief that microformats such as RDFa and GRDDL can be used to capture the semantics of the different elements in a REST service and the same has been validated with some initial prototyping. We encourage the members of the working group to identify possible issues and solutions that would make the initial ideas outlined above, viable.
| The content and opinions expressed on this Web page do not necessarily reflect the views of nor are they endorsed by the Wright State University |