Wright State University CORE Scholar The Ohio Center of Excellence in Knowledge- Kno.e.sis Publications Enabled Computing (Kno.e.sis) 2007 SA-REST: Semantically Interoperable and Easier-to-Use Services and Mashups Amit P. Sheth Wright State University - Main Campus, [email protected] Karthik Gomadam Wright State University - Main Campus Jonathan Lathem Follow this and additional works at: https://corescholar.libraries.wright.edu/knoesis Part of the Bioinformatics Commons, Communication Technology and New Media Commons, Databases and Information Systems Commons, OS and Networks Commons, and the Science and Technology Studies Commons Repository Citation Sheth, A. P., Gomadam, K., & Lathem, J. (2007). SA-REST: Semantically Interoperable and Easier-to-Use Services and Mashups. IEEE Internet Computing, 11 (6), 91-94. https://corescholar.libraries.wright.edu/knoesis/731 This Article is brought to you for free and open access by the The Ohio Center of Excellence in Knowledge-Enabled Computing (Kno.e.sis) at CORE Scholar. It has been accepted for inclusion in Kno.e.sis Publications by an authorized administrator of CORE Scholar. For more information, please contact [email protected]. Semantics & Services SA-REST: Semantically Interoperable and Easier- to-Use Services and Mashups Amit P.Sheth and Karthik Gomadam • Wright State University Jon Lathem • University of Georgia ervices based on the representational state required. If a company developing a mashup tool transfer (REST) paradigm, a lightweight wanted to add a new service that didn’t have a S implementation of a service-oriented archi- standard output or that wasn’t internal to their tecture, have found even greater success than their tool, it could modify its existing tooling in order heavyweight siblings, which are based on the Web to incorporate the new service’s interface. Howev- Services Description Language (WSDL) and SOAP er, this solution isn’t scalable because of the rate (see www.w3.org/2005/Talks/1115-hh-k-ecows/ for at which new services are coming online. The need a comparison). By using XML-based messaging, to change the tool itself also negates the idea of a RESTful services can bring together discrete data customizable Web. from different services to create meaningful data How, then, to address these limitations and find sets; mashups such as these are extremely popu- a less complex yet scalable approach? Reuse and lar today.1 data mediation have led to several proposals for Semantic Web services, leading to the W3C recom- Mashups mendation for the Semantic Annotation of WSDL Although mashups fully embrace the idea of cus- and XML Schemas (SAWSDL; www.w3.org/TR/ tomization on the Web, read–write is another story. sawsdl/). But adding semantics to REST is more Without technical training, it’s difficult for aver- challenging than adding semantics to WSDL. age users to create a mashup — they need to Unlike WSDL, REST-based services are often understand not only how to write the code but also embedded in Web pages written largely in XHTML. the APIs and descriptions of data elements for all Although WSDL was specifically created to cap- the services to be included. To solve this problem, ture service descriptions and has a supporting several companies are developing tools for mashup schema for doing so, XHTML is a more general- creation that require little or no programming purpose language that adds semantic annotations knowledge. These tools, exemplified by Yahoo’s only to those page elements that wrap a service or pipes, IBM’s QEDwiki, and Google’s Mashup Edi- a service description. tor, facilitate the selection of some number of For an open, flexible, and standards-based RESTful Web services or other Web resources and approach to adding semantics to RESTful servic- chain them together by piping one service’s out- es, we built the SA-REST description by borrow- put into the next service’s input while filtering ing the idea of grounding service descriptions to content and making slight format changes. semantic metamodels via model reference anno- One drawback of these tools is that they’re lim- tations from SAWSDL. The key difference between ited in the number of services with which they can SAWSDL and SA-REST is that although SAWSDL interact — typically, they deal with services inter- annotations were added to formal service descrip- nal to the company that created them or to serv- tions in WSDL, SA-REST annotations will have to ices that have standard types of outputs such as be added to the services that are usually described RSS or Atom. Anyone with experience in data in Web pages composed in HTML. Consequently, interoperability and integration also knows that SA-REST uses RDFa (www.w3.org/TR/xhtml-rdf it’s hard to integrate data through purely syntac- a-primer/) and Gleaning Resource Descriptions tic and structural means — semantic techniques are from Dialects of Languages (GRDDL; www.w3. 84 Published by the IEEE Computer Society 1089-7801/07/$25.00 © 2007 IEEE IEEE INTERNET COMPUTING SA-REST Mashups <html xmlns:sarest=”http://lsdis.cs.uga.edu/SAREST#”> … org/TR/grddl/) to add and capture objective of REST is simplicity annotations. (WSDL facilitates significant <p about=” http://craigslist.org/search/”> tooling support). The logical input of this service is an SA-REST: Foundations Most RESTful Web services and Annotations have HTML pages that describe <span property=”sarest:input”> Following several efforts to add formal to users what the service does http://lsdis.cs.uga.edu/ont.owl#Location_Query semantics to traditional Web services, and how to invoke it — in one </span> the W3C recommendation for SAWS- sense, this HTML is somewhat object.The logical output of this service is a list of DL has became the baseline for devel- equivalent to WSDL for REST- <span property=”sarest:output”> oping a Semantic Web service based ful Web services, making it an http://lsdis.cs.uga.edu/ont.owl#Location on WSDL (http://knoesis.wright.edu/ ideal place to add semantic </span> 2 library/resource.html?id=00068). SA- annotations. The problem, objects.This service should be invoked using an REST borrows many ideas first pre- however, with treating HTML <span property=”sarest:action”> sented in our work on WSDL-S (www. like WSDL is that the former is HTTP GET w3.org/Submission/WSDL-S/) and then meant to be human readable </span> adapted in SAWSDL, specifically the whereas the latter was <meta property=”sarest:lifting” content= model reference attribute, which links designed to be machine read- and maps a service element to the able. Microformats might offer “http://craigslist.org/api/lifting.xsl”/> ontological concepts that describe it. a solution: they offer a way to <meta property=”sarest:lowering” content= The basic annotations that SAWS- add semantic metadata to “http://craigslist.org/api/lowering.xsl”/> DL adds are inputs, outputs, operation, human-readable text in such a <meta property=”sarest:operation” content= interfaces, and faults; in SAWSDL, way that machines can glean “http://lsdis.cs.uga.edu/ semantic annotations are simply bits semantics. Recently the W3C ont.owl#Location_Search”/> of XML embedded as properties in has worked on standardizing </p> WSDL (basically, URIs of ontology two different microformat objects). In other words, the annota- technologies, GRDDL and Figure 1. SA-REST document. For a tion of a concept in SAWSDL or SA- RDFa. GRDDL, which recently craigslist.com service, this document describes REST ties that concept to an ontology became a W3C recommenda- semantic annotations both inside the <meta> or a conceptual model. As with SAWS- tion, offers a way for the tag as well as inside formatting tags such as DL, SA-REST doesn’t enforce the human-readable text’s author <span>.Annotations in the <meta> tags choice of language for representing an to choose any microformat aren’t visible to the user, but he or she can see ontology or a conceptual model, but it and specify a translation into annotations in the <span>. does allow the use of OWL or RDF, machine-readable text; RDFa which are now accepted as preferred offers a way to embed RDF and standards-based approaches to triples into an XML, HTML, or XHTML subject should be the URL at which the represent ontologies. Because SAWS- document. For SA-REST, we recom- service is invoked; the predicate of the DL and SA-REST are more concerned mend using RDFa because it’s a subset triple should be sarest:input, with data structure than with the rela- of RDF, extends XHTML to annotate sarest:output, sarest:operation, tionships between objects and reason- with markups or annotations, has sarest:lifting, sarest:lowering, ing, developers will likely use RDF built-in support URIs and namespaces, or sarest:fault, where sarest is the more frequently in the near future and is recognized by the W3C. alias to the SA-REST namespace. The because of its simplicity. In SA-REST descriptions, we embed triple’s object should be either a URI or a semantic annotations in RDFa into the URL to a resource, depending on the Annotation Techniques HTML page that describes the service, predicate. Figure 1 gives a detailed and Languages thus making the page both human and example of an SA-REST document for a In SAWSDL, semantic annotations that machine readable and creating a single Web service to search for houses on describe a service appear in that ser- place to make an update if the service craigslist.com. vice’s WSDL, which is logical because changes. SA-REST leaves it up to the of the one-to-one correlation between user as to how and where to embed Using GRDDL WSDL and a traditional SOAP-based triples — they can be intermingled with To build in more flexibility and lower Web service.