This article is written in a style that is not suitable for a wiki. This will change as we get more inputs and continue our edits. For now, this is just a easy way to share what our thoughts and start a discussion. The editorial changes will happen as we start and continue the discussion. The wikimedia css bombs on me, hence this personal message - karthik.
SA-REST is a simple and open format for enhancing Web APIs HTML or XHTML. In addition to HTML and XHTML, the SA-REST approach can also be used to enrich Atom, RSS, and arbitrary XML. SA-REST is one of several open microformat standards.
- 1 People
- 2 Introduction
- 3 Usage Scenarios
- 4 SA-REST Elements
- 5 Processing SA-REST
- 6 Related Documents
Collaborators in the SA-REST initiative are listed by their affiliations.
- kno.e.sis center, Wright State University, Dayton, OH
- Amit P. Sheth.
- Karthik Gomadam.
- Ajith Ranabahu
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.
Current mashup tools and technologies
One of the main drawbacks of the current state of the art is the lack of support for interoperability, especially that of data. Since most these 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 (Yahoo! Pipes), the problem of interop does not seem to arise.
- Visual: Complexity arising out of the need to create intuitive visual elements and handle various events relating to them
- Data: Complexity arising due to heterogeneous in data schemas and formats.
SA-REST in a nutshell
SA-REST is a microformat to add additional meta-data to REST API descriptions in HTML and XHTML. Developers can directly embed meta-data from various models such an ontology, taxonomy or a tag cloud into their API descriptions. The embedded meta-data can be used to improve search (for example: perform faceted search for APIs), data mediation (in conjunction with XML annotation) as well as help in easier integration of services to create mashups.
Researchers in the area of Semantic Web Services have proposed various specifications, the prominent of which are
In 2005, the W3C initiated a charter to create a standard for adding semantics to WSDL descriptions. The WSDL-S specification (submitted by Services Research Lab at kno.e.sis from LSDIS Lab in GA along with IBM) was taken as the primary input for the charter. This led to the standardization of SAWSDL (Semantic Annotation of WSDL and XML Schema). SAWSDL has had a significant impact in the evolution of SA-REST. However, the adoption of a microformat based approach is a key difference between the SAWSDL and SA-REST frameworks. However, it must be noted here that the principles of Schema annotation, lifting and lowering can be directly used from SAWSDL for XML data objects in the RESTful environment.
We present three usage scenarios where additional meta-data can be very useful.
The number of available APIs are growing fast. In April 2008, we found that there were about 700 APIs added to ProgrammableWeb. In September, that number is over 900. Currently, general purpose search engines like Google are largely used to find these APIs. However, these treat API documents like any other in indexing and ranking APIs. As a result, search for APIs (even when specific queries like "Maps API") results in API resources being scattered all over the result set. Web API directories like programmableWeb do present a more domain-specific solution. However, they largely rely on user tags for classification and searching.
Addition of meta-data to capture the various facets of APIs (their functionality, the message types they support, clientside bindings, protocol) can allow for better searching. The results of one such framework APIHut is presented in Faceted Search for APIs. We also present our initial evaluation of precision and recall metrics. SA-REST can improve faceted search in a significant manner. Using known techniques of GRDDL and XSLT, one can extract RDF representations of APIs. This can then be indexed and searched upon.
Data Mediation and Mediatability
The importance of enabling easier approaches to data mediation has been well understood. In the context of mashups this is even more important, largely due to the fact that often developers are faced with the burden of handling data at the client side. SA-REST will address this issue in two ways
- Adopting XML annotation from SAWSDL: This will allow us to add the lifting and lowering transformations to data elements as a part of the API description. Information about SAWSDL lifting and lowering can be found in theSAWSDL spec on schema annotations. There is a small catch that we have to address here. In the WSDL world, data exchange was XML de-facto. However, in the RESTful environment, developers can use many formats such as JSON, GData, RSS. It will be interesting to investigate this as a part of the SA-REST effort.
- Mediatability: Mediatability is a measure of the estimated human effort for performing data mediation manually. Having additional annotations can significantly help us in computing the mediatability. Even when automatic mediation is not possible, knowing how hard or easy the mediation between two services can definitely help developers in choosing services for their mashups.
Smart mashups are those that allow the end user more flexibility to change certain services in a mashup. For example, in the popular Housing Maps mashup, if the quality of Yahoo! maps in a certain area is better than that of Google, the user must have the flexibility to change it. To realize this, we are pursuing on a meta based approach for mashup creation. In this approach, the developer creates the mashup application at a meta level and services are added to them at the run time. In this context, there needs to be a way for the developer to specify the requirements for a service and the system to check if the user preference meets the requirement. Having annotations can help accomplish this task with lesser difficulty.
Help in disambiguation in during text analysis
We have currently come up with a few elements for SA-REST. This is by no means final and is very much open to discussion and change. Markups can be one of:
- block markup : Markups on that pertain to a block like div, body etc.
In this example, the domain-rel markup is added to the body. This markup indicates that API descriptions inside the body belong to the maps domain as described in the domain model.
- element markup: markup on a single element like a, span (when it wraps a word or a phrase)
Currently, we propose to have the following elements: Note that the examples depict the SA-REST compoenents in the commonly used microformat annotation style.
- sem-rel: Sem-rel element will capture the semantics of a link. This evolves from the popular rel tag. An application of sem-rel would be to describe
a data model that is captured in a XSD. The primary purpose of the sem-rel tag is to allow developers to add "top level annotation" to schemas that are third party.
<a href="http://foo.xsd" sem-rel="http://taxonomy.org/computerscience#firstname"> This is the input schema</a>
- domain-rel: captures the domain of the current api. It can applied either as a block or an elemental markup.
The above example can also be reformulated with an additional value property, rather than just using domain-rel. This would be,
<body class="domain-rel" value="http://apihut.com/taxonomies/domainClassification.rdf#maps">
- p-lang-binding: captures a particular client side binding. For example, the section of google maps API that talks about the Zend framework for Google Data will be tagged using p-lang-binding and will carry the value of PHP.
<span p-lang-binding="http://apihut.com/taxonomies/languages.rdf#php"> PHP bindings for this API ... </span>
Here again, we can reformulate this using a value property.
<span class="p-lang-binding" value="http://apihut.com/taxonomies/languages.rdf#php"> PHP bindings for this API ... </span>
- message-format: describes the messaging formats supported. The value will be a message format. The messaging format refers to the way the message is represented, typically XML, Java Script Object Notation(JSON) or specific formats such as GData.
<span message-format="http://apihut.com/taxonomies/formats.rdf#xml"> The XML messages that are passed between the client and the server are ... </span>
Reformulation using value property:
<span class="message-format" value="http://apihut.com/taxonomies/formats.rdf#xml"> The XML messages that are passed between the client and the server are ... </span>
- protocol: describes the messaging protocols supported. Typical values include SOAP and REST.
<span protocol="http://apihut.com/taxonomies/protocols.rdf#soap"> ... </span>
Reformulation using value property:
<span class="protocol" value="http://apihut.com/taxonomies/protocols.rdf#soap"> ... </span>
- sem-class: is an alternative to modelreference in SAWSDL. It can be used to refer to a concept in a semantic model.
<span sem-class="http://tap.stanford.edu/#computer"> Computer </span>.
Reformulation using value property:
<span class="sem-class" value="http://tap.stanford.edu/#computer"> Computer </span>.
The most straight forward way to process the documents is to use XSLT along with GRDDL. XSLT is a well supported and a flexible way to transform XML documents from one form to another, typically the target form being XML or any other text format. GRDDL specification describes how the XSLT transformation can be used to convert annotated XHTML/HTML documents to RDF. The following snippet shows a specification of the transformation stylesheet according to GRDDL.
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:grddl='http://www.w3.org/2003/g/data-view#' grddl:transformation="glean_title.xsl http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl" >
The subsequent processing can be done using the RDF representation.