SERIN SEMANTIC RESTFUL INTERFACES

SERIN – SEMANTIC RESTFUL INTERFACES Bruno de Azevedo Muniz*, Laura M. Chaves*, Júlio Cesar Campos Neto**, José Renato Villela Dantas***, Pedro Porfirio Muniz Farias* *

UNIFOR–Universidade de Fortaleza – Av. Washington Soares, 1321 sala J-30,CEP 60.811-34, Fortaleza, Brazil ** Instituto Atlântico – R. Chico Lemos, 945, Cidade dos Funcionário, CEP 60822-780, Fortaleza, Brazil *** SERPRO – Av. Pontes Vieira, 832, S. J. Tauape, CEP: 60130-240, Fortaleza, Brazil

ABSTRACT This paper presents an approach to specify Semantic interfaces to RESTFul Web Services. Semantic Interfaces are ontologies, written in OWL, that have classes and properties annotated indicating the existence of only five types of RESTFul Web services: (GET, PUT, GET (key), DELETE, POST). The semantics of each type of Web service is fixed using HTTP verbs and, like JAVA interfaces, these services (methods) must be implemented by the agents that commit to the semantic interface. In order to use ontologies as interfaces, this work proposes an addressing convention to the services that permits to locate them knowing the host and the ontology/class used. KEYWORDS Semantic Interfaces, Semantic Web Services, RESTFul Web Services, Ontology, Semantic Web

1. INTRODUCTION In the current Web, which can be viewed as a network of hypertext, a user may access a page without ever has been contacted with the page author. In turn, the author builds his page not considering who may access. Similarly, Web Services must be able to interoperate without author and consumer contact and with no combined format for the exchange messages representation. Interoperability between services, which have not been previously designed to work together, implies the need for their abilities to be formally described and understood by other services. They should communicate the nature of the documents and requests that are exchanged. They should also communicate any side effects associated with the success of the sent request (McIlraith & Martin 2003). A key element for services interoperability is their semantic description in a format capable of being handled automatically by machines. In the Semantic Web proposed architecture, this description can be achieved by the use of ontologies. An ontology is a formal explicit specification of a conceptualization (Gruber 1993). Ontologies written in OWL (Ontology Web Language) (Anon 2009) provide meaning to the data being exchanged over the Internet. Two applications exchange messages in the Semantic Web only if they agree with the messages formal semantics as indicated in the used ontologies. It should be noted that in any computer system, there is always an implied semantic standardization. Or rather a semantic standardization held informally but agreed upon the people who are involved with the system. Web Services next generation need semantic standardization not only explicit and standardized syntax as there is in existing systems nowadays. Semantic Web Services (SWS) can be defined as services whose Web properties, capabilities, interfaces and effects are encoded in a non-ambiguous and likely to be interpreted by machines (S. A McIlraith et al. 2001). A second element traditionally used for interoperability between systems is the use of interfaces. Interfaces have been used successfully as an abstraction to register a syntactic pattern (whose semantics has been established previously and informally) to be followed by systems that exchange information. Basically

interfaces facilitate the division of the multi-layered computer systems, whether internal layers to a single object-oriented program, whether through APIs (Application Programming Interfaces), or distributed processing through IDLs (Interface Description Languages). Interfaces semantics are usually informally communicated through the system documentation, training or through personal communication among those involved with the system. To obtain interoperability in the Semantic Web model, one will define the semantic interface concept as an interface whose semantics will be explicitly expressed using ontologies. In this work it is proposed that a Semantic Web Services implements Semantic Interfaces. 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. In particular, RESTful Web Services described by semantic interfaces will be called Semantic RESTful Web Services. Besides presenting a semantic standardization, SERIN presents standardization to addressing services. The rest of the paper is organized as follows: Section 2 describes semantic Web services; Section 3 introduces SERIN (SEmantic Restful Interface); Section 4 explains how SERIN addresses semantic Web services; and finally, Section 5 presents conclusion and future work.

2. SEMANTIC WEB SERVICES The Semantic Web Service vision (Sheila A. McIlraith & D. L. Martin 2003) 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 services 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. Table 1. Approaches to Semantic Web Services.

Semantic Web Services

Web Services

Annotations in Semantic Service Description

Ontologies for Services

Annotations in Ontologies defining Semantic Interfaces

SOAP/WSDL based

SAWSDL

OWL-S, SWSF WSMO

Active OWL

REST based

SA-REST, SBWS(SA-WADL)

EXPRESS

SERIN

The semantic Web services can be based on two categories of Web services: Web services based on SOAP/WSDL and Web services based on RESTFul. Among the approaches adopted for SOAP/WSDL semantic Web services, there is SAWSDL (Semantic Annotation for WSDL) (Akkiraju & Sapkota 2007). This approach is based on WSDL-S (Web Service Semantics) (Akkiraju et al. 2005). 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 components (Chinnici et al. 2007). Examples of ontologies on services, presented in Table 1, are the following proposals: OWL-S, SWSF and WSMO.

OWL-S (Ankolekar et al. 2004) defines OWL ontology to describe service properties and capabilities of Web services. The ontology defines the a service concept and three subontologies OWL-S, 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 (S. Battle et al. 2005a), 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) (S. Battle et al. 2005b), and a language for axiomatization called Semantic Web Service Language (SWSL) (Battle et al., 2005c). 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” (Bruijn et al. 2005). Third strategy presented in Table 1 is an annotation indicating which ontology concepts are related to a Web Service. Active OWL (Campos Neto 2007) (Marques et al. 2008) 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 was 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. In table 1, SA-REST and SBWS are proposals for semantic Web services strategy to semantically annotate services description. SA-REST proposal (Lathem et al. 2007) was created for adding semantics to RESTFul services, borrowing the SAWSDL idea. The fundamental difference between SAWSDL and SA-REST is that in SAWSDL semantic annotations will be 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 (Adida & Birbeck 2008) and Gleaning Resource Descriptions from Dialects of Languages (Connolly 2007). In this proposal, when a system performs a search with predefined criteria for a resource, it can not 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 R. Battle & Benson (2008) to associate semantics to RESTFul Web services. SBWS makes annotation on documents WADL, like the SAWSDL, connecting REST input and output methods to ontologies. The EXPRESS (RESTFul Expressing Semantic Services) proposal (Alowisheq & Millard 2009) 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 a consistent operational semantics about all the features of Web 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 written in 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.

3. SEMANTIC RESTIFUL INTERFACES - SERIN 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 (Campos Neto 2007) (Marques et al. 2008) 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 Web services five types 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. SERIN does not claim to specify the semantics of any Web services. It is restricted only to the mentioned five types of Web services. This restriction makes it suitable for use with RESTFul Web services that are also based on the HTTP methods. In addition, if you restrict the HTTP methods, SERIN becomes a lot easier than the other proposals as, since methods semantics are established, it is necessary only to establish the arguments semantics and the resulting value. In OWL, annotations are defined through Annotation Properties. Listing 1 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. Listing 1. Excerpt from SERINAnnotations Ontology.



3.1 SERIN annotations for classes and properties The annotations syntax is specified by ontology SERINAnnotations and through it, each of the five annotations received a URI that uniquely, identifies them. To be formally used, the meaning, i.e., the semantics of each entry must first be informally defined and this definition must be known to everyone involved. 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. The five annotation significance is based on the use of the HTTP methods that are already widespread. Classes and properties can receive annotations. Each entry indicates the existence of a RESTFul Web service URL and whose semantics are presented in Table 3 and Table 4. In both Table 3 and Table 4, the identifier represents the host URL that implements ontology. identifier is the URI that identifies the ontology. The identifiers and , respectively, represent the annotated class and annotated property.

Table 2. Notes on classes indicating the existence of Web Services, its location (URL) and Semantics.

Post

URL Semantics URL Semantics URL Semantics

Put

URL Semantics

Delete

URL Semantics

Get List

GET /serin/// Receives a identifier as a parameter and returns the its individual GET /serin// Receives, as a parameter, an OWL corresponding to the individual identified by and updates the individual information DELETE /serin/// Receives, as parameters, an individual identifier and removes this individual from the class individuals set

Table 3. Properties notes indicating the existence of Web services, its location (URL) and Semantics.

Get

List Post Put Delete

URL Semantics

URL Semantics URL Semantics URL Semantics URL Semantics

GET /serin//// Receives as parameters the individual identifier and returns the property value for the respective individual . The annotation “get” is only defined for functional properties GET /serin/// List the values associated with property POST /serin///// Assigns a new value to property PUT /serin/////< value > Updates the property value DELETE /serin/////< value > Delete the value associated with property

Note that list and get two notes are associated with the HTTP GET method. This option was adopted because the HTTP semantics and have different results, depending on whether or not the use of parameters. 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. Notes do not apply to anonymous classes or built up from expressions. Annotations are not inherited, that is, a child class to specify its own Web services that is not inherited from the father. In the current specification fails in the execution of Web services should be treated by the application. A natural extension of the current specification would be the treatment of such failures.

4. SEMANTIC WEB SERVICE ADDRESSING 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 address constituted under the proposed Convention refers to a WSDL file that describes the service (Campos Neto 2007). 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 2. The variable part corresponds to the URL of each agent

while the fixed part, which remains the same for all agents that implement the same Web service, is made from the URI of the ontology and the class name < class name>. Listing 2. Grammar for specifying the URL of each Web service in interface semantics.