SA-REST

From Knoesis wiki
Revision as of 06:41, 5 March 2009 by Kgomadam (Talk | contribs) (Class and Title)

Jump to: navigation, search

SA-REST is a simple and open microformat for enhancing Web resources with additional semantic information. 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.

People

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

Introduction

Replace this with a need for additional semantic annotation for Web resources. Highlight Web APIs as an example, not the only effect.

Current mashup tools and technologies

This section changes as well to talk about limitation in APIs and how SA-REST can address this. Add a blog example. 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.

Limitations

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.

Another drawback of the current approach to mashups is the complexity of their development itself. Frameworks like Pipes that do not require any programming have limited capabilities. Google Mashup Editor has a steeper learning curve and can do much more than Yahoo! Pipes. The need to be proficient in languages such as javascript is mandatory to create more complex mashups. We identify two types of this complexity

  • 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

Change this. We can remove this completely, if we can capture a very good description at the beginning.

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.

Background

Rather than talking only about SWS (not relevant), we should instead talk about other microformats and the synergy therein with SA-REST.

Researchers in the area of Semantic Web Services have proposed various specifications, the prominent of which are

  • OWL-S
  • WSDL-S
  • WSMO

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.

Usage Scenarios

Need to write this along the style of microformats.org wiki.

Faceted Search

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

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.

Automatic Annotation

Assisted automatic annotation is a significant application of the domain-rel markup. Illustrate with an example from a blog.


SA-REST Elements

The abbr design pattern

What is the abbr design pattern and why did we adopt this?

Class markup

<span class="sem-class http://apihut.com/schema/apihut-taxonomy#Map">Maps</span>

Class and Title

<span class="sem-class" title="http://apihut.com/schema/apihut-taxonomy#Map">Maps</span>



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

block markup : Markups on that pertain to a block like div, body etc.

 <body domain-rel="http://apihut.com/taxonomies/domainClassification.rdf#maps"> 

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

  • 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.
 <body domain-rel="http://apihut.com/taxonomies/domainClassification.rdf#maps"> 

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 class="protocol" title="http://apihut.com/taxonomies/protocols.rdf#soap"> SOAP </span> 

Reformulation using value property:

 <span class="protocol" title="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 class="sem-class" title="http://tap.stanford.edu/#computer"> Computer </span> 
.

Processing SA-REST

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.

Related Documents