Semantic Interfaces Discovery Server
Laura Maria Chaves José Renato Villela Dantas
PPGIA - University of Fortaleza
Fortaleza, CE, Brazil
lauramariachaves@gmail.com
Bruno de Azevedo Muniz
PPGIA -University of Fortaleza
Fortaleza, CE, Brazil
brunoamuniz@gmail.com
Pedro Porfírio Muniz Farias
PPGIA-University of Fortaleza; ARCE
Fortaleza, CE, Brazil
porfirio@unifor.br
Abstract – This paper presents an architecture for a SERIN
(SEmantic RESTful INterface) Discovery Server. SERIN is a
semantic interface specification for RESTful Web Services that
includes an addressing standard to the Web services. This
standard permits the SERIN Discovery Server to use a web
crawler to find which hosts implement a specific semantic
interface. The presented architecture provides a greater degree of
scalability than current known UDDI servers because it is based
on semantic interfaces, does not require Web service developers
register their services on the server and also presents a semantic
interface for software agents to run automated queries on the
server.
Keywords – Semantic Web, RESTful Web service, ontology,
semantic interface service discovery, SERIN, semantic interface.
I. INTRODUCTION
Interfaces have been used successfully for interoperability
between systems as an abstraction to register a syntactic
pattern to be followed by systems that exchange information.
Basically interfaces facilitate the division of the multi-layered
computer systems, like the division of internal layers in a
single object-oriented program, or like division of layers
through APIs (Application Programming Interfaces), or
distributed processing through IDLs (Interface Description
Languages).
Usually, the semantic of each interface is informally
communicated through the system documentation, training or
personal communication among those involved with the
system.
To obtain interoperability in the Semantic Web model, the
semantic interface will be defined as an interface whose
semantics will be explicitly expressed using ontologies.
In this work SEmantic RESTful INterfaces (SERIN) will
be used to specify semantic interfaces. Each host that
implements the semantics should implement the methods
recommended in the interface.
SERPRO– Federal Data Processing Service
Fortaleza, CE, Brazil
jose.dantas@serpro.gov.br
Júlio Cesar Campos Neto
Instituto Atlântico
Fortaleza, CE, Brazil
julioccn@gmail.com
RESTful Web Services described by semantic interfaces
will be called Semantic RESTful Web Services.
Besides presenting a semantic standardization, SERIN also
presents a standardization of addressing services, thus it makes
it possible for a web crawler to find the hosts that implement a
Semantic RESTful Interface.
This paper presents Architecture for a SERIN (SEmantic
RESTful INterface) Discovery Server that:
• is designed to be used, mainly, by software agents;
• is designed to use semantic interfaces;
• is based on an automatically constructed index.
The difficulty of finding the requested web service on the
Web inevitably remains one of the main motivations of the
Semantic Web vision.
Agent creators need to adopt semantic standards in order to
allow the exchange of messages between them. Semantic Web
Services discovery consists in automating service requests
made by a user or machine on the Internet. Several proposals
have been presented for Semantic Web Services discovery
based on the UDDI (Universal Description Discovery and
Integration) server [10]. To discover a Web service in the
UDDI server, it is necessary that web services developers
explicitly register their services on the UDDI server. This
requirement creates a scalability problem.
In addition, UDDI servers, normally, are searched by
people that read the descriptions published and select the
appropriated services that match with their needs, also, the
UDDI servers, originally, are not prepared to work with
Semantic Web standards.
UDDI servers typically are used to publish WSDL (Web
Services Description Language) [21]. WSDL files encapsulate
both abstract interface and connection to a particular web
service in a single specification. There are no known cases
using a UDDI server to publish only web services abstract
interfaces. The use of UDDI server to publish RESTful Web
Service Descriptions is also unknown.
 Table I. Approaches to Semantic Web Services
Semantic Web Services
Annotations in
Web Services Semantic Service Ontologies for Services
Description
OWL-S, SWSF
SOAP/WSDL based WSDL-S, SAWSDL
WSMO
SA-REST, SBWS(SA-
REST based EXPRESS, MicroWSMO
WADL)
In order to minimize these problems, this work will
propose a RESTful semantic web service discovery server.
The rest of the paper is organized as follows: Section 2
presents proposals for assigning semantics to Web services;
Section 3 discusses semantic web services discovery;
Section 4 introduces SERIN – SEmantic RESTful INterface;
Section 5 shows SERIN Discovery Server architecture;
Section 6 presents a Semantic Interface for SERIN
Discovery Server; and Section 7 presents our conclusion
and future work.
II. SEMANTIC WEB SERVICES
The Semantic Web Service vision [9] is to combine web
services with Semantic Web and thereby allow an automatic
and dynamic interaction between information systems.
Semantic Web Services intend to use the previously
established semantic concepts of an ontology linking them
to Web Services components. As shown in Table 1, three
strategies are used alternatively to perform this mapping:
• Annotate service descriptions by making them
point to ontologies;
• Annotate domain ontologies indicating which Web
services exist regarding a given ontology; and
• Create a new specification, independent of the first
two. This new specification is usually a meta-
ontology that describes the services.
Semantic Web Services can be based on two categories
of Web Services: Web Services based on SOAP/WSDL and
Web Services based on RESTful. The RESTful web
services are stateless and uses only the HTTP methods
(GET,PUT,POST,DELETE) to access resources identified
by URIs.
A. Semantic Web Services based on SOAP/WSDL
Among the approaches adopted for SOAP/WSDL
Semantic Web Services, there is SAWSDL (Semantic
Annotation for WSDL) [14]. This approach is based on
WSDL-S (Web Service Semantics) [20]. It follows the
strategy to create a semantic annotation for service
description. To do so, it defines three attributes to WSDL
2.0 extensibility elements: modelReference,
liftingSchemaMapping and loweringSchemaMappping that
allow semantic annotations on WSDL (Web Services
Description Language) components [21].
Annotations in domain Ontologies defining Semantic
Interfaces
Active OWL
SERIN
Examples of ontologies on services, presented in Table
I, are the following proposals: OWL-S, SWSF and WSMO.
OWL-S [11] defines an OWL (Ontology Web
Language) ontology to describe service properties and
capabilities of web services. The OWL-S ontology defines
the service concept and three subontologies, known as
service profile, which describes, “what the service does”,
service model, which tells the customer how to use the
service, and service grounding, which specifies the details
of how an agent can access a service.
Semantic Web Services Framework, SWSF [15], has its
roots in the OWL-S standard. It is composed of an ontology,
which provides a conceptual model to describe Web
services called Semantic Web Services Ontology (SWSO)
[17], and a language for axiomatization called Semantic
Web Service Language (SWSL) [16]. This language is more
powerful than OWL.
Web Services Modeling Ontology (WSMO) “aims to
describe all relevant aspects related to services that are
accessible through a Web service interface. Its main
objective is to enable task automation (total or partial), e.g.
discovery, selection, composition, mediation, execution, and
monitoring” [19].
The Third strategy presented in Table I is an annotation
indicating which ontology concepts are related to a web
service. Active OWL [4] [8] proposes to use ontologies as
interfaces. It suggests the restriction to allow only web
services (GET, PUT, LIST, DELETE, and POST). Thus,
although it was originally proposed for SOAP/WSDL
Semantic Web Services (SWS), OWL Active approaches a
SWS-REST specification.
Active OWL uses the strategy of associating Web
services with ontologies by annotating classes and
properties. These annotations indicate the existence of Web
services types. Thus, the annotations specify a semantic
interface to the five Web services types. Annotations are
defined in OWL using Annotation Properties.
B. Semantic Web Services based on REST
In Table I, SA-REST and SBWS are proposals for
semantic Web services strategy to semantically annotate
services descriptions.
The SA-REST [7] proposal was created for adding
semantics to RESTful services, borrowing the SAWSDL
idea. The fundamental difference between SAWSDL and
SA-REST is that SAWSDL semantic annotations are added
in the WSDL (which are not normally adopted for RESTful
Web Services). The SA-REST annotations will be added to
Web pages, describing the services through the use of micro
formats such as RDFa [13] and Gleaning Resource
Descriptions from Dialects of Languages [6].
In this proposal, when a system performs a search with
predefined criteria for a resource, it cannot know the page
address where the searched information semantics is. Thus,
the provider would have to somehow provide the page
address where the semantics reside so the applicant can
access it. Otherwise, the applicant should have a scanner to
read every provider page in order to find the predicates
above.
SBWS (Semantic Bridge for Web Services) is also
proposed by [3] to associate semantics to RESTful Web
services. SBWS makes annotation on documents WADL,
like the SAWSDL, connecting REST input and output
methods to ontologies.
EXPRESS (RESTful Expressing Semantic Services)
proposal [2] describes RESTful Web Services using domain
ontologies that include descriptions of the features
(following a format OWL/EXPRESS). From these
descriptions, it generates stubs for access to available
services.
This process starts when a service provider describes the
entities and their relationships as ontology (as an OWL file).
Using the OWL file, a deployment mechanism EXPRESS
(EXPRESS Deployment Machine) generates a list of URIs
that identify resources, related classes, instances and
properties. The service provider then specifies which HTTP
methods can be applied to these features (though there is
information on how this specification is performed).
The authors state that the use of HTTP methods (GET,
PUT, DELETE, POST, and OPTIONS) is sufficient to
define consistent operational semantics about all the features
of web services.
MicroWSMO [22] consists of service ontology for
RESTful Web services, and a method for annotating
descriptions of RESTful services.
SERIN is an Active OWL adaptation for Semantic Web
Services and REST. It fits the strategy of specifying
semantic interface via annotations on ontologies.
The semantic interface is represented by OWL
ontologies with annotations that indicate how the five types
of web services (GET, PUT, LIST, DELETE, POST) are
mapped in the four HTTP methods (GET, PUT, DELETE,
POST).
This approach proposes a convention for URLs that
address the RESTful semantic Web services dividing them
into two components: the host and the semantic interface.
Each host that implements a semantic interface is
responsible for implementing RESTful Web Services
associated with it. This convention permits discover which
host implements a interface, so is possible to construct the
SERIN discovery server proposed in this paper.
III. SEMANTIC WEB SERVICE DISCOVERY
The semantic web services discovery is the process of
finding technical means to access service providers with
relevant capabilities, based on semantic annotation. This
finding has to be fully automated, since there are no people
involved in the process that could help agents in the trial to
determine if the service is relevant or not. For this purpose,
all parts involved in the semantic annotation has to be
understandable by machines, so the agent can put them
together neatly for correct conclusions. To achieve this goal,
semantic web service discovery explores expressive
formalization of knowledge representation and sophisticated
techniques of automated reasoning [18].
Among the first, and possibly most influential works on
semantic Web services discovery, [12] was limited to
semantically annotating web services inputs and outputs. In
this approach, "a publishing matches a request when all
publishing inputs and outputs match with request inputs and
outputs."
Paulocci´s criterion only allows an approximate match.
The "Degree of Match" (DoM) concept can be introduced as
an attempt to deal with these problems [5]. DoM can be
informally defined as a value from an ordered set of values
that express how similar two entities are, considering some
similarity metric. Such entities may be services, IOPE
attributes (Input, Output, Preconditions, Effects), or a
specific service operation. A matching algorithm service
that calculates DoM can thus be used to classify discovered
services according to their relevance to the request.
Semantic pattern matching algorithms are usually
complex. They operate by considering that requests from
publications and services are not in perfect combination.
They are designed to explore semantic functionality explicit
description and service request. Algorithms have been
offered with different features, suggesting different
architecture types, for example peer-to-peer.
Reference [5] considers that the use of these domain
ontologies by both service provider and service requestor,
though not necessary, significantly simplifies the process of
semantic pattern matching by eliminating the need for
mediation layers. However, this is an optimistic scenario,
not suitable for open information environments, such as the
Web.
Therefore, if the same domain ontology is not used for
both provider and requestor, considering the approximate
character of the matching, a rough mediation layer should be
introduced.
The complexity of these approaches is a result of its
heavy reliance on reasoning for pattern discovery and
matching. This complexity also means that the approaches
would not work properly on web-scale, which is a key
requirement for Web Services [1].
 In the SERIN Discovery Server, services published and
requested follow the same interface, i.e. the matching is
always accurate in order to avoid the need for complex
pattern matching. This proposal allows a scalable solution.
IV. SERIN – SEMANTIC RESTFUL INTERFACE
The REST standard states that resource orientation and
the use of HTTP methods are the only operations available.
Semantic RESTful Interfaces (SERIN) is basically
annotated ontology whose classes and properties
characterize uniquely and semantically available resources.
Annotations indicate which RESTful Web Services should
be implemented for each resource.
SERIN is based on an earlier specification called Active
OWL [8] that applies to Web Services SOAP/WSDL.
The strategy used in SERIN to associate web services
with ontologies was to annotate classes and properties of an
ontology written in OWL through five notes, indicating the
existence of five types of Web services: “get”, “post”,
“delete”, “put”, and “list”.
The five types of web services are mapped in the four
HTTP methods. The types “get” and “list” will both be
mapped to the GET method. The “get” type requires a key
as a parameter indicating a single instance to be recovered,
while the “list” type has no parameters and returns a list of
all class instances. This restriction makes it suitable for use
with RESTful Web Services that, normaly, are also based on
the HTTP methods.
<owl:AnnotationProperty
rdf:about="http://www.unifor.br/
serinAnnotations.owl#delete"/>
<owl:AnnotationProperty
rdf:about="http://www.unifor.br/
serinAnnotations.owl#post"/>
<owl:AnnotationProperty
rdf:about="http://www.unifor.br/
serinAnnotations.owl#get"/>
<owl:AnnotationProperty
rdf:about="http://www.unifor.br/
serinAnnotations.owl#put"/>
<owl:AnnotationProperty
rdf:about="http://www.unifor.br/
serinAnnotations.owl#list"/>
Listing I. Excerpt from SERIN Annotations Ontology.
In OWL, annotations are defined through Annotation
Properties. Listing I shows the definitions of annotations
used. To avoid repetition of annotations in an interface, we
define the SERINAnnotations ontology to package the
required settings. SERINAnnotations ontology can be
imported to each RESTful semantic interface.
A. SERIN annotations for classes and properties
The annotations syntax is specified by an ontology of
SERINAnnotations and through it, each of the five
annotations received a URI that uniquely, identifies it. To be
formally used, the meaning, i.e., the semantics of each entry
must first be informally defined and everyone involved must
know this definition.
The option to use only five web service types makes
SERIN semantics much simpler than the proposals based on
SOAP/WSDL Web services, which apply to any Web
service. Since the semantics of resources are properly
established by the semantic interface, it remains only to
clarify the semantics of annotations used.
Each annotation indicates the existence of a RESTful
Web service URL whose semantics are presented in Table II
and Table III.
In both Table II and Table III, the identifier <host>
represents the host URL that implements the ontology.
<Ont> identifier is the URI that identifies the ontology. The
identifiers <class> and <prop>, respectively, represent the
annotated class and annotated property.
Note that “list” and “get”, two notes are associated with
the HTTP GET method. This option was adopted because
the HTTP GET has different results, depending on whether
or not parameters are used. When used without parameters
the GET method returns a list of individuals and when used
with an identifier as a parameter the GET method returns
only the single individual identified by the parameter
reported.
The media-type “application/owl+xml” is used to
represent arguments and results.
Annotations cannot be applied to anonymous classes or
classes built from expressions. Annotations are not
inherited, that is, a child class must specify its own Web
services, which will not be inherited from the parent class.
On the current specification, execution errors on Web
services should be treated by the application. An expected
extension for the current specification would be the
treatment of such errors.
Table II Annotations on classes indicating existence of a Web Service,
its location (URL) and its Semantics.
URL GET <host>/serin/<Ont>/<Class>/<rdf:id>
Get Receives a <rdf:id> identifier as a parameter
Semantics
and returns the its individual
URL GET <host>/serin/<Ont>/<Class
List
Semantics List the individuals in a Class
POST
URL
<host>/serin/<Ont>/<Class>/<individual>
Post Receives as parameter the XML
Semantics corresponding to the individual and it adds to
the class individuals set
PUT
URL <host>/serin/<Ont>/<Class>/<rdf:id>/<indivi
dual>
Put Receives, as a parameter, an OWL
corresponding to the individual identified by
Semantics
<rdf:id> and updates the individual
information
DELETE
URL
<host>/serin/<Ont>/<Class>/<rdf:id>
Delete Receives, as parameters, an individual
Semantics identifier and removes this individual from
the class individuals set

Table III. Property notes indicating the existence of Web services, its
location (URL) and Semantics.
GET
URL
<host>/serin/<Ont>/<Class>/<rdf:id>/<prop>
Get Receives as parameters the individual identifier
<rdf:id> and returns the property value for the
Semantics
respective individual <prop>. The annotation
“get” is only defined for functional properties
URL GET <host>/serin/<Ont>/<Class>/<prop>
List
Semantics List the values associated with property <prop>
POST
URL <host>/serin/<Ont>/<Class>/<rdf:id>/<prop>/
Post <value>
Assigns a new value <value> to property
Semantics
<prop>
PUT
URL <host>/serin/<Ont>/<Class>/<rdf:id>/<prop>/
Put <value>
Semantics Updates the property <prop> value <value>
DELETE
URL <host>/serin/<Ont>/<Class>/<rdf:id>/<prop>/
Delete <value>
Delete the value <value> associated with
Semantics
property <prop>
B. Semantic Web Service addressing
Figure 1 shows an example in which a personal agent
performs a query on a group of car rental agents. The car
rental agents implement their web services in each of the
hosts of the rental agencies, which are www.rentalA.com,
www.rentalB.com and www.rentalC.com. The three hosts
implement the same semantic interface, called serin/vehicle.
Thus, running the Web service www.rentalA.com
/serin/Vehicle.owl/availableModel produces vehicle models
available in rentalA, while the other two Web services
should, respectively, provide models of vehicles available in
rentalB and rentalC.
Figure 1. Using Semantic Interfaces RESTful.
Thus, each car rental agent has a RESTful Web service
class corresponding to available Model. The personal agent
may trigger the GET Web service in each of the
implementations obtained in each case, from the list of
models available for that store.
The convention used is particularly simple when applied
to RESTful Web Services, however, you can apply it to
traditional Web services. In the case of architecture SOAP /
WSDL, the address constituted under the proposed standard
convention refers to a URL of a WSDL file that describes
the service [12].
Semantic interfaces are similar to interfaces in OOP
(Object Oriented Programming). Each agent who accepts a
semantic interface is responsible for implementing its
methods.
For each agent, the address (URL) RESTful semantic
Web service consists of a variable and a fixed part of the
grammar as shown in Table II. The variable part
corresponds to the URL of each agent <host > URL while
the fixed part, which remains the same for all agents that
implement the same Semantic Interface, is derived from the
URI of the ontology <Ont uri> and the class name <Class >.
<host URL> = “www.rentalAgencyC.com”
<ontology URI> = “serin/Vehicle.owl”
<class name> = “available Model”
<interface URI> = “/ontologies/serin/Vehicle.owl/
availableModel”
<service URL> = “www.rentalAgencyC.com/ontologies
/serin/Vehicle.owl/availableModel”
Listing II. URL sample of a RESTful Web Service that implements a
Semantic Interface
Listing II is presented, as would be the URL of the Web
service implemented for the agent rentalC in Figure 1.
V. SERIN DISCOVERY SERVER ARCHITECTURE
The SERIN Discovery Server is a centralized index,
which works on architecture composed of four components,
as shown in Figure 2:
• A scanning module – a crawler that scans the Web
content, updating;
• A repository of indexes (that maps Semantic
interfaces to hosts);
• A manual query module - a site where users query
the index;
• An automatic query module - semantic Web
services which automatic agents query the index.
The scanning module inspects each web host known to
identify semantic interfaces that each host implements. The
scanning module must also update the list of known hosts
and the list of known semantic interfaces. Information
obtained by the scanning module, alternatively, can be
manually published by those responsible for a host by
developers of a semantic interface who wish their site or
their interface becomes part of the index.
 The manual query module should basically allow a user These two classes design follow the Ontological
to query the hosts that implements a given interface. In Minimum requirements principle. An Ontology class has
addition, manual module queries could offer multiple only two attributes (as data type properties) ontologyId and
queries of interest to designers and users wishing to build ontologyDescriptionFile. While the class Host has only one
new interfaces or specify agents. For example, which data type property called hostId.
interfaces are registered, and which interfaces are
implemented by each host. The ontology has appropriate annotations with the Web
services that the SERIN Discovery Server must implement.
The automated query module, mainly, responds to the Table IV presents the respective URL and semantics for
software agents which hosts implement certain interface. each of the four methods.
The Software agents that will consult the automated query
module must use a semantic interface that will be presented Table IV. SERIN Discovery Server Web Service description.
in section VI.
Method GET
The repository stores the index of hosts and the index of <host>/serin/SerinSea
semantic interfaces(SI) as well as the known relationships rch/Ontology/
isImplementedBy URL <OntId>/isImplemented
among them. <list> By
Semantics Set of hosts that implement a
specific semantic interface .
Method GET
<host>/serin/SerinSea
URL rch/Ontology/<HostId>
/implementsOntology
Returns the interfaces that a
Semantics
host implements.
Method POST
implementsOntology <host>/serin/SerinSea
<list,post> rch/Ontology/<HostId>
URL /implementsOntology/<
Ont id>
Returns in which the host
implements a specific interface.
Semantics The discovery server confirms
this information by host direct
inspection.
Method GET
<host>/serin/SerinSea
Figure 2. SERIN Discovery Server Architecture. URL rch/Ontology/<Ont Id>
Ontology
<get> Returns an ontology class
VI. SERIN DISCOVERY SERVER SEMANTIC Semantics instance including its
description file.
INTERFACE

Consultations at the SERIN Discovery Server will be
done by implementing the semantic interface called
SerinSearch shown in Figure 3. SerinSearch interface has
two classes: the class Host and the class Ontology that are
connected by two properties implementsOntology and
isImplementedBy (inverse property).
A. SERIN Discovery Server automatic search
The sequence diagram in Figure 4 describes an
automated search at the SERIN Discovery Server and a
following query to hosts that implement an interface called
semantic Ont1.

Figure 3. SERIN Search Semantic interface for consultation at the SERIN

Discovery Service
Figure 4. SERIN Discovery Server automatic query sequence
diagram.
 The user agent wants to find hosts that implement the
semantic interface Ont1. It sends a query as a GET URL
www.busca.com/serin/SerinSearch/Ontology/Ont1/isImple
mentedBy to the SERIN Discovery Server. The server
returns the list {hostAId, hostBId}, which contains the
identifiers of the two hosts that implement Ont1 ontology.
First, the user agent will consult HostA. The agent sends
a GET request through the URI
www.hostA.com/serin/Ont1/Classe1. HostA receives the
GET request, which contains the resource related to Class1.
It performs a query in its database. Finally it sends back a
list with all individuals in Class1.
After, sending a request to HostB performs the same
query.
(Ont1Id). The server receives a negative answer about the
existence of interface Ont1 in the repository.
The server asks the discovery HostA about the Ont1
interface description. It receives a description file as an
answer. Then, it includes the semantic interface Ont1 in the
index repository. Finally, the method
insertIsImplementedBy updates the index repository
indicating, through their respective parameters, that hostAId
implements the semantic interface Ont1Id.

B. Index updating at SERIN Discovery Server

The scanning module can make its scan by direct

inspection or by asking the host about which semantic
interfaces it implements.
The sequence diagram in Figure 5 shows an example of
scanning the hosts and updating of indexes in the SERIN
Discovery Server. This service intends to search for
semantic interfaces that exist in these hosts. With this,
SERIN server will update the index database repository.
This database will have a list of found semantic interfaces,
as well as the relationship of semantic interfaces with each
host.
The discovery server performs the following steps at the
hostA.
The discovery server sends a GET request, represented
by the URL www.hostA.com/serin/ to determine which
semantic interfaces that HostA has. The HostA response
indicates that it implements the semantic interface Ont1.
Discovery server searches the semantic interface Ont1 at
the index repository using the method hasOntology
(Ont1Id). The server receives a negative answer about the
existence of interface Ont1 in the repository.
Figure 5. Semantic interface discovery at various hosts sequence diagram
The server asks the discovery HostA about the Ont1
interface description. It receives a description file as an For HostB, steps six to eleven are executed. In step six,
answer. Then, it includes the semantic interface Ont1 in the it identifies that HostB implements two semantic interfaces:
index repository. Finally, the method Ont1 (which already exists in the index repository) and Ont2
insertIsImplementedBy updates the index repository (to be included in the index repository).
indicating, through their respective parameters, that hostAId
implements the semantic interface Ont1Id. VII. CONCLUSION
For HostB, steps six to eleven are executed. In step six, The first SERIN (Semantic RESTful Interface)
it identifies that HostB implements two semantic interfaces: contribution is to utilize semantic interface concepts on the
Ont1 (which already exists in the index repository) and Ont2 context of Web services.
(to be included in the index repository).
The interface concept is traditionally used to provide
The discovery server sends a GET request, represented interoperability at various levels of computing, whether in-
by the URL www.hostA.com/serin/ to determine which house programs, at API level, or in distributed computing
semantic interfaces that HostA has. The HostA response models. Semantic Interfaces fit the concept of interface
indicates that it implements the semantic interface Ont1. technologies related to the Semantic Web and, in particular,
Discovery server searches the semantic interface Ont1 at RESTful Web Services.
the index repository using the method hasOntology
 Following the REST approach, SERIN uses only five
service types that follow HTTP methods semantics.
In addition to semantic standardization, a second SERIN
contribution is to standardize service URLs.
This work presented how address standardization
adopted in SERIN may be used to discover semantic Web
services. Such discovery can be performed in three ways,
namely, by direct inspection, by consultation at a centralized
index, and by broadcasting a P2P network.
In particular, architecture for a SERIN Discovery Server
was designed. This work presented its functionalities. It also
indicates a semantic interface to RESTful web services
through which the server can be accessed by programs.
In order to accelerate the discovery, SERIN architecture
standardized two Web Services to be implemented by each
host that implements a semantic interface. Through the first
service, the host responds to the interface it implements. The
second service answers a file that describes each interface.
The main distinction this server presents is the fact that
is not necessary for suppliers to register their services (like
UDDI server does). In contrast, the index server is powered
primarily by a crawler that scours the Web to identify hosts
that implement each semantic interface.
This innovative feature, which arises from the use
semantic interfaces concept, has a great impact on the
scalability of the index server. In this respect, the difference
between an UDDI server and a SERIN Discovery Server is
similar to the difference between a server based on
automatically constructed indexs, such as Google, and the
former service offered by Yahoo, which depended on the
initiative of the developers to register each Web page on the
server.
Besides a SERIN Discovery Server is designed to use
semantic interfaces, while a UDDI server usually publishes
WSDL files having interface specification and
implementation in the same package.
Finally, a SERIN Discovery Server is designed to be
used by software agents, while the UDDI by people who,
after consulting the specifications would be able to build
programs to access the services described.
In future work, we will emphasize mainly the actual
construction of the proposed server, whose success depends
on the spread of semantic interface SERIN. In addition, we
also propose the study of mechanisms for ontologies and
interfaces evolution.
The annotations in SERIN can be extended to specify
non-functional aspects of web services, for example, quality
of service and security.
REFERENCES
[1] Alowisheq, A. e Millard, D.E. 2009. EXPRESS: EXPressing RESTful
Semantic Services. Web Intelligence and Intelligent Agent
Technology, IEEE/WIC/ACM International Conference on. 3, (2009),
453-456.
[2] Alowisheq, A. et al. 2009. EXPRESS: EXPressing RESTful Semantic
Services Using Domain Ontologies. ISWC ’09: Proceedings of the
8th International Semantic Web Conference (Berlin, Heidelberg,
2009), 941–948.
[3] Battle, R. e Benson, E. 2008. Bridging the semantic Web and Web 2.0
with Representational State Transfer (REST). Web Semantics:
Science, Services and Agents on the World Wide Web. 6, 1 (2008),
61 - 69.
[4] Campos Neto, J.C. 2007. Active OWL - Uma arquitetura para integrar
serviços Web e ontologias. Universidade de Fortaleza (UNIFOR).
[5] Cardoso, J. 2007. Semantic Web services : theory, tools and
applications. Information Science Reference.
[6] Gleaning Resource Descriptions from Dialects of Languages
(GRDDL): 2007. http://www.w3.org/TR/grddl/. Accessed: 2011-06-
10.
[7] Lathem, J.D. et al. 2007. SA-REST: BRING THE POWER OF
SEMANTICS TO REST-BASED WEB SERVICES Electronic
Version Approved:
[8] Marques, T.C. et al. 2008. Active Ontologies - an Approach for Using
Ontologies as Semantic Web Services Interfaces. SEKE’08 (2008),
847-852.
[9] McIlraith, S.A. e Martin, D.L. 2003. Bringing Semantics to Web
Services. IEEE Intelligent Systems. 18, (2003), 90-93.
[10] OASIS UDDI Specification TC | OASIS: 2005. http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=uddi-spec. Accessed:
2011-07-13.
[11] OWL-S’ Relationship to Selected Other Technologies: 2004.
http://www.w3.org/Submission/2004/SUBM-OWL-S-related-
20041122/. Accessed: 2010-05-06.
[12] Paolucci, M. et al. 2002. Semantic Matching of Web Services
Capabilities. The Semantic Web — ISWC 2002. I. Horrocks e J.
Hendler, orgs. Springer Berlin / Heidelberg. 333-347.
[13] RDFa Primer: 2008. http://www.w3.org/TR/xhtml-rdfa-primer/.
Accessed: 2011-06-10.
[14] Semantic Annotations for WSDL and XML Schema — Usage Guide:
2007. http://www.w3.org/TR/sawsdl-guide/. Accessed: 2011-06-07.
[15] Semantic Web Services Framework (SWSF) Overview: 2005.
http://www.w3.org/Submission/SWSF/. Accessed: 2010-05-06.
[16] Semantic Web Services Language (SWSL): 2005.
http://www.w3.org/Submission/SWSF-SWSL/. Accessed: 2011-06-
13.
[17] Semantic Web Services Ontology (SWSO): 2005.
http://www.w3.org/Submission/SWSF-SWSO/. Accessed: 2011-06-
13.
[18] Studer, R. 2007. Semantic web services : concepts, technologies, and
applications. Springer.
[19] Web Service Modeling Ontology (WSMO): 2005.
http://www.w3.org/Submission/WSMO/. Accessed: 2010-05-08.
[20] Web Service Semantics - WSDL-S: 2005.
http://www.w3.org/Submission/WSDL-S/. Accessed: 2010-05-06.
[21] Web Services Description Language (WSDL) Version 2.0 Part 1:
Core Language: 2007. http://www.w3.org/TR/2007/REC-wsdl20-
20070626/. Accessed: 2010-04-29.
[22] MicroWSMO: 2008. http://www.wsmo.org/TR/d38/v0.1/. Accessed:
2011-12-09.