International Journal on Semantic Web and Information Systems

Volume 16 • Issue 1 • January-March 2020

An Architecture for Restful Web Service

Discovery Using Semantic Interfaces
José Renato Villela Dantas, Universidade de Fortaleza, Fortaleza, Brazil
Pedro Porfirio Muniz Farias, Universidade de Fortaleza, Fortaleza, Brazil

ABSTRACT

In the internet environment, web services based on representational state transfer (REST) have
become the de facto standard. The addition of semantics is intended to enhance the description of
web services with information that enables automatic agents to understand their data. However, the
existence of different languages to semantically describe services makes it difficult to discover and
select the service that best meets a requirement. Furthermore, relatively few proposals have a RESTful
service semantic description, making the discovery process for RESTful services more difficult. This
work proposes a RESTful semantic web service discovery architecture based on semantic interfaces
(SERIN). SERIN is an ontology with annotations that semantically describe RESTful web services.
This architecture enables software agents to automatically discover and make service calls in order
to execute a determined task.

Keywords
Restful Web Service, Semantic Interface, Semantic Web, SERIN, Web Service Discovery

1. INTRODUCTION

REST-based (or RESTful) web services (Fielding, 2000) are widely adopted on resource-oriented
architectures (ROA). They bring advantages such as scalability and general interfaces, and they
separate the server implementation from the client’s perception of resources (Richardson & Ruby,
2008). Furthermore, they do not obligate the provider to develop heavy service descriptions, as
WSDL does for SOAP services.
Considering the increasing amount of available web services, the discovery of an appropriate
one that agrees with the user’s requirements is a challenge (Pakari, Kheirkhah, & Jalali, 2014). Web
service discovery is the process of identifying the service that best matches some user-provided
characteristics.
Most of the web service discovery research has focused on three features (Priyadharshini &
Gunasri, 2013; Dong et al., 2013; Patil and Gopal, 2011): (i) matching user requirements with the
service description, (ii) the existence of a centralized repository where all service providers must
register their services, and (iii) the adoption of semantic web technologies to enrich the web service
descriptions.
The service matchmaking (feature (i)) is considered the most complex and difficult task in the
discovery process. Moreover, given de dynamic nature of available data, this problem should be
solved automatically (Cerón-Figueroa, 2017). The matching task usually considers some degree of
matching (Paolucci, Kawamura, Payne, & Sycara, 2002) as an indicator of the similarity between

DOI: 10.4018/IJSWIS.2020010101

Copyright © 2020, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.


1
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

requirements and service descriptors. As discussed by Dong, Hussain, and Chang in their semantic
web service matchmakers survey (Dong, Hussain, & Chang, 2013), many researchers have tried to
solve the discovery problem by optimizing the matching degree. These methods essentially compute
the matching degree by reducing the distance between the user goals and the service descriptions in
the minimum computation time. Usually, the service is described as a function of its inputs, outputs,
preconditions, effects, and nonfunctional properties. The discovery process usually tries to match
the service descriptor with the requirements descriptor. Some approaches propose to use logical
reasoning (Fang, 2018) or clustering (Bukhari, 2018) to organize similar web services and, thus, to
improve the performance of web service discovery.
The main problem with the matching is that it is always inaccurate. The consumer establishes
the minimal degree of matching that is acceptable to the task. However, this degree of matching is
not precise and may lead to errors. Finding a service that has the same (or similar to some degree)
inputs, outputs, preconditions and effects is not a sufficient condition for selecting a service.
Furthermore, considering the service composition context, the concatenation of services multiplies
the imprecision of the matching degree, leading to a very high imprecision at the end of the service
chain. For example, consider a chain with five services, each with a matching degree of 95%. The
final accumulated matching degree for the whole chain will be 0.955 = 0.77
The imprecision of the matching also increases when multiple ontologies are used to annotate
the user requirements or multiple ontologies are used to describe an existent service. (Fellah, 2016)
The existence of a centralized repository (feature (ii)) clearly contributes to a faster discovery
process. In most research, the starting point for discovering a service is a registry server, e.g., a
UDDI (OASIS, 2005) server. Nowadays, some web service portals, such as the aforementioned
ProgrammableWeb and several open government data portals, like https://www.data.gov and https://
data.gov.uk, are being adopted as tools to search for web services and APIs. All of them suffer from
the same difficulty: the service provider must register its service to make it known. This obligation
limits the discovery process to a single point of search, restricting the discovery process to the
registered services in the repository. Such a limitation removes all unregistered web services from
the discovery process.
Many studies (Dong et al., 2013; Pakari et al., 2014; Nacer & Aissani 2014) have found that the
addition of semantics to web service descriptions (feature (iii)) provides a valuable contribution to
the discovery task. Unfortunately, the heterogeneous nature of several service description languages
complicates the discovery process, because the consumer must know and create a proper service
client that can handle each language specification.
Adopting semantic web technologies, Muniz et al. (Muniz, Chaves, Campos Neto, Dantas, &
Farias, 2011) proposed the semantic interfaces (SERIN) specification to describe semantic web
services in functional terms. Conceptually, SERIN is an abstract interface that is analogous to those
in the object-oriented paradigm. The abstract interface defines the elements that the service provides,
but it does not concretely describe the service. Based on this abstract interface, service providers
implement the web services as concrete representations. The distinction between an abstract interface
and a concrete web service interface is important in enabling a more efficient and simpler service
discovery. It also enables an exact service matching.
In practice, SERIN is an annotated ontology that provides a mechanism to markup web service
functionalities and for locating service endpoints. As an ontology (Gruber, 1993) is, by definition,
shared knowledge, such an interface provides a web service description that is known to both the
client agent and the service provider.
Using the SERIN specification, it is possible to build an architecture to discover web services
from providers that implement one or several semantic interfaces. The discovery architecture identifies
the hosts that implement the services. This architecture considers clients to know the services already,
because they are described by the semantic interfaces. The scenarios and Motivation for SERIN
Discovery was presented in (Dantas, Lira, De Azevedo Muniz, Nunes, & Farias, 2015) using an early

2
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

version of Serin Ontology, also a client agent and a server application was described to illustrate the
steps involved to query the discovery server. The present study further investigates how the adoption
of semantic interfaces contributes to the web service discovery process. Our hypothesis is that the
adoption of semantic interfaces is a necessary and sufficient condition to discover the appropriate web
service. Semantic interfaces enable the sharing of knowledge between both provider and consumer.
This knowledge enables the consumer to implement only the code necessary to attend the interface,
avoiding the matching effort. So, SERIN bypass the problem of service matchmaking (feature(i))
because the accordance in using the same interface always guarantee a 100% accuracy
Basically, the discovery architecture considers the existence of a crawler agent that searches
the web, finds the SERIN-based services, and creates an inverted-index repository with the host
addresses that provide the services and the semantic interfaces they adopt. The crawler obviates the
need for registration, as the search is done by direct inspection of the service provider. This feature
contributes to the construction of a centralized repository (feature (ii)) much more scalable because
the repository is feed by the automatic discover of hosts that implement each semantic interfaces and
not by manual publication, in the central server, of each implemented web service.
In this paper, a new version of SERIN Ontology is used and an algorithm description of crawler
discovery is presented. An extensive comparation with four related proposals is presented. For each one,
SERIN similar implementations was constructed. An interface generator program was implemented
to convert ontologies in SERIN interfaces. One of the contributions of this paper is the construction
of a test collection for Restful web services consisting of 34 ontologies, 13.879 annotated classes
and 55.516 web services. The empirical performance tests of the crawler’s algorithm exhibited linear
complexity (O(N)).
The remainder of this paper is organized as follows: section 2 revisits recent state-of-art work
on RESTful semantic web service discovery; section 3 recalls the SERIN specification; section 4
introduces our proposal for web service discovery; section 5 analyzes the adoption of our proposal
in comparison with similar techniques; and section 6 tests the discovery process in a SERIN-adapted
testbed. Finally, section 7 presents our conclusions and proposals for future work.

2. SEMANTIC WEB SERVICE DISCOVERY

The web service discovery task has been extensively studied over recent years. The system proposed
by Pakari, Kheirkhan, and Jalali (2014) classifies the web service discovery approaches. They
categorized the discovery approaches as architecture views, matchmaking views, and automation
views. The architecture views can be classified as centralized or decentralized approaches, according
to the existence of elements such as a centralized registry server, crawler, or peer-to-peer distribution
of services. The matchmaking view can be classified as semantic-based, syntax-based, or context-
aware approaches. The automation view is classified as manual or automatic.
The core of the present discovery proposal is based on a language to semantically describe the
RESTful web services and takes a decentralized approach. We intend to improve the automation of
the service discovery and service mediation tasks. In this sense, we have investigated the approaches
that are related to these characteristics.

2.1. Semantic Service Description Languages

Nowadays, semantic web service description languages are mainly focused on the SOAP/WSDL
architecture. Many proposals have been made for the semantic enrichment of WSDL service
descriptors. The most common solutions are OWL-S (Martin, et al., 2007), WSMO (Keller, Lara,
Lausen, & Fensel, 2006), and SAWSDL (W3C, 2007).
We have found fewer solutions that formally describe RESTful web services. In WSDL 2.0
(Chinnici, Moreau, Ryman, & Weerawarana, 2007), descriptions are provided for both SOAP and

3
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

RESTful web services. WADL (Hadley, 2006) is another well-known language that has the same
purpose.
In addition, some RESTful web service descriptions enhanced with semantics include hRESTs
(Roman, Kopecký, Vitvar, Domingue, & Fensel, 2015), SA-REST (Gomadam, Ranabahu, & Sheth,
2010), RESTDesc (Verborgh, Steiner, Van Deursen, Van De Walle, & Valles, 2011), and ReLL
(Alarcón & Wilde, Linking data from RESTful services, 2010). All these proposals add semantics
to web services. However, they do not have a standard and shared language. They also demand
considerable effort to build an ontology and annotate the web service descriptions or webpages that
describe the services. More recently, the Linked Web API (Dojchinovski & Vitvar, 2015) has been
developed to reduce such effort with an architecture that semi-automatically generates a large RDF
dataset with semantic descriptions.

2.2. Service Matching

The majority of solutions for web service discovery focus on the matching task. Paolucci (Paolucci,
Kawamura, Payne, & Sycara, 2002) conducted a seminal study in which he introduced the degree of
matching (DoM), which describes the proximity between the user requirements and the web service.
After his work, many authors presented proposals to maximize the DoM.
The problem with matching is that it is always inaccurate, i.e., it is very difficult to obtain a
100% DoM. To the best of our knowledge, no approach can achieve this DoM value. Thus, there is
always a degree of uncertainty or error in the selected web service.

2.3. Decentralized Service Discovery

Despite most studies on web service discovery focusing on centralized approaches (mainly considering
UDDI as a service registry server), there are some decentralized approaches. Decentralized discovery
systems are based on distribution technologies, e.g., peer-to-peer, to publish service descriptions
over a network.
Dong et al. (Dong, Hussain, & Chang, 2013) noted that, inside the semantic web service field,
very little work has examined index-based service discovery. This area is dominated by nonspecialized
crawlers and index-based systems, such as webpage search engines or index-based systems for non-
semantic SOAP/WSDL web services.
In the present study, we found only a few semantic web service discovery methods based on web
crawlers, such as Service Search Crawler (Kaewmarin, Arch-int, & Arch-int, 2008), Restler (Alarcón
& Wilde, RESTler: crawling RESTful services, 2010), and iServe (Pedrinaci, Liu, Maleshkova,
Lambert, Kopecḱy, & Domingue, 2010).
The Service Search Crawler architecture for semantic web service discovery has a crawler as its
core element. Its function is to crawl the web searching for web service descriptions inside any host
and also in UDDI servers. The architecture considers web descriptions to be in WSDL format or
WSDL with semantic annotations such as OWL-S or WSDL-S. The necessity of considering a variety
of different languages complicates the crawler search algorithms. It is necessary to develop at least
one search algorithm for each description language. Moreover, the search algorithm needs to parse
web documents that contain web service descriptions. This task increases the search complexity. A
second limitation of this approach is that it does not apply to RESTful web services, but is restricted
to WSDL descriptions, which only apply to SOAP services. An extension to their study to consider
RESTful services would have to consider the limitations of the absence of a formal description for
RESTful web services.
Focusing on RESTful web services, Alarcón and Wilde presented Restler, a crawler that uses the
ReLL (Alarcón & Wilde, 2010) descriptions as instructions for traversing a RESTful web service.
This produces a typed graph of the resources and the links among them. The main goal of their work
was not to find web services or service providers, but to proceed from a known REST service and

4
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

generate the links among this service and related resources. This expands the linked data network
but provides little help for discovering new services or service providers.
The iServe tool (Pedrinaci, Panziera, & Mier) was developed for RESTful web service discovery.
The authors (Pedrinaci, Liu, Maleshkova, Lambert, Kopecḱy, & Domingue, 2010) intended to promote
interoperability among services that have descriptions implemented in different languages. To the best
of our knowledge, iServe implements resources to work with SAWSDL, WSMO-lite, MicroWSMO,
and partially with OWL-S.
The iServe architecture includes a component to reduce the descriptions in various languages
to a simplified generic model. The aim is to identify the so-called MSM (Minimal Service Model),
which is the most common model supporting the common publishing and searching of services. This
model was first introduced with WSMO-Lite (Vitvar, Kopeck, Viskova, & Fensel, 2008).
The architecture also projects the development of a crawler to look for web service descriptions
in the abovementioned languages. According to the iServe webpage (Pedrinaci, Panziera, & Mier,
iServe Architecture, 2015), the crawler module is a work in progress and has not been released to the
public. To the best of our knowledge, there is no crawler or search engine that collects web service
descriptions from all, or at least some, different languages to build a single index repository.
As a crawler option, the authors provide two API description editors, SWEET and SOWER. Both
enable developers to create web service descriptions with semantic annotation. They also provide
integration with the iServe tool for annotated web service publishing. In this respect, the iServe
framework is similar to other web service registry tools. The web service developers must register
their services in the tool to make them known.
It is apparent that most approaches focus on SOAP/WSDL web services with semantic annotations
in OWL-S or WSMO. There is a lack of REST approaches. In addition, some works have proposed
methods of discovery from UDDI registries, which do not require the service providers to register
their services.

3. SEMANTIC RESTFUL INTERFACE

The Semantic RESTful Interface (SERIN) (Muniz et al., 2011; Muniz et al., 2013; Lira et al., 2014) is
basically an annotated ontology whose classes and properties uniquely and semantically characterize
the available resources. The SERIN specification defines an upper ontology with the annotation
properties, some additional concepts, and their relationships. Figure 1 shows the SERIN ontology
elements. Some annotation properties are divided into two groups: operation and integrity constraint.
The Operation annotation properties represent the operations that are available over the services.
Four annotation types can be added to an ontology. These annotations indicate the existence of four
web service types: GET, POST, DELETE, and PUT. The four web service types are mapped into
four related HTTP methods that define which RESTful web service should be implemented for each
resource. These annotations present the minimal set of concepts necessary for the service discovery
process.
The Integrity Constraint annotation properties (Lira, 2015) represent constraints that can be
validated by a server when it executes a writing operation through the web service. These annotations
have some similarities with the integrity constraints in relational database models. Except for the
annotation id, this paper does not examine the Integrity Constraint annotations, because they are not
necessary for the discovery process.
The annotation property id is based on the concept of the primary key in relational databases.
This annotation defines an object property or a data property representing the unique identifier for
a resource. The resource class has a relation with the property that receives an id annotation. The
resource owner can use this annotated property to generate URIs for the resources. The discovery
process presented in the next section adopts this annotation to build web service requests.

5
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

Figure 1. SERIN ontology

Any ontology can import the SERIN ontology (http://www.activeontology.com.br/serin.owl)

to create a semantic interface. The ontology builder applies the SERIN annotations on the ontology
classes. The resulting annotated ontology is a Semantic RESTful Interface.
A set of RDF triples, i.e., an RDF instance, represents each resource. Each resource has an
identifier called an <rdfid>. The RDF instance granularity is too low to define a business process.
Usually, a set of instances are required to define a business entity.
Each host that implements a semantic interface must implement one RESTful web service for
each operation, i.e., for each annotation in a class.
The option to use only four web service types, whose semantics are pre-defined, makes the SERIN
semantics much simpler than proposals that specify semantics for SOAP/WSDL web services. The
Semantic Interface properly establishes the resource semantics. The four possible operation semantics
follow the CRUD model (Create, Read, Update, Delete) usually associated with HTTP verbs.
As this is an interface, the matching is always accurate. This provides higher scalability, which
makes it more attractive to the web environment.

6
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

Besides standardized semantics, SERIN also offers standardized service URLs. Each service
URL is divided into two parts. The first part identifies the host, and the second part semantically
identifies the resource.
The basic address convention format is:
http://{host}/{interface}/{class}/{resource}
where:

• host - IP or DNS host address.

• interface - ontology URI that represents the semantic interface.
• class - ontology class identifier.
• resource - resource identifier.

One can add some parameters to the basic address convention to reduce the result set. Each
property related to a class may work as a filter condition. The address convention to add filtering is:
http://{host}/{interface}/{class}?{property}={value}
where:

• property - A property in the interface ontology that is related to the class. It can be either a data
property or an object property.
• value - The value attribute for this property. A URI can assume the value in the case of an object
property.

The address convention allows the use of the ampersand (&) operator to add optional
property=value pairs.
Other special operators defined in the SERIN address convention specification are:

• properties - The requester may specify a list of properties to be returned. The result set will
present only the properties in this list.
• query - The requester may build a more complex query using logical and Boolean operators.
Note that the objects in the query are those contained in the semantic interface.
• size - Limits the number of returned occurrences.
• page - Enables pagination of the returned occurrences.

Combining these operators, the address convention syntax is:

http://{host}/{interface}/{class}?{property}={value}&properties=
({property 1}/.../{propertyN})&size=x&page=n
This section has only presented the patterns for the SERIN address convention. Practical examples
for the address convention are discussed in section 5.

4. ARCHITECTURE FOR WEB SERVICE DISCOVERY

SERIN discovery architecture has three goals: the discovery of new hosts that implements SERIN-
based web services; the discovery of new semantic interfaces; and the discovery of the relationships
among hosts and semantic interfaces.
To achieve the goal of discover new hosts, this architecture proposes a crawler that searches the
web looking for hosts that implement any SERIN semantic interface, presented in the previous chapter.
The goal of discovering new semantic interfaces is achieved by executing a direct inspect in the
hosts to identify which semantic interfaces each one implements. The host can response with new
semantic interfaces that the discovery server does not know at the moment of the inspection.

7
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

The direct inspect in a host also contributes to achieve the third goal: discover the relationships
between hosts and semantic interfaces. In a direct inspect, the host responses with a set of semantic
interfaces that it implements. With this response, it is possible to establish the relation between this
host and its semantic interface.
This goal is important because this relationship contributes to the web service mediation process.
When the client agent knows the relationship between a host and a semantic interface, the client agent
knows which web services the host implements and she knows the description of these web services.
This information is sufficient to the client agent make a request to the web service.
The four main architectural components in this discovery process are the semantic interface, the
service clients, the hosts that act as service providers, and the discovery server.
The annotated ontology that represents the semantic interface must be known by all other agents,
i.e. the clients, the hosts, and the discovery server. Knowing the semantic interface, these agents
know how to make requests and responses for the web services. The service clients are the agents
that execute the requests for web services. The client agent reads the semantic interface, build the
requests based on SERIN address convention, and process the web service responses.
The clients can be automatic agents or human users. An automatic agent is a client software
agent that automatically requests web services in the host. This agent can also execute requests to the
discovery server to obtain information about the available hosts and available semantic interfaces.
A user can execute a query in the discovery server manual query module or he can request the web
service in a browser.
The hosts act as web service providers. They are responsible to implement the web services
and to provide the responses to the client request. In the discovery process, the host is responsible
to provide information about its implemented web services to the discovery server. The discovery
server scans the Web trying to find out SERIN semantic interfaces and hosts that implement these
interfaces. This server maintains an index repository with the identified hosts and their interfaces
on a centralized inverted-index. Additionally, it provides a manual and an automatic query module
where users and automatic agents can consult the index repository.
The discovery server is the core element of the proposed architecture because it provides a
centralized mechanism to the clients for querying hosts. This centralized mechanism contributes
to reduce the discovery execution time. The next section presents the discovery server components
(Figure 2).
The discovery server is composed of four components:

1. An index repository that maps semantic interfaces to hosts.

2. A scanning module - a crawler that scans web content, updating the index.
3. A manual query module - a site where users can query the index.
4. An automatic query module - semantic web services from which automatic agents can request
data from the index repository.

4.1. Index Repository

The index repository stores the service providers addresses, the semantic interfaces, as well as the
known relationships among them. The repository database stores records that are instances of the
SERIN ontology.
A SERIN discovery server can implement the index in a relational database. In such case, SERIN
ontology classes Host and Interface and their relationships works as a database schema. The classes
Host and Interface can be implemented as tables while their respective properties can be implemented
as columns in these tables.
In case of a relational database storage, the discovery server can provide a consulting mechanism
that returns the data in a SQL format. This is not recommended because the SQL format lacks the

8
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

Figure 2. SERIN discovery process

semantics provided by SERIN ontology. The suggestion is that the results are provided in a format
that enables semantic information.
It is possible, but not mandatory, to store the hosts and interfaces as RDF triples. The RDF
statements are in the form:
<serin:Host>
<serin:implements>
<serin:Interface>
or
<serin:Interface>
<serin:isImplementedBy>
<serin:Host>
Optionally, it is possible to store the index in a relational database. In such cases, the SERIN
ontology classes of Host and Interface and their relationships function as a database schema.

4.2. Scanning Module

The scanning module is a crawler that scans the Web looking for hosts that implements semantic
interfaces. The discovery process works in two steps. At first, the crawler identifies a set of hosts.
Secondly, it identifies which interfaces are available in each host.
There is a difference between usual web service discovery architectures and SERIN discovery
architecture. The usual web service discovery architectures try to identify the most appropriate service
among a set of available services in the same host. This is not the purpose in SERIN architecture.
The main goal of the scanning module is to discover the relationships among hosts and their
semantic interfaces, i.e., which semantic interfaces a host implements. Considering that the discovery

9
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

server already knows the interfaces, i.e., the discovery server already knows the web service
descriptions, the remaining task is the search for providers that implements these web services. In
the process of discovering these relationships, the crawler can also find new hosts and new semantic
interfaces.
The crawler is responsible to executes four tasks:

• Generate a list of known hosts as a starting point to the discovery process.

• Send requests to the hosts to direct inspect their available semantic interfaces.
• Check the availability of a semantic interface in a host.
• Save the data about hosts and semantic interfaces in the index repository.

4.3. Web Service Query Module

The web service query module is a consultation mechanism to the index repository. This module
have specific web services to request information about indexed hosts and about indexed semantic
interfaces. This module is intentionally designed to provide information for automatic consultation.
These web services attend the SERIN semantic interfaces. This means that the SERIN ontology
represents the interface that describes the web services. It also means that the web services follow
the SERIN address convention. The hosts and interfaces that are stored in the index repository are
instances of their respective classes in SERIN ontology.
The SERIN discovery server implements five web services. These services provide a list of hosts
that attends an interface and which interfaces a host attends. Table 1 presents the available methods.
where:
{discovery server} = IP or DNS address of the discovery server.
{host id} = the identificator of a host.
{interface URI} = the URI of a semantic interface.
The hosts must implement the web service
http://{discovery server}/serin.owl/Implemented_Interface
This is the only web service whose implementation is required for the host. This service is
necessary to the execution of a task of direct inspect in the host. Since it is not a condition that each
host work as a discovery server, the other web services in Table 5 does not require an implementation
in the hosts. Of course, each host must also implement the web services described by the semantic
interfaces that it follows.

4.4. Manual Query Module

The manual query module is an endpoint in which human users can execute queries to obtain index
repository data. The manual endpoint acts as a SPARQL query engine. Users may either write a web
service URL or a SPARQL query.

Table 1. Available web services for the discovery server

Method Description
http://{discovery server}/serin.owl/Host Returns the list of all indexed hosts.
http://{discovery server}/serin.owl/Host/{host id} Returns the list of all interfaces that the host uses.
http://{discovery server}/serin.owl/Interface Returns the list of all indexed interfaces.
http://{discovery server}/serin.owl/Interface/{interface URI} Returns the list of all hosts that use the interface.

10
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

It is desirable that the manual module display the responses in human-readable format. The
endpoint default result format is a user-friendly table. If preferred, the user can change the default
format to RDF triples.
The manual query module is an endpoint where human users can execute queries to get the index
repository data. The manual endpoint acts as an SPARQL query engine. The user may either write
a web service URL or a SPARQL query.
It is desirable that the manual module display the responses in a human readable format. The
endpoint default result format is a table, which is more user-friendly format.
If the user prefers, he can change the default format to RDF triples

5. COMPARISON WITH PREVIOUS APPROACHES

This section compares the SERIN discovery approach with the approaches presented in section 2.
We considered a use-case that exemplifies the compared approaches and implemented it using the
SERIN specification. Due to space limitations, the experiments were summarized in this section. A
more complete presentation of these experiments can be found in (Dantas, 2016)

5.1. hRESTs
The hRESTs approach considers a web service with an associated HTML description. Microformat
hRESTs classes should be added to this description to ensure they are machine comprehensible. The
authors define microformat classes that formally describe the web services, such as service, operation,
address, method, input, and output.
The HTML description is mapped into RDF through GRDDL (Connolly, 2007), a mechanism
for extracting RDF from webpages. Listing 1 presents an example of an hRESTs description.
Listing 1. Example hRESTs service description (Roman, Kopecký, Vitvar, Domingue, & Fensel,
2015).
<div class= “service” id=”svc”>
<h1><span class= “label”>ACME Hotels</span>
service API</h1>
<div class= “operation” id= “op1”>
<h2>Operation <span class= “label”>
getHotelDetails</span></h2>
<p> Invoked using the
<span class= “method”>GET</span> at
<code class= “address”>
http://example.com/h/id
</code><br/>
<span class= “input”>
<strong>Parameters:</strong>
<code>id</code> the identifier of the particular
hotel </span><br/>
<span class= “output”>
<strong>Output value:</strong>
hotel details in an
<code>ex:hotelInformation</code> document
</span>
</p>
</div></div>
In the hRESTs approach, the discovery process consists of searching for hRESTs service
descriptions. The main problem with this approach is that it is based on matching processes. The

11
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

matching considers only inputs and outputs. In the example of Listing 1, the semantics in the class
service= “svc” and in the class operation= “getHotelDetails” do not enable machine interpretation
of which operation the service really provides. The service description enables the identification of
the inputs and outputs but lacks semantics for these parameters. It is not possible, for example, for
the agent to know exactly what hotel information the service provides.

5.1.1. SERIN Similar Implementation

The same example described in SERIN enables the client agent to identify the relevant concepts.
This example adopts the Travel ontology as an interface. Listing 2 presents the annotated concepts
in the Travel Ontology for the example in Listing 1.
Listing 2. Example Travel Ontology with annotations.
<rdf:RDF
xmlns=”http://127.0.0.1/ontology/travel.owl#”
xml:travel=”http://127.0.0.1/ontology/travel.owl”
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:owl=”http://www.w3.org/2002/07/owl#”
xmlns:serin=”http://www.activeontology.com.br/serin.owl#”>
<owl:Class
rdf:about=”travel:Hotel”>
<rdfs:subClassOf rdf:resource=”travel:Accommodation”/>
<serin:post></serin:post>
<serin:put></serin:put>
<serin:get></serin:get>
<serin:delete></serin:delete>
</owl:Class>
<owl:ObjectProperty rdf:about=”travel:isReserved”>
<rdfs:domain rdf:resource=”travel:Hotel”/>
</owl:ObjectProperty>
Based on this interface, a client can make a request to the desired hotel host. The service that
provides Hotel information, similar to the getHotelDetails service in the hRESTs example, has the
address:
http://example.hotel.com/serin/travel.owl/Hotel/id
By definition, the information is a list of individuals that have types equal to the Hotel class.
Observing the Travel Ontology, it is possible to know that the returned information consists of
individuals URIs with the property isReserved. The concepts in the ontology are shared information.
Sharing the information enables software agents to identify the format of the service responses. Listing
3 shows an example of the response to a request for the individual id = “FourSeasons”.
Listing 3. Example Hotel Named Individual.
<rdf:RDF
xml:travel=”http://127.0.0.1/ontology/travel.owl”
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:owl=”http://www.w3.org/2002/07/owl#”>
<owl:NamedIndividual rdf:about=”travel:FourSeasons”>
<rdf:type rdf:resource=”travel:Hotel”/>
<isReserved rdf:resource=”travel:JohnDoe”/>
</owl:NamedIndividual>
Any hotel host can implement this Travel interface. However, each hotel host provides its
particular data in response to the same web service request. In the example above, the web service
returns the data shown in Listing 3 only when the client makes a call to the FourSeasons Hotel. If

12
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

the client makes the same request to the AnotherSeasons Hotel server, it will receive a response that
has the same structure, but with different data.

5.2. SA-REST
SA-REST is an approach to add semantics to RESTful web services. SA-REST annotates output,
input, operations, and faults, along with the type of request that is needed to invoke the service.

Data mediation is effected in SA-REST not only by specifying the ontology concept that its message
represents, but also by specifying a lifting and lowering schema. What a lifting and lowering schema
does is to translate the data structure that represents the input and output to the data structure of the
ontology, which we call the grounding schema (Lathem, 2007).

Most RESTful web services have HTML pages that describe what the service does and how
to invoke it. SA-REST embeds its semantic annotations in RDFa (Adida & Birbeck, 2008) into the
HTML page that describes the service. These annotations make the description of the service both
human-readable and machine-readable, while also creating a single place to be updated if the service
ever changes. Users can use GRDDL to attach annotations.
The RDF triples can be extracted from the XHTML via parsers or XSLTs. The subject of the
triple should be the URL at which you would invoke the service. The predicate of the triple should
be either sarest:input, sarest:output, sarest:operation, sarest:lifting, sarest:lowering, or sarest:fault,
where sarest is the alias for the SA-REST namespace. The object of the triple should be either a URI
or a URL of a resource, depending on the predicate of the triple.
The sarest:lifting and sarest:lowering annotations are used for data mediation. Users can specify
the data mediation using the principles of lifting and lowering with XSLT documents that capture
the mediation rules.
Listing 4. SA-REST document (Sheth, Gomadam, & Lathem, 2007).
<html xmlns:sarest=”http://lsdis.cs.uga.edu/SAREST#”>
...
<p about=” http://craigslist.org/search/”>
The logical input of this service is an
<span property= “sarest:input”>
http://lsdis.cs.uga.edu/ont.owl#Location_Query
</span>
object.The logical output of this service is a list of
<span property= “sarest:output”>
http://lsdis.cs.uga.edu/ont.owl#Location
</span>
objects.This service should be invoked using an
<span property= “sarest:action”>
HTTP GET
</span>
<meta property= “sarest:lifting” content=
“http://craigslist.org/api/lifting.xsl”/>
<meta property= “sarest:lowering” content=
“http://craigslist.org/api/lowering.xsl”/>
<meta property= “sarest:operation” content=
“http://lsdis.cs.uga.edu/
ont.owl#Location_Search”/>
</p>

13
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

5.2.1. SA-REST Analysis

From the website specification:

SA-REST is a poshformat to add additional meta-data to (but not limited to) REST API descriptions
in HTML or XHTML (Gomadam, Ranabahu, & Sheth, 2010).

SA-REST establishes a direct relation to SAWSDL. Indeed, the authors propose a translator
from SA-REST to SAWSDL and back. The main problem is that both specifications are heavyweight
implementations, unlike the lightweight REST specification. The existence of a SA-REST document
to formally describe the web service means that this document must be updated every time the web
service changes.

5.2.2. Serin Similar Implementation

The same example shown in listing 4 can be implemented using SERIN. The example describes a
craigslist.com service that returns information about Locations.
The first step is to insert SERIN annotations in their ontology. The example only shows a
description of a GET request. DELETE, POST, or PUT annotations can also be inserted. The annotated
classes are shown in Listing 5.
Listing 5. SERIN annotated ont.owl Location class.
<rdf:RDF
xmlns:owl=”http://www.w3.org/2002/07/owl#”
xmlns:ont= “http://lsdis.cs.uga.edu/ont.owl#”>
xmlns:serin= “http://www.activeontology.com.br/serin.owl#”>
<owl:Class rdf:about= “ont:Location”>
<serin:get></serin:get>
</owl:Class>
</rdf;RDF>
In SA-REST, a Location_Search class defines the search operation that returns a list of Location
individuals. In a SERIN server, the following request returns the same result:
GET serin/ont.owl/Location HTTP 1.1
Thus, it is not necessary to annotate the ontology classes, as Location_Search class, that define
operations, because the operation GET Class does the same job.
Note that, in the SA-REST description, it was necessary to define the input, output, action,
lifting, lowering, and operation to describe the service. In contrast, SERIN requires only the GET
annotation in the Location class to define the same service. The action is previously defined, because
SERIN assumes the HTTP semantics for the operations. The input and output are already defined in
the ontology that acts as the semantic interface. The lifting and lowering are not necessary, because
once the interface is known the mediation is defined by the semantics in the HTTP operations.

5.3. RESTdesc
The goals of RESTdesc are: 1) to have a functionality-centered and formally defined service
description; 2) to use semantic web technologies; and 3) to emphasize simplicity and elegance.
The following example adopts the DBpedia ontology.
Listing 6 shows how the functionality of the authors resource can be expressed in “traditional”
RESTdesc. The descriptions explain how to take the ISBN code of a book and construct the URI to
retrieve the authors.
Listing 6. Coupled RESTdesc description for book authors (Verborgh, Steiner, Van Deursen,
Van De Walle, & Valles, 2011).

14
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

{ ?book dbpedia:isbn ?isbn. }

=>
{ _:request http:methodName “GET”;
tmpl:requestURI (“/books/” ?isbn “/authors”);
http:resp [tmpl:representsMultiple ?author].
?book dbpedia:author ?author. }.
In contrast, the linked RESTdesc description in listing 7 does not need any properties to construct
the URL.
Listing 7. Linked RESTdesc description for book authors (Verborgh, Steiner, Van Deursen, Van
De Walle, & Valles, 2011).
{ ?book a dbpedia:Book. }
=> { ?book dbpedia:author _:author;
dbpedia:subject _:subject;
dbpedia:publisher _:publisher;
[. . . ]. }.

5.3.1. RESTdesc Example Using Serin

Using SERIN, the same book author example needs the annotations in the DBpedia ontology.
Listing 8. SERIN description for book authors.
<rdf:RDF
[...]
xmlns:serin=”http://www.activeontology.com.br/serin.owl#”>
<owl:Ontology rdf:about=”http://dbpedia.org/ontology/”>
[...]
<owl:imports rdf:resource=”http://www.activeontology.com.br/
serin.owl”/>
</owl:Ontology>
<owl:Class rdf:about=”http://dbpedia.org/ontology/Book”>
[...]
<rdfs:subClassOf rdf:resource=”http://dbpedia.org/ontology/
WrittenWork”/>
<serin:get></serin:get>
</owl:Class>
<owl:Class rdf:about=”http://dbpedia.org/ontology/WrittenWork”>
[...]
<rdfs:subClassOf rdf:resource=”http://dbpedia.org/ontology/
Work”/>
</owl:Class>
<owl:ObjectProperty rdf:about=”http://dbpedia.org/ontology/
author”>
[...]
<rdfs:domain rdf:resource=”http://dbpedia.org/ontology/Work”/>
</owl:ObjectProperty>
</rdf:RDF>
The DBpedia ontology was adapted to receive SERIN annotations. Only two adaptations are
necessary to define a web service description: import the serin.owl ontology (line 3) and insert the
AnnotationProperty serin:get in the Book class (line 11). The DBpedia ontology defines an author as
a property related to Book (line 19) by inheritance from its superclass (lines 10 and 15). We named
the resulting ontology serin-dbpedia.owl to distinguish it from the original dbpedia.owl. Applying

15
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

the addressing pattern over the annotated DBpedia ontology, it is possible to define the web service
of obtaining book author information.
GET /serin/serin-dbpedia.owl/Book/{dbpedia:isbn}?properties=(dbpe
dia:author) HTTP 1.1
Both the RESTdesc and SERIN specifications define a two-part request that splits the server
address from the functional definition. However, in RESTdesc, it is necessary to create one description
for each web service. In practice, a service that returns a different set of parameters should have its
own description, which can increase the effort involved in building the descriptions.
The SERIN address convention eases the burden of building web service descriptions once all
services follow the same pattern. As shown in section 3, the pattern for the Book web service is:
GET /serin/serin-dbpedia.owl/Book/{dbpedia:isbn}?properties=({pro
perty 1}/{property 2}/.../{property N}) HTTP 1.1
where:

• /serin/serin-dbpedia.owl/Book/ = invariant part for Book information;

• dbpedia:isbn = variant part containing the book identifier. In this example, the ISBN identifies
the book.
• properties = set of properties that the web service should return. If a service provider does not
implement any of the properties, the web service returns only the available properties.

The same pattern can be extended to any DBpedia class as:

GET /serin/serin-dbpedia.owl/{dbpedia:class}/{dbpedia:id}?propert
ies=(dbpedia:property) HTTP 1.1
If the client intends to request information about a set of books instead of one single book, a filter
parameter can substitute the book ID (<dbpedia:isbn>). The web service pattern, which returns all
books from the same author for a specific year, becomes:
GET /serin/serin-dbpedia.owl/Book?dbpedia:author={author
URI}&dbpedia:year={value of year} HTTP 1.1
or, using a query as a filter clause:
GET /serin/serin-dbpedia.owl/Book?query=dbpedia:author = {author
URI} AND dbpedia:year>{value of year} HTTP 1.1
As the service provider uses a semantic interface, there is no need to explicitly describe the
services, because the semantic interface already describes them. The provider need only implement
the services based on the interface. The client agent can build the service request because it knows
the address convention and the semantic interface represented by the annotated DBpedia.

5.4. ReLL
ReLL (Resource Linking Language) describes RESTful web services and provides a mapping from
the interlinked graph-oriented world of RESTful services to the graph-based model of RDF. For the
purpose of describing a RESTful service, the main elements in ReLL are the resources (rell:resource),
the links (rell:link) among these resources, and the protocol representation (rell:representation) and
protocol interactions.
Because ReLL describes a REST application, it is used to generate a domain ontology for the
application. This ontology is the basis for converting the service resources into RDF triples.
The authors made no attempt to formalize the semantics. They consider that, for the mere
description of a service interface, the semantics of the resources are not necessary. We consider the
absence of semantics to make it harder to execute a proper discovery process.
In fact, the Restler crawler proposed by the same authors (see subsection 2.3) needs a formal
ReLL document as the service description. This discovery process does not need formal semantics,

16
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

but the crawler is highly coupled to a specific language. This coupling increases the development
effort, as one crawler is required for each description language.
As we have mentioned, SERIN already has a domain ontology, which is the semantic interface
itself. Thus, it is not necessary to create a new one. This domain ontology adopts OWL, which is a
highly consolidated language. Therefore, clients do not need to implement different algorithms for
new languages, thus reducing the coupling between service and client.

6. ARCHITECTURE ANALYSIS AND RESULTS

In this section, we describe a nonfunctional test in which we evaluate the performance of SERIN-
based web services. To execute this test, we constructed a test collection composed of semantic web
services, ontologies, and queries.
The search for RESTful web service test platforms or collections for evaluating the performance
of matchmakers and the service itself led to the conclusion that there is a lack of such test platforms.
To the best of our knowledge, there are only two test providers, the Semantic Web Challenge (http://
challenge.semanticweb.org/2015/) and the SemWebCentral portal (http://projects.semwebcentral.
org/projects/).
The Semantic Web Challenge test platform defines the requirements that a web service must use
and contains an execution environment to analyze the matching algorithms. The Semantic Service
Selection (S3) platform is a complementary test platform that evaluates the retrieval performance
of matchmakers.
The SemWebCentral portal provides test collections composed of a set of ontologies and web
service descriptions. Most of these test collections are based on SOAP/WSDL technology. The OWL-S
and WSMO languages define the semantics of these services.
It was difficult to use these test platforms for two reasons. First, these test platforms and collections
focus on testing the matchmaking algorithms, which we try to avoid in the discovery process presented
in our work. Second, although these platforms provide a good framework that is sufficient for tests
with SOAP/WSDL-based web services, they do not provide a platform for REST-based tests. We
found only one REST-based test collection for the hRests language on the SemWebCentral portal.
We conducted a study to verify the feasibility of the proposed web service discovery architecture.
A test collection was built to help execute further functional and nonfunctional tests. Although
we concentrated on functional tests, the test collection was prepared so as to be suitable for future
nonfunctional evaluations. We executed the crawler discovery algorithm to discover the services
contained in the test collection and check their availability. At the end of this section, we present the
applied algorithm and an execution example.
Some authors have mentioned the necessity of creating adequate test collections for RESTful
web services. Ngan and Kanagasabai (2012) stated that the need for comprehensive and practical
benchmarks/testbeds is an important web service discovery challenge. Dong et al. (2013) discussed
the lack of test platforms or collections for evaluating the performance of matchmakers and the process
of RESTful web service discovery.
We built a test collection from the hRESTS-TC (http://www.semwebcentral.org/projects/hrests-
tc/) release 2 package, which can be obtained through the SemWebCentral portal. This package
provides a collection of 1080 web service description distributed over nine domain areas, 38 domain
ontologies, and 42 queries. The web services are semantically annotated in the hRESTS format. This
collection is typically used for comparative matchmaking studies, whereby a query is matched with
a service. The main motivation for choosing this collection is that it provides RESTful web services.
The SERIN specification liberates the web services from requiring a description document. The
only formal description needed is the annotated ontology. Hence, we started from the ontologies in the
hRESTS-TC package. We built an interface generator program to automatically convert each ontology
into a SERIN interface. To do so, the program added the following statements to each ontology:

17
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

• Import the SERIN ontology.

• Associate an AnnotationProperty to each ontology class. Each class received four SERIN
annotation properties - GET, PUT, POST, and DELETE - representing the HTTP operations.

The result was a semantic interface set consisting of 34 ontologies, with 13,879 annotated classes
providing 55,516 web services. These annotated ontologies provide the service functional semantics,
described by the ontology concepts, and the behavioral semantics, which are the HTTP operations
represented by the annotation properties.
The implementation of the service provider for all these services is quite simple. Previously, we
implemented a server to provide SERIN services. This server has a configuration file with properties
in the format of a key/value pair indicating the available semantic interfaces. All the web services can
be made available by setting this key/value pair for each ontology. The interface generator program
also inserted some registries in the server database. This database provides server data about which
interfaces it uses.
The same interface generator program can convert any OWL ontology into a SERIN interface.
If researchers wish to conduct their own tests, the source code is available at the SERIN website
(https://www.semanticinterface.org).
We executed the discovery service crawler algorithm shown below, in which H = {1,..h n } is a
set of hosts in a network; fa (h) = ip is a function that gets the host address (DNS or IP); fu (ip) = url
is a function that returns the discovery web service URL (composed of the host address with the
added string “serin.owl/Interface”); fi (url) = Ih is a request function that returns the semantic
interface URIs Ih = {1,..¹n } , and Si = {1,..sn } is a set of hosts that implements a SERIN interface,
where Si ⊆ H .
Listing 9. Crawler web service discovery algorithm.
      H ← {1,..h n }
      S ← ∅
for each h ∈ H
Ih ←
ip ← fa (h)
url ← fu (ip)
if fi (url) = Status.OK
then
Ih ← fi (url)
for each ¹n ∈ I
Si ← h n
end for
end if
end for
return S
The algorithm splits each search result to get the server address, and then builds the web service
address based on the SERIN address convention. It then checks whether the server responds to requests
that verify the semantic interface. Finally, if the server responds with a positive answer, the crawler
saves the results in the index repository.
Several approaches can build the initial host set $H$. In this study, we set the initial host list
using our local server’s IP addresses. Another option is to start searching using the Google Custom

18
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

Search API or any other search engine. In this case, we defined the initial keyword expressions to start
searching under a desired domain. It is possible to expand this server list using a webpage crawler to
get the IP server addresses inside webpages contained in these initial hosts. This option is yet to be
tested. A third possibility is to receive a list of certain domains, for example, the .gov domain. In a
real-world scenario, governmental agencies could provide a DNS list of all its servers. In this case,
it would be possible to restrict discovery to government services.
The crawler continuously checks whether the server is on by making calls to the server address.
The crawler also checks whether all web services are still available. These checking operations keep
the index repository updated by inserting new semantic interfaces when the algorithm identifies
them in the hosts. In the tests, we executed requests in local service providers to check for service
availability. The services are described by semantic interfaces. The results are illustrated in Figure 3.
The increase in execution time with the number of requests was as expected, as the method executes a
direct request for each service it inspects. More services imply a greater execution time. The advantage,
in this case, is that only one request is needed to inspect a server. Other approaches usually crawl all
webpages to find the services.
( )
The complexity of the crawler algorithm is given by O (h) = H*I h , i.e., the number of hosts
(H) multiplied by the average number of interfaces in a host (Ih). The algorithm exhibits linear
complexity (O(N)). The graphic in Figure 3 verifies this complexity.
This study has demonstrated that semantic interfaces can easily provide machine-readable web
service descriptions. The semantic interfaces release the service providers from the need to provide
another service description than the annotated ontology. A large number of RESTful semantic web
services were generated with little implementation effort. The most time-consuming step in the

Figure 3. Discovery agent check service method - Discovery time per request set.

19
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

ontology construction, i.e., making the domain ontology, is shared by all domain specialists and
developers.
The same study was not executed for the other available test collections, hRESTs-TC and
SAWSDL-TC (http://www.semwebcentral.org/projects/sawsdl-tc/) (a base for hRESTs-TC). The
crawler algorithm requires the existence of a semantic interface and will not work for different service
descriptions. The published results for these test collections focus on matching algorithms. As our
proposal avoids the matching process, it is not possible to compare the results with those presented here.
In this study, we constructed a test collection for RESTful web services with semantic interface
descriptions. This collection can aid developers that are interested in SERIN-based web service
development. In addition to the services, the collection also provides a set of queries in the SERIN
format. These queries were used in further tests for service selection and service composition. The
results of these tests have not been presented here because of space limitations.

7. CONCLUSION

The discovery of RESTful web services is considered a difficult task. The lack of an appropriate
language for REST-based service descriptions complicates the identification and selection of the
service that best matches some user requirement. Furthermore, the lack of semantics in the description
hampers software agents from automatically or semi-automatically executing discovery tasks, making
user intervention inevitable.
The approach presented in this paper reduces the complexity of this task. In this sense, the SERIN
semantic interfaces provide the resources for defining RESTful semantic web service descriptions. One
advantage of this approach is that SERIN is an interface. By definition, it provides a shared description
that both the client and service provider know and agree. SERIN adopts an annotated ontology based
on common and standard languages, which makes the process of building an interface very simple.
We assume that all involved actors adopt the same API and the same interface. This is a very
reasonable assumption, as it is one of the most important principles of the semantic web. The
assumption of the adoption of a semantic interface is similar to the assumption of the adoption of
ontologies in the semantic web. As they promote the creation of ontologies, the creation of semantic
interfaces entails relatively low development effort.
The shared ontology and address convention enables the implementation of a decentralized
discovery architecture. A crawler navigates the web, indexing the web services and their providers.
The complexity of the discovery algorithm is low considering that it makes direct calls to the services
that use an interface. The crawler eliminates the need to register the services in a UDDI server or
any other service index.
The study described in this paper also contributes to the implementation and testing of discovery
architectures. We presented an implementation of a crawler algorithm that can be installed to build
a discovery server. Those who intend to build a SERIN server that provides semantic interfaces can
access our semantic interface generator program, which aids the costliest task in this process, i.e. the
building of semantic interfaces from any ontology. The test collection provided here will also assist
with semantic interface tests. Under this framework, researchers can easily construct a functional
host that provides semantic web services based on SERIN interfaces.
In future work, we intend to implement decision criteria for service selection based on
nonfunctional requirements. Another study will extend the discovery process to service compositions.

20
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

8. REFERENCES

Adida, B., & Birbeck, M. (2008). RDFa Primer. W3C. Retrieved from http://www.w3.org/TR/xhtml-rdfa-primer
Alarcón, R., & Wilde, E. (2010). Linking data from RESTful services. Proceedings of the Third workshop on
linked data on the web, Raleigh, NC. Academic Press.
Alarcón, R., & Wilde, E. (2010). RESTler: crawling RESTful services. Proceedings of the 19th international
conference on World wide web, Raleigh, NC (pp. 1051--1052). ACM. doi:10.1145/1772690.1772799
Bennara, M., Mrissa, M., & Amghar, Y. (2014). An approach for composing RESTful linked services on the web.
WWW ‘14 Companion Proceedings of the 23rd International Conference on World Wide Web, Seoul, Korea:
(pp. 977-982). New York: ACM. doi:10.1145/2567948.2579222
Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The semantic web. Scientific American, 284(5), 28–37.
doi:10.1038/scientificamerican0501-34 PMID:11323639
Bukhari, A. L., & Liu, X. (2018). A Web service search engine for large-scale Web service discovery based on
the probabilistic topic modeling and clustering. Service Oriented Computing and Applications, 12(2), 169–182.
doi:10.1007/s11761-018-0232-6
Cardoso, J. (2007). Semantic Web services - Theory, tools and applications. IGI Global. doi:10.4018/978-1-
59904-045-5
Cerón-Figueroa, S., López-Yáñez, I., Alhalabi, W., Camacho-Nieto, O., Villuendas-Rey, Y., Aldape-Pérez, M.,
& Yáñez-Márquez, C. (2017). Instance-based ontology matching for e-learning material using an associative
pattern classifier. Computers in Human Behavior, 69, 218–225.
Chinnici, R., Moreau, J.-J., Ryman, A., & Weerawarana, S. (2007). Web Services Description Language (WSDL)
Version 2.0 Part 1: Core Language. W3C. Retrieved from http://www.w3.org/TR/wsdl20/
Christensen, E., Curbera, F., Meredith, G., & Weerawarana, S. (2001). Web Services Description Language
(WSDL) 1.1. W3C. Retrieved from https://www.w3.org/TR/wsdl
Connolly, D. (2007). Gleaning Resource Descriptions from Dialects of Languages (GRDDL). W3C. Retrieved
from http://www.w3.org/TR/grddl/
Dantas, J. R. (2016). An architecture for RESTful web service discovery based on semantic interfaces.
Universidade de Fortaleza, PPGIA.
Dantas, J. R., Lira, H. A., De Azevedo Muniz, B., Nunes, T. M., & Farias, P. P. (2015). Semantic web services
discovery adopting SERIN. Proceedings - 15th IEEE International Conference on Computer and Information
Technology, CIT 2015, Liverpool, UK (pp. 387-394). IEEE. doi:10.1109/CIT/IUCC/DASC/PICOM.2015.55
Dojchinovski, M., & Vitvar, T. (2015). Linked Web APIs Dataset. Semantic Web, 1, 1–5.
Dong, H., Hussain, F. K., & Chang, E. (2013). Semantic Web Service matchmakers: State of the art and challenges.
Concurrency and Computation, 25(7), 961–988. doi:10.1002/cpe.2886
Fang, M. W., Wang, D., Mi, Z., & Obaidat, M. S. (2018). Web service discovery utilizing logical reasoning and
semantic similarity. International Journal of Communication Systems, 31(10), e3561. doi:10.1002/dac.3561
Fellah, A. M., Malki, M., & Elci, A. (2016). A Similarity Measure across Ontologies for Web Services
Discovery. International Journal of Information Technology and Web Engineering, 11(1), 22–43. doi:10.4018/
IJITWE.2016010102
Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. Irvine,
CA: University of California.
Gomadam, K., Ranabahu, A., & Sheth, A. (2010). SA-REST: semantic annotation of Web resources. W3C.
Retrieved from http://www.w3.org/Submission/SA-REST/
Gruber, T. R. (1993). A Translation Approach to Portable Ontology Specification. Knowledge Acquisition, 5(2),
199–220. doi:10.1006/knac.1993.1008

21
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

Hadley, M. (2006). Web Application Description Language (WADL). Oracle Labs. Retrieved from http://labs.
oracle.com/techrep/2006/abstract-153.html
Kaewmarin, V., Arch-int, N., & Arch-int, S. (2008). Semantic Web Service Discovery and Integration Using
Service Search Crawler. Proceedings of the 2008 International Conference on Computational Intelligence for
Modelling Control & Automation, Vienna, Austria (pp. 884-888). Academic Press. doi:10.1109/CIMCA.2008.78
Keller, U., Lara, R., Lausen, H., & Fensel, D. (2007). Semantic Web service discovery in the WSMO framework.
In Semantic Web Services: Theory, Tools and Applications (pp. 281–316). Hershey, PA: IGI Global.
Lathem, J. (2007). SA-REST and (S)mashups: Adding Semantics to RESTful Services. Proceedings of the
IEEE International Conference on Semantic Computing (pp. 469--476). IEEE Press. doi:10.1109/ICSC.2007.94
Lira, H. A. (2015). An Approach to Support Data Integrity for Web Services Using Semantic RESTful Interfaces.
Proceedings of the 24th International Conference on World Wide Web - WWW ‘15 Companion (pp. 1485-1490).
New York, USA: ACM Press. doi:10.1145/2740908.2743042
Lira, H. A., Dantas, J. R., Muniz, B. d., Chaves, L. M., & Farias, P. P. (2014). Semantic data services: An approach
to access and manipulate Linked Data. Proceedings of the 2014 XL Latin American Computing Conference
(CLEI), Montevideo, Uruguay (pp. 1-12). IEEE.
Martin, D., Burstein, M., Mcdermott, D., Mcilraith, S., Paolucci, M., Sycara, K., & Srinivasan, N. et al. (2007).
Bringing Semantics to Web Services with OWL-S. World Wide Web (Bussum), 10(3), 243–277. doi:10.1007/
s11280-007-0033-x
Muniz, B. D., Chaves, L. M., Campos Neto, J. C., Dantas, J. R., & Farias, P. P. (2011). SERIN - Semantic
Restful Interfaces. Proceedings of the IADIS International Conference on WWW/Internet, Rio de Janeiro (pp.
463-467). IADIS Press.
Muniz, B. d., Chaves, L. M., Lira, H. A., Dantas, J. R., & Farias, P. P. (2013). SERIN - An Approach to Specify
Semantic Abstract Interfaces in the Context of Restful Web Services. Proceedings of the IADIS International
Conference on WWW/Internet, Fort Worth, TX (pp. 187--194). IADIS Press.
Nacer, H., & Aissani, D. (2014). Semantic web services: Standards, applications, challenges and solutions.
Journal of Network and Computer Applications, 44, 134–151. doi:10.1016/j.jnca.2014.04.015
Ngan, L. D., & Kanagasabai, R. (2012). Semantic Web service discovery: State-of-the-art and research challenges.
Personal and Ubiquitous Computing, 17(8), 1741–1752. doi:10.1007/s00779-012-0609-z
OASIS. (2005). UDDI Version 3 Specification.
Pakari, S., Kheirkhah, E., & Jalali, M. (2014). Web Service Discovery Methods and Techniques: a Review.
International Journal of Computer Science, Engineering and Information Technology, 1-14.
Paolucci, M., Kawamura, T., Payne, T. R., & Sycara, K. (2002). Semantic Matching of Web Services Capabilities.
In The Semantic Web — ISWC 2002 (pp. 333–347). Berlin: Springer. doi:10.1007/3-540-48005-6_26
Patil, N., & Gopal, A. (2011). Comparative Study of Mechanisms for Web Service Discovery based on
Centralized Approach Focusing on UDDI. International Journal of Computers and Applications, 14(1), 28–31.
doi:10.5120/1809-2328
Pedrinaci, C., Liu, D., Maleshkova, M., Lambert, D., Kopecḱy, J., & Domingue, J. (2010). IServe: A linked
services publishing platform. CEUR Workshop Proceedings, 596, 71–82.
Pedrinaci, C., Panziera, L., & Mier, P. R. (2015). iServe Architecture. iServe. Retrieved from http://kmi.github.
io/iserve/latest/architecture.html
Pedrinaci, C., Panziera, L., & Mier, P. R. (n.d.). Where Linked Data Meets Services. iServe. Retrieved from
http://iserve.kmi.open.ac.uk/
Priyadharshini, G., & Gunasri, R. (2013). A Survey on Semantic Web Service Discovery Methods. International
Journal of Computers and Applications, 82(11), 8–11. doi:10.5120/14158-1759
Programmable Web. (n.d.). Retrieved from https://www.programmableweb.com/
Richardson, L., & Ruby, S. (2008). RESTFul WEb Services. O’Reilly Media Inc.

22
 International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

Roman, D., Kopecký, J., Vitvar, T., Domingue, J., & Fensel, D. (2015). WSMO-Lite and hRESTS: Lightweight
semantic annotations for Web services and RESTful APIs. Journal of Web Semantics, 31, 39–58. doi:10.1016/j.
websem.2014.11.006
Schreiber, G., & Raimond, Y. (2014). RDF 1.1 Primer. W3C. Retrieved from https://www.w3.org/TR/2014/
NOTE-rdf11-primer-20140624/
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. doi:10.1109/MIC.2007.133
Verborgh, R., Steiner, T., Van Deursen, D., Van De Walle, R., & Valles, J. G. (2011). Efficient runtime service
discovery and consumption with hyperlinked RESTdesc. Proceedings of the 2011 7th International Conference
on Next Generation Web Services Practices (pp. 373--379). IEEE. doi:10.1109/NWeSP.2011.6088208
Vitvar, T., Kopeck, J., Viskova, J., & Fensel, D. (2008). WSMO-Lite Annotations for Web Services. Proceedings
of the European Semantic Web Conference (pp. 674--689). Berlin: Springer.
W3C. (2007). Semantic Annotations for WSDL and XML Schema. Retrieved from Recommendation: http://
www.w3.org/TR/sawsdl/
W3C. (2009). OWL 2 Web Ontology Language Document Overview. Retrieved from http://www.w3.org/TR/
owl2-overview
W3C Working Group. (2004). Web Services Architecture. Retrieved from http://www.w3.org/TR/2004/NOTE-
ws-arch-20040211/

23
International Journal on Semantic Web and Information Systems
Volume 16 • Issue 1 • January-March 2020

José Renato Villela Dantas is currently a system analyst at SERPRO, Brazil. He has expertise in business
intelligence, database systems, software engineering, and web development. He has a PhD in Applied Informatics
at University of Fortaleza. His main research areas are ontologies, semantic web services, and machine learning
algorithms.

Pedro Porfírio is currently a Full Professor of the Department of Computer Science at the University of Fortaleza,
Brazil. He received his doctorate in Systems Engineering and computation from the Federal University of Rio de
Janeiro, Brazil in 1998. His main research interests are in agents, logics, ontologies and their use in Software
Engineering and Web information Retrieval. He is member of the Brazilian Computer Society.

24