Recently technology developments in the area of services on the Web are marked by the proliferation of Web applications and APIs. The development and evolution of applications based on Web APIs is, however, hampered by the lack of automation that can be achieved with current technologies. In this paper we present SWEET{ Semantic Web sErvices Editing Tool{ a lightweight Web application for creating semantic descriptions of Web APIs. SWEET directly supports the creation of mashups by enabling the semantic annotation of Web APIs, thus contributing to the automation of the discovery, composition and invocation service tasks. Furthermore, it enables the development of composite SWS based applications on top of Linked Data.
Since the advent of Web service technologies, research on semantic Web services (SWS) has been devoted to reduce the extensive manual e ort required for manipulating Web services. The main idea behind this research is that tasks such as the discovery, negotiation, composition and invocation of Web services can have a higher level of automation, when services are enhanced with semantic descriptions of their properties. Recently, technology developments in the area of services on the Web are marked by the proliferation of Web applications and APIs. The development and evolution of applications based on Web APIs is, however, hampered by the lack of automation that can be achieved with current technologies. Research on semantic Web services is therefore trying to adapt the principles and technologies that were devised for traditional Web services, to deal with this new kind of services.
Web APIs are characterized by their relative simplicity and their natural
suitability for the Web, which is indeed closely related to the growing
popularity and use of Web 2.0 technologies. Many Web 2.0 applications like Facebook,
Google, Flickr and Twitter o er easy-to-use Web APIs, which not only provide
simple access to di erent resources but also enable combining heterogeneous data
coming from diverse sources, in order to create mashups. However, despite their
success, Web APIs are currently facing the same limitations that were identi ed
for traditional Web service technologies and present even further di culties. In
particular, as opposed to WSDL services, there is no widely accepted structured
language for describing Web APIs, even though there are some initial approaches
in the area [
In order to support the creation of mashups and the more automated handling of Web APIs in general, we have developed SWEET1 { Semantic Web sErvices Editing Tool. SWEET is a lightweight Web application, which requires no installation and can be invoked directly in the Web browser. It is realized by using JavaScript and ExtGWT2 and supports the development of mashups based on linked open data and services, by enabling the creation of semantic descriptions of Web APIs. In particular, SWEET can be used to annotate Web APIs, which results in semantic descriptions that are amenable to automated reasoning and can therefore support a higher level of automation during the discovery, composition and invocation of Web APIs. As a consequence SWEET contributes to better supporting the creation of mashups and applications based on linked open data and Web APIs.
The remainder of this paper is structured as follows: Section 2, provides an overview of the existing formalisms for the semantic description of Web APIs, while Section 3 exempli es how semantically annotated Web APIs can contribute to the scalability and exibility of the creation of mashups. Section 4 introduces SWEET, including its components, functionalities and user support. An example for creating semantic descriptions of Web APIs is given in Section 5. Section 6 presents an overview of comparable tools, related formalisms and approaches. Finally, Section 7 presents future work that will be carried out and concludes the paper. 2
Recently, the world around services on the Web, thus far limited to \classical"
Web services based on SOAP and WSDL, has signi cantly evolved with the
proliferation of Web applications and APIs, often referred to as RESTful Web
services [
hRESTS contains only a few elements, is very lightweight and easy to use. Microformats, in general, facilitate the translation of the HTML tag structure into objects and properties, while hRESTS in particular, uses class and rel
2 ExtGWT is a Java library for building rich internet applications with Google Web
Toolkit (GWT). http://extjs.com/products/gxt/ XHTML attributes to mark key service properties (see Listing 1.1), leaving the visualization of the HTML description unchanged. hRESTS introduces tags for marking the service description as a whole, the used HTTP method, the operation with corresponding input and output, and the service or operation names in the form of labels. Therefore, hRESTS marks the key properties of the Web API and provides a machine-readable description based on the available HTML documentation. The result can be used as the basis for adding complementary information and annotations.
We use MicroWSMO [
In summary, we use MicroWSMO and hRESTS, to support the automation of Web API-related tasks, such as discovery, composition and invocation. The here presented approach is very lightweight because it relies on the use of microformats, which only enhance existing HTML descriptions with a few simple tags, without modifying the existing visualization. It only relies on the use of incremental extensions, which results in a low overhead of its uptake and practical use. In addition, the annotation process does not require extensive user training or ontology knowledge, and is very intuitive. In particular, SWEET supports users in creating semantic annotations of Web APIs by abstracting away from the technical details and assisting in the location of suitable domain ontologies from the Web. 3
In this section we describe a data-oriented composition, i.e. a mashup, that we implemented in order to exemplify the importance of the semantic annotation of Web APIs for the creation of compositions, based on linked open data and Web APIs.
The availability of linked open data, such as the one published by the open government data initiative3, provides the foundation for the development of diverse mashups, where distinct sources can be combined to provide added-value solutions. Moreover, these data compositions can be enhanced by integrating the existing Web APIs as additional data sources. As a result, Web applications can be created to display or synthesize linked open data and data retrieved through Web APIs.
Undoubtedly such applications can be very useful and there are already a number of existing implementations, the most common ones probably being the visualization of data by using the Google Maps API. However, currently, a developer needs to manually search for suitable Web APIs, implement the data composition and realize its invocation. The result is a mashup based on open data and Web APIs. However, applications created in this way have very restricted potential when it comes to reusability, maintenance and extensibility. In order to enable the reusability of Web APIs within mashups and to add a higher level of automation to the composition process, we propose the use of semantic descriptions of Web APIs. Figure 1 visualizes a Web application implemented by combining open government data about schools in Milton Keynes with APIs for retrieving location-based crime statistic and visualizing it together in Google Maps. However, instead of hard-coding the implementation, we use the latitude and longitude as search parameters for nding relevant Web APIs. In this way, based on the semantic descriptions, we are able to discover and provide a set of services, which take as input latitude and longitude and return location-based information such as crime statistic or local businesses.
In order to support the creation of semantic descriptions of Web APIs and contribute to the exible and easier creation of mashups, we use SWEET. 4
SWEET (http://sweet.kmi.open.ac.uk/) is a Web application developed
using JavaScript and ExtGWT, which is started in a Web browser by calling the
host URL. It implementation is mainly based on using scripting programming
languages and is part of a fully- edged framework supporting the lifecycle of
services, particularly targeted at enabling the creation of semantic descriptions
of Web APIs. SWEET takes as input an HTML Web page describing a Web API
and o ers functionalities, which enable users to annotate the service properties
and to associate semantic information to them. In comparison to previously
published versions of SWEET [
As it can be seen in Figure 2, the architecture of SWEET consists of three main components, including the visualization component, the data preprocessing component and the annotations recommender. The annotations recommender assists the user in annotating a service by suggesting suitable annotations for the service as a whole (domain ontology recommendation) and for its individual properties. This component is still under development and will be available soon. The data preprocessing component implements functionalities for data preparation for the visualization component, caching mechanisms and simple rule-based analysis.
The GUI of the visualization component is shown in Figure 3 and it has
three main panels. The the HTML description of the Web API is loaded in
the Navigator panel, which implements a reverse proxy [
In addition to these three main panels, SWEET o ers a number of
supplementary useful functionalities. It guides the user thorough the process of marking
service properties with hRESTS tags, by limiting the available tags depending
on the current state of the annotation. This implements measures for reducing
possible mistakes during the creation of annotations. In addition, based on the
hRESTS tagged HTML, which provides the structure of the Web API, the user
can link service properties to semantic content. This is done by selecting service
properties, searching for suitable domain ontologies by accessing Watson [
SWEET e ectively supports users in creating semantic descriptions of Web
APIs by marking service properties, by searching for suitable ontologies, and by
attaching semantic information. When the user completes the semantic
annotation of the HTML description, the Web API annotation can be locally saved as
annotated HTML or as extracted RDF. In addition, both the annotated HTML
and the RDF can be directly published to the iServe4 [
This section exempli es how SWEET supports each of the tasks along the process of creating semantic descriptions of Web APIs. SWEET takes as input the
HTML Website describing the Web API and returns a semantically annotated version of the HTML or an RDF MicroWSMO description. In order to do this the user needs to complete the following four mains steps: 1. Identifying service properties by inserting hRESTS tags in the HTML service description. 2. Searching for domain ontologies suitable for annotating the service properties. 3. Annotating service properties with semantic information. 4. Saving or exporting the annotated Web API.
The rst step can easily be completed by simply selecting the part of the HTML, which describes a particular service property, and double-clicking on the corresponding tag in the inset hTags pane (Figure 3). In the beginning, only the Service node of the hRESTS tree is enabled. After the user marks the body of the service, additional tags, such as the Operation and Method, are enabled. In this way, the user is guided through the process of structuring the Web API description and we limit the potential mistakes that a user could make, thus avoiding the generation of incorrect service description structures. The marking of HTML content with a particular hRESTS tag results in the insertion of a corresponding class HTML attribute. This formalism complexity is hidden from the user, and instead, he/she only sees the current status of the annotation re ected in the Semantic Description panel. In addition, each inserted tag is highlighted by a custom cascading style sheet (CSS), which visualizes the annotations the user has made. An example of an HTML with identi ed service properties is given in Listing 1.1.
Listing 1.1. Example hRESTS Service Description 1 <div class="service" id="s1"><h1>happenr API</h1> 2 <span class="label">Happenr </span>has two main methods to call "getEvents" and ... 3 <p>All operations should be directed at http://happenr.3scale .net/</p> 4 <h2>Example usage</h2> 5 <span class="address">http://happenr.3scale.ws/webservices/getEvents.php?user key=xxx</span> 6 <p>where the userkey is the key issues with the signup you made.</p> 7 <div class="operation" id="op1"><h2><span class="label">getEvents </span>Method</h2> 8 <span class="input"> 9 <h3>username</h3> 10 <p>Your username that you received from Happenr in order to query this webservice.</p> 11 <h3>password</h3> 12 <p>Your password that you received from Happenr in order to query this webservice.</p> 13 <h3>eventid</h3> 14 <p>The id of the event.</p></span></div></div>
After the user structures the HTML description and identi es all service
properties, the adding of semantic information can begin. SWEET supports users
in searching for suitable domain ontologies by providing an integrated search
with Watson [
The implementation of the Service Properties and Domain Ontologies panels supports the user in choosing a suitable ontology for annotating the individual service properties or the complete Web API. These supporting functionalities are visualized in Figure 5. The user can view the URI of each of the matching concepts, properties or instances and the corresponding ontology. Additional information is available in the Domain Ontologies panel, which shows all service properties that can be annotated with one particular ontology as well as a list of all concepts. The entries of both panels can be expanded or collapsed in order to ease the navigation.
Once the user has decided, which ontology to use for the service property annotation, he/she can do an annotation by selecting a part of the service HTML description and clicking on Semantic Annotation in the Service Properties context menu. This results in inserting a model attribute and a reference pointing to the URI of the linked semantic entity. MicroWSMO also contains elements for lifting and lowering, which point to links for lifting and lowering transformations. Even though, the current version of SWEET does not support the insertion of these elements, they can still be manually added by the user. The result is a semantically annotated HTML description, with inserted model and href tags marking the association of the particular HTML elements with the semantic entities. A summary of the already made annotations is given in the Annotations panel. These annotations can be removed by choosing \Delete" from the context menu. In this way, the user can remove incorrect annotations and substitute them with new ones without having to reload the tool and start the annotation process from the very beginning.
Listing 1.2. Example MicroWSMO Service Description <div class="service" id="s1"><h1>happenr API</h1> <a rel="model" href="http://example.com/events/getEvents"> <span class="label">Happenr </span>has two main methods to call "getEvents" and ...</a> <p>All operations should be directed at http://happenr.3scale .net/</p> <h2>Example usage</h2> <span class="address">http://happenr.3scale.ws/webservices/getEvents.php?user key=xxx</span> <p>where the userkey is the key issues with the signup you made.</p> <div class="operation" id="op1"><h2><span class="label">getEvents </span>Method</h2> <span class="input"> <h3><a rel="model" href="http://example.com/data/onto.owl#Username">username</a> (<a rel="lowering" href="http://example.com/data/event.xsparql">lowering</a>)</h3> <p>Your username that you received from Happenr in order to query this webservice.</p> <h3><a rel="model" href="http://example.com/data/onto.owl#Password">password<a> (<a rel="lowering" href="http://example.com/data/event.xsparql">lowering</a>)</h3> <p>Your password that you received from Happenr in order to query this webservice.</p> Listing 1.2 shows our example service description annotated with MicroWSMO by using SWEET. Line 2 uses the model relation to indicate that the service searches for events, while line 10 associates the input parameter username with the class Username. The lowering schema for the recipient is also provided in line 11. The annotated HTML of the Web API can be directly transformed into RDF (Listing 1.3), which serves as the basis for discovery and manipulation directly over the semantic properties.
Listing 1.3. Example RDF Service Description <rdf:RDF><wsl:Service> <rdfs:isDe nedBy rdf : resource="http://open.3scale.net/happenr/happenr#code"/> <sawsdl:modelReference rdf:resource="http://example.com/events/getEvents"/> <rdfs: label >Happenr</rdfs:label> <hr:hasAddress rdf:datatype="http://www.wsmo.org/ns/hrests#URITemplate"> http://happenr.3scale .ws/webservices/getEvents.php?user key=xxx</hr:hasAddress> <wsl:hasOperation><wsl:Operation><rdfs:label>getEvents </rdfs:label> <wsl:hasInputMessage><wsl:Message> <sawsdl:modelReference rdf:resource="http://example.com/data/onto.owl#Username"/> <sawsdl:modelReference rdf:resource="http://example.com/data/onto.owl#Password"/> <sawsdl:loweringSchemaMapping rdf:resource="http://example.com/data/event.xsparql" /> </wsl:Message></wsl:hasInputMessage> </wsl:Operation></wsl:hasOperation></wsl:Service></rdf:RDF>
SWEET also provides options for customizing the way service descriptions are viewed. First, if the Navigator panel displays HTML service descriptions, which already contain MicroWSMO elements, these elements will be recognized and automatically highlighted so that the user can manipulate them and integrate them in his/her own annotation of the service. Second, the way the service properties and semantic information is highlighted can be modi ed by simply substituting the current CSS le with a new one, which uses di erent text fonts and colors.
In summary, SWEET e ectively supports users in creating semantic descriptions of Web APIs by using the hRESTS and the MicroWSMO microformats. In particular, it provides functionalities for marking service properties by inserting tags, for searching for suitable domain ontologies, for linking service properties with semantic entities and for saving and exporting the resulting semantic description both as annotated HTML or directly as RDF. In this way, SWEET contributes to a higher level of automation of common service tasks, such as discovery, composition and invocation. 6
Current research in the area of Web APIs and, in particularly on semantic
RESTful services, is mostly focused around the de nition of formalisms for creating
semantic annotations. As already mentioned, MicroWSMO is one such
formalism, which relies on hRESTS for describing the main aspects of a service and
uses hooks for linking these to semantic information. SA-REST [
hRESTS is not the only alternative that can be used for the creation of
machine-readable descriptions of Web APIs. WADL (Web Application
Description Language) [
In the area of tools supporting the semantic annotation of services, ASSAM
[
Currently, Web APIs are becoming increasingly popular, however, their general adoption is hindered by the fact that they cannot be found, interpreted and invoked without the extensive user involvement and a multitude of manual tasks. Web APIs play a particularly important task in the context of mashups, where existing linked open data can be combined with related services in order to develop applications, which facilitate a synergy e ect over the combined information.
The challenges faced by Web APIs can be addressed through the creation of machine-readable descriptions, which server as the basis for automatically nding services, through crawlers and search engines, and processing them. Moreover, extended with semantic annotations, Web APIs can even be discovered and included in compositions automatically, following the principles of the SWS.
In this paper, we have presented SWEET, which facilitates an integrated lightweight approach for creating semantic descriptions of Web APIs. These semantic descriptions serve as the basis for creating more exible mashups composed of linked open data and Web APIs, as demonstrated by our example application. SWEET uses two microformats: the hRESTS microformat that enables the tagging of key service properties and therefore supports the creation of machine-readable service descriptions; and the MicroWSMO microformat that enables the linking of semantic information to service properties. As a result, SWEET e ectively supports users in creating semantic descriptions of Web APIs, by providing functionalities for both the creation of machine-readable descriptions and the addition of semantic annotations based on hRESTS and MicroWSMO.
Future work will focus on further developing SWEET's annotations recommender component, in order to reduce the number of manual tasks that the user has to complete. This will result in the faster and more correct creation of semantic descriptions of Web APIs. Future work will also include the development of supplementary functionalities of SWEET, which will provide additional user support. In addition, some work will be devoted to the automatic recognition of service properties such as operations and input parameters, so that the user only has to verify the pre-marked service properties. The goal is that future versions of SWEET will even better support users in creating semantic descriptions of Web APIs. 8
SWEET is based upon work partially supported by the EU funding under the project SOA4All (FP7 - 215219).