Recent developments on the Web are marked by the growing support for the Linked Data initiative, which encourages government and public organisations, as well as private institutions, to expose their data on the Web. This results in a plentitude of multi-lingual document collections where the original resources are published in the language, in which they are available. The challenges of multilingualism present on the Semantic Web are also re ected in the context of services on the Web, characterised by the rapid increase in popularity and use of Web APIs, as indicated by the growing number of available APIs and the applications built on top of them. Web APIs are commonly described in plain-text as part of Web pages, following no particular guidelines and conforming to no standards, despite some initial approaches in the area [1, 2]. Therefore, API providers publish descriptions in any language they see t, making the service discovery and the subsequent processing of the documentation challenging tasks. In this paper, we present a cross-lingual approach that calculates semantic similarity of text to help classify and annotate Web APIs, based on their textual descriptions. Furthermore, we show how our solution can be implemented as part of SWEET [3], which is a tool that enables the semi-automated creation of semantic Web API descriptions. In addition, we demonstrate how the cross-lingual approach can be adopted to support the language-independent discovery of Web APIs.
In the research context, English has established itself as a de-facto standard
language for conducting and publishing work. It is therefore easy to forget that
multilingualism is actually one of the main characteristics of the Semantic Web.
The importance of language diversity is made evident by the growing support
for the Linked Data initiative, which encourages government and public
organisations, as well as private institutions, to expose their data on the Web. Since
the document collections are published in the language, in which the original
sources are available, the result is an abundance of multi-lingual resources. In
comparison, the situation is quite similar in the context of services on the Web,
where the past few years have been marked by the increasing popularity and use
of Web APIs. The growing importance of Web APIs, also referred to as RESTful
services [
Despite their proliferation, Web APIs are facing a number of limitations. The
majority of the Web APIs have only textual descriptions that are given directly
as part of HTML Web pages, disregarding e orts towards a common formal
language for describing Web APIs [
In this paper, we focus in particular on supporting the Web API search and
discovery tasks by enhancing the descriptions with: 1) information about the
type of provided functionality (for example, a weather service or a shopping
service) and 2) central concepts that can be used for determining the domain
of the service or be taken directly for annotating service properties such as the
inputs and outputs. For this purpose we present an approach that makes use
of Cross-lingual Explicit Semantic Analysis [
The remainder of this paper is structured as follows: Section 2 provides a motivating example that illustrates the challenges of searching for APIs with particular functionality or from a particular domain, while Section 3 lists related work and gives some background in the area of semantic Web API descriptions and details on the cross-lingual semantic relatedness approach. Our API classication and annotation approaches are given in Section 4. Section 5 describes in more detail the solution design and the implementation of the key components, and Section 6 concludes the paper. 2
One of the most common service discovery tasks is discovery based on the functionality or the domain of the service (for example, \I am looking for an API that can map my travel route" or \I am looking for a shopping service"). Therefore, in this paper we focus our work on supporting this basic but essential discovery type. Currently the search options for APIs are very limited. One possibility is to use conventional search engines such as Google or Yahoo and do keyword search and hope that one of the returned matches is a Web API description. It is important to point out that so far there is no way of automatically distinguishing between webpages that describe Web APIs and webpages that simply mention an API, such as a news article, so this di erentiation has to be done manually. Another way is searching in Web API directories, such as ProgrammableWeb (http://www.programmableweb.com), which are based on manually collecting and registering APIs. A nal option is looking in developer forums and asking other users for suitable APIs, i.e. the \word of mouth" approach.
Figure 1 visualises a simple example, which demonstrates the necessity of
supporting cross-language Web API search. The presented API provides
capabilities for geocoding and reverse geocoding. If we use Google to search for
a geocoding API, the query will be language speci c; therefore, we would
either nd a service such as the popular GeoNames (http://www.geonames.org/
export/web-services.html), which is in English, or the example description
in Czech (http://ondras.zarovi.cz/smap/geokodovani/). However, it would
not be possible to nd both descriptions with one and the same search keywords.
Similarly, existing Web API directories are language speci c, in particular
restricted to English, as are developer sites and forums too.
abstracting away from syntactic speci cs, including the original language of the
documentation [
In this section we provide some background on the use of lightweight semantics for describing Web APIs, list existing annotation and tagging tools, and focus on providing details on common classi cation approaches and, in particular, on classi cation based on cross-lingual semantic relatedness. 3.1
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 discovery, negotiation, composition and invocation can have a higher level of automation, when services are enhanced with semantic descriptions of their properties. Similarly to \classical" Web services based on WSDL/SOAP, Web API-related tasks also require a lot of developer involvement and face even further di culties, since there is no established common formalism for describing Web APIs. In order to address this, lightweight annotations over API descriptions have been proposed as means for achieving a higher-level of automation.
Currently, there are two main contributions aiming at using semantics to
support the automation of common Web API service-related tasks. Both
approaches rely on marking service properties within the HTML description and
subsequently linking these to semantic entities. MicroWSMO [
Currently, there are quite a few tagging tools that enable the tagging of
web pages but also support the user in choosing the correct tags. Some of the
main ones include TagAssist [
Text classi cation has been successfully applied to many real world problems including spam detection, plagiarism detection or newspaper content classi cation, and its importance grew quickly with the amount of information available on the Web. Along with the widespread use of text classi cation methods comes the need for automated classi cation of new documents or web pages into hierarchies. This can be demonstrated on the Web by the existence of large web directories, such as Open Directory Project or ProgrammableWeb.
Over the past 20 years, text classi cation largely bene tted from the advances
in the eld of machine learning [
There are two common approaches to address this problem:
{ Machine translation approach - involves machine translation of texts to a
common language or interlingua and then represents the documents as
vectors in that language.
{ Mapping to a shared conceptual space - represents the documents as term
vectors in their source language and then projects them into a shared conceptual
space. This is typically done in practice with the help of
ontologies/vocabularies or by applying the distributional hypothesis [
An approach, which received much attention in the recent, years is to use
Wikipedia terms as a shared conceptual space. Texts can be mapped into this
space by performing Explicit Semantic Analysis (ESA) [
In this paper we describe a Web API classi cation and annotation method
that uses CL-ESA to classify the textual description of a Web API, given a
background collection of APIs. The form of CL-ESA that we utilise is equivalent
to [
In this section we describe in detail our approach for classifying Web APIs based solely on their textual documentation. We provide the devised algorithm as well as a speci c application example. We take the cross-lingual processing one step further and use it to determine the key concepts of the description, which can be used directly as tags or can serve as the basis for deriving further API annotations. 4.1
Our approach towards Web API classi cation is based on comparing the description of an API, which is to be classi ed, with a set of APIs already classi ed according to a given taxonomy. The speci c implementation of our approach is based on the ProgrammableWeb taxonomy, which comprises of 54 classes (http://www.programmableweb.com/apis/directory). We refer to the set of pre-classi ed services as Background Collection. In particular, we determine a number of representative service descriptions for each class in the taxonomy. These service descriptions are used as service models for the classi cation process. Moreover, the actual classi cation process is not based on the textual descriptions in the background collection but rather on the pre-computed ESA vector representations, thus saving computation time at runtime.
In addition to the background collection, we also de ne a set of stop words. Web API documentation use very limited vocabulary for describing the format of data and also for describing the behaviour of the Web API. For this reason, a stop-word le must be built to prevent the Explicit Semantic Analysis from focusing on the features of Web API descriptions that do not di erentiate the services into classes. Therefore, a su ciently large document collection in each of the input languages must be acquired and used to build the stop-word list. The stop-word list serves as an input for the pre-processing step of the Explicit Semantic Analysis.
Algorithm 1 formally describes the proposed API classi cation approach. In particular, the devised method includes the following steps. First we determine the language, in which the Web API description is written. This is currently not an issue and can be done easily by comparing the word distribution of the Web API description to average word distributions of other languages, or using one of the Web Services1. Second, we remove the web-service speci c stopwords and project the Web API description into the concept space given by the particular language version of Wikipedia. After that we project the vector into the English Wikipedia concept space, to facilitate its comparison with our Web API background. In the following step we iterate over each document in the background and record its similarity with the previously determined vector 1 http://code.google.com/apis/language/translate/v1/using_rest_ langdetect.html of the input Web API description. Finally, for each category, we add up the acquired similarity measure and divide it by the number of examples for the given category. We do this in order to derive a normalised similarity measure, which is not in uenced by the number of representative services. There are a number of further ways for determining the similarity measure (selecting the category with best service score, selecting the category with best median, etc.). The output is a list of categories, sorted according to their score. Algorithm 1 Assigning Class Labels to a Web API Description Require: webAPIDescription, backgroundCollection Ensure: Scored class suggestions language ← recognize language(webAPIDescription); esa vector ← esa analyze(language, webAPIDescription); esa vector en ← esa map vector(esa vector, language, \en"); category score ← new Map(); category cnt ← new Map(); for ⟨background api vector, category⟩ ∈ backgroundCollection do doc score ← vector similarity(esa vector en, background api vector); category score[category] ← category score[category] + doc score; category cnt[category] ← category cnt[category] + 1; end for for category, score ∈ category score do
result[category] ← score / category cnt[category]; end for sort(result); return result
Coming back to the example introduced in Section 2, independently of whether we want to classify the GeoNames API or the Czech geocoding API, both descriptions will be converted to English ESA vectors. Based on each vector a list (ideally, an identical list) of sorted categories will be produced. Therefore, independently of the language, both descriptions would in the end be mapped to the same category. We do not consider the case where a new category needs to be created but simply map the API to the closest of the existing categories. Previous approaches base classi cation on word matches or word stemming/similarity, therefore, they are not applicable to a multi-lingual context. 4.2
Central Concepts Detection We assume that two APIs can be described with the same central concepts if their descriptions are semantically similar (their semantic relatedness measure is above some threshold). Our approach towards detecting the Central Concepts of a non-english Web API description is to nd similar descriptions in a repository of English-based APIs (in this approach serving as background collection), and re-use its central concepts.
The Central Concepts for API descriptions in the repository. i.e. background collection, can be assigned either manually (e.g. by letting users assign keywords to services), using a concept extraction method or a concept extraction Web service. We will use the concept extraction Web service AlchemyAPI2. It would be possible to extract concepts from the non-English WebAPI description directly using the aforementioned Web service, but from our experience the concept detection from an English text yields much better results.
Algorithm 2 Determining the Central Concepts for a Web API Description Require: webAPIDescription, backgroundCollection language ← recognize language(webAPIDescription); esa vector ← esa analyze(language, webAPIDescription); esa vector en ← esa map vector(esa vector, language, \en"); for ⟨background api vector, central concepts⟩ ∈ backgroundCollection do score ← cosine similarity(esa vector en, background api vector); results[score] ← central concepts; end for return max(results)
Algorithm 2 represents the pseudo-code for our central concepts detection method. First, the language of the input API description is determined, and the description is projected into the ESA concept space of the particular language. Then, the ESA vector is mapped into the English concept space to facilitate its comparison with the ESA vectors of the services in the background API collection. The best matching service from the background collection is chosen and its central concepts are suggested as central concepts for the input API description.
If we use the algorithm to process the examples introduced in Section 2, the central concepts for the GeoNames API can be determined directly by using the AlchemyAPI. However, calculation of the central concepts for the Czech geocoding API is more challenging and is based on computing the cross-lingual similarity between its description and the descriptions in the background collection. The results, however, are comparable for both APIs.
The bene ts of determining the central concepts for an API description are
multifold. First, they can be used directly as tags for the Web API. These tags
can be employed to enhance search within directories or as complementary
information presented to the user as part of the API description. However, with some
further processing, the central concepts can serve as the basis for determining
semantic annotations for separate service parts, such as inputs and outputs, or
for extrapolating the domain of the service. In particular, we propose to input
the computed words into Watson [
the domain of the service and extrapolate a set of relevant domain ontologies. However, this work is beyond the scope of the paper but is envisioned as part of our future work. 4.3
The here described methods for cross-lingual classi cation and determining central concepts can be employed for supporting Web API search and discovery, overcoming language boundaries. In particular, the bene ts of enhancing Web API descriptions with classi cation information and speci c key words can be implemented both directly on the level of the API documentation as well as on the semantic level. For instance, existing Web API directories could be extended with search functionality about the type of service or based on keywords describing the service, which in contrast to current solutions, would be language independent. This is a simple, yet e ective way for enabling cross-language Web API search.
Furthermore, our work supports enhanced discovery by following the general approach outlined by semantic Web service technologies that aims to reduce the extensive manual e ort required for performing tasks such as discovery, negotiation, composition and invocation by enriching services with semantic descriptions of their properties. In particular, the computed classi cation type and annotations can directly be included as part of lightweight semantic Web API descriptions given in MicroWSMO or SA-REST. These, in turn serve as a basis for applying automated discovery approaches. In the following section we describe the implementation of a system that enables precisely the semi-automatic creation of semantic API descriptions in MicroWSMO, where the user is presented with a list of suitable categories and annotations to choose from. 5
In this section we validate our approach by presenting a system design and giving
an implementation solution realised by extending the Semantic Web sErvice
Editing Tool { SWEET [
The implementation of our cross-lingual Web API classi cation and annotation approach consists of three parts. The rst one is the background builder, 3 http://sweet.kmi.open.ac.uk/ which prepares the background collection for further classi cation, the second one proceeds with the actual classi cation, and the third one detects the central concepts. As background for the Explicit Semantic Analysis, we use di erent language versions of Wikipedia, in particular, English and Czech. The text analysis and its projection into ESA concepts space is done by our Java library, created by adapting the code from Wikiprep ESA implementation4.
Fig. 2. SWEET Extended Architecture
The Web API background collection is built by getting APIs and categories from http://www.programmableweb.com. Five APIs are taken as an example for each category. Information about each API is saved to a database and after that the web pages describing each API are harvested. Subsequently, the HTML mark-up is removed and the text is normalised by removing stop-words and stemming. Then, the ESA vector is computed and stored in the database. Additionally, central concepts for each API in the background collection can be automatically determined by the AlchemyAPI. Before putting the Web API description into the AlchemyAPI engine, we remove the service-speci c stop-words to get the Web API speci c concepts.
Both, classi cation and central concept detection operate similarly, and di er only in the last step. They start with projecting the input API description into the Czech Wikipedia concept space. Then, the resulting Czech ESA vector is mapped into English ESA vector, using the concept mapping from Wikipedia. Afterwords, the ESA vector is compared with each API description ESA vector from the API background collection. The last step is the following: { In case of classi cation, the results are aggregated and the best categories are suggested as candidates.
{ Concept detection does not summarise the results but rather suggests the central concepts of the rst few most semantically similar Web APIs as concept suggestions.
The so computed results can be represented to the user as annotation suggestions, aiding the process of creating the semantic Web API description. In the case of the classi cation of the service functionality, the top 3 results, for ex
ample, can be automatically assigned to the API and the annotator would only need to validate them.
We also ran some preliminary evaluation and tests. In particular, we ran
the concept detection system on the APIs from the geocoding domain. The rst
phase, which identi es the most similar service worked quite well, and was able to
locate relevant similar Web APIs. Therefore the classi cation task was completed
successfully. This evaluation needs to be extended to cover further domains, in
order to be able to make statements about the precision of the classi cation
approach in general. Our previous experiments with CL-ESA reported in [
In contrast, the concept extraction phase must be further re ned because the returned central concepts were not always relevant. We discovered that the results greatly depend on the quality of the background collection. In particular, we are using the Web APIs from the ProgrammableWeb directory, where Web APIs are sometimes assigned to the wrong category or the link to the API documentation is inaccurate. We can overcome these limitations by hand-picking the APIs per category or by ensuring that the URLs pointing to the API documentation are correct. Even if improvements still remain to be done, the initial results show that the approach, especially in the context of the classi cation task, is quite promising. 6
Nowadays, nding, interpreting and invoking Web APIs requires extensive
human involvement due to the fact that the majority of the APIs have only
textual documentation, not conforming to any particular standards and guidelines.
Moreover, providers publish API description in any language that they see t,
making the discovery of suitable services a challenging tasks. In this paper, we
present a cross-lingual approach, based on calculating semantic similarity, for
classifying APIs and determining the central concepts of their descriptions, thus
enabling language-independent search and discovery. We validate the
applicability of the proposed method by implementing it as part of an extension to
SWEET [
Acknowledgment The work presented in this paper is partially supported by funding from the EC FP7, under grant agreement number 270001 { Decipher