Mastering Structured Data on the Semantic Web From HTML5 Microdata to Linked Open Data(2015)

CHAPTER 5 Semantic Web Services

In this service-oriented world, online services are important parts of web offerings. Online shopping, flight booking, hotel booking, navigation, public transport services, government services, community services, and media services are parts of our daily lives. However, the range of service offerings is widening. In the information technology (IT) industry, for example, there is also an endless variety of services. In the more and more popular cloud computing environments, the fundamental service models are Infrastructure as a Service (IaaS), such as Amazon EC2 and Google Cloud Storage; Platform as a Service (PaaS), such as WHM, Microsoft Azure, and the Google App Engine; and Software as a Service (SaaS), such as Hosted Exchange, GoogleApps, and NetSuite. Further services in the IT industry contain, but are not limited to, Database as a Service (DBaaS), Graph as a Service (GaaS), Storage as a Service (STaaS), Test Environment as a Service (TEaaS), API as a Service (APIaaS), Network as a Service (NaaS), and Unified Communications as a Service (UCaaS). Web services often have web sites that provide e-commerce, navigation with dynamic maps, remote control of a physical device, and so on. The mainstream XML-based standards for web service interoperability specify the syntax only, rather than the semantic meaning of messages. Semantic Web technologies can enhance service-oriented environments with well-defined, rich semantics. Semantic Web services leverage Semantic Web technologies to automate services and enable automatic service discovery, composition, and execution across heterogeneous users and domains.

Semantic Web Service Modeling

Web services are programs programmatically accessible over standard Internet protocols, using reusable components [1]. Web services are distributed and encapsulate discrete functionality. Semantic Web Services (SWS) make web service characteristics machine-interpretable via semantics. Semantic Web Services aim to combine web services and Semantic Web technologies with the aim of automating service-related tasks, such as discovery, composition, etc. [2]. Semantic Web Services can address some of the limitations of conventional web services, such as syntactic descriptions and the need for manual inspection of web service usability, usage, and integration. The life cycle of Semantic Web Services includes the service description or annotation, the advertisement, the discovery, the selection, the composition, and the execution of services, using four types of semantics: data semantics, functional semantics, Quality of Service (QoS) semantics, and execution semantics. The usage process of Semantic Web Services includes the following [3]:

· Publication: Making the description of service capability available

· Discovery: Locating different services suitable for a given task

· Selection: Choosing the most appropriate services among the available ones

· Composition: Combining services to achieve a goal

· Mediation: Solving data, protocol, and process mismatches

· Execution: Invoking services following programmatic conventions

Semantic Web Services have three different types of properties: functional, behavioral, and nonfunctional properties. Functional properties define the capabilities of a web service. Behavioral properties provide a way to achieve the required functionality through interaction with other services. Nonfunctional properties set the constraints over the functional and behavioral properties or add metadata about the service. For instance, assume we have a flight booking service wherein the functionality is the actual booking, which might be constrained by using a secure connection when security is a nonfunctional property. The communication and integration of service-based Semantic Web applications are provided by WSDL, an XML description language for web services, SOAP, an XML-based message format to exchange arbitrary XML data between services and clients, and UDDI, a data model and API for web service registries. In other words, the service consumer finds the service through the UDDI registry, which points to the WSDL description of the web service, as well as to the actual service, which communicates with the consumer using SOAP.

Typical Semantic Web services have three phases (publishing, searching, and binding), as well as three entities (the service requester, the service provider, and the service registry). For example, a service provider can publish the description of a service to the UDDI service registry in the form of an advertisement, which includes the profile of the service provider (company name and address), a service profile, such as service name and category, and the service interface definition URL (WSDL description).

Communication with XML Messages: SOAP

The Simple Object Access Protocol (SOAP) is a syntax for sending and receiving XML messages with web services. Each SOAP message contains a SOAP envelope that wraps the message, a data encoding description, and the SOAP body that contains the application-specific message for the back-end application (see Figure 5-1).

9781484210505_Fig05-01

Figure 5-1. Structure of a web-based SOAP message

The root element of a SOAP message is the Envelope element, which is the container of the Header and Body elements (see Listing 5-1). The Body element can optionally contain a Fault element, which is used only if a fault occurs in the web service.

Listing 5-1. Structure of a SOAP Message

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope">

<soap:Header>
</soap:Header>

<soap:Body>

<soap:Fault>
</soap:Fault>

</soap:Body>

</soap:Envelope>

The SOAP envelope always contains the namespace declaration pointing to http://www.w3.org/2001/12/soap-envelope. The Header element, an optional child element of the Envelope element, can provide information not directly related to the message itself, such as the maximum time requirement of the SOAP request. The Header element uses the same XML namespace as the Envelope element. The mustUnderstand Boolean attribute of the Header element can explicitly state (mustUnderstand="true") that the SOAP agent processing the message must “understand” the header block. If the header is not understood, a SOAP fault is returned. The role attribute can specify the SOAP message forwarder or processor.

Note SOAP supports predefined and custom roles that can be used in the Header element and the Fault element. SOAP messages are processed by three types of nodes: the sender, the forwarder (not always used, corresponds to the next role), and the last node that actually processes the SOAP message (corresponds to the ultimateReceiver role). The URI of the next role is http://www.w3.org/2003/05/soap-envelope/role/next, while the URI of the ultimateReceiver role is http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver.

The relay attribute determines whether a header block can be relayed if not processed.

The Body element, which is a mandatory element, contains the main part of the SOAP message to be processed by either the client or the web service, such as a service element and its parameters nested inside it. If you declare a Fault element within the Body element, it can perform actions if an error occurs when processing the SOAP message. The Fault element has two mandatory child elements (Code and Reason) and three optional child elements (Node, Role, and Detail) (see Listing 5-2).

Listing 5-2. SOAP Fault Structure

<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>env:Sender</env:Value>
<env:Subcode>
</env:Subcode>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text>Incorrect Input Data</env:Text>
</env:Reason>
<env:Node>http://example.com/theNodeWhichFailed</env:Node>
<env:Role>
http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver
</env:Role>
</env:Fault>

The Value element is a sub-element of the Code element. The Value element can have one of five values. The VersionMismatch attribute indicates that a root element was found in the SOAP message that was not a valid Envelope element. The MustUnderstand attribute value is returned if any header child element could not have been processed. If the encoding of the header element (the encodingStyle attribute value) cannot be processed, the fault to be returned is the value of the DataEncodingUnknown attribute. The Sender attribute value is used if the sender sent an incorrectly written SOAP message with missing or invalid data. The Receiver attribute value is returned if the receiver of the SOAP message failed to process the message, such as if the database the web service relies on is unavailable. If you need separate code blocks for error handling, you can optionally add the Subcode element to the Code element.

The Reason element contains one or more Text elements that provide the reason of the fault. The natural language of the description can be specified by the lang attribute on the Text element as an ISO language code. The optional Node element contains a URI that identifies the node where the fault has occurred. The Role element contains the role of the node in which the fault has occurred. The Detail element has child elements providing additional information about the fault that occurred. These child elements use your custom namespace.

Web Services Description Language (WSDL)

The Web Service Description Language (WSDL, pronounced “Wiz’-dul”) is an XML-based interface definition language to describe the functionality of web services as collections of network endpoints, or ports, suitable for message exchange [4]. Ports are defined by associating a network address with a reusable binding, and the collections of ports define the WSDL services. The abstract, typed definitions of exchanged data form the WSDL messages. The collections of operations supported by one or more endpoints are the port types. The protocol and data format specifications provide a reusable binding, which is a concrete protocol and data format specification for a particular port type enabling WSDL to describe a public interface to web services. The file extension of WSDL files is .wsdl, while the Internet media type isapplication/wsdl+xml. A WSDL 2.0 file contains the following elements:

· The description element is the root element, which contains all other WSDL elements.

· The types element is the specification of the data types exchanged between the client and the web service described by default using XML Schema.

· The interface element enumerates the operations of the web service, the messages exchanged for each input and output operation, as well as the fault messages.

· The binding element describes how the web service is accessed over the network, usually binding the web service to the HTTP protocol.

· The service element declares where the web service can be accessed on the network, i.e., the URL of the service.

· The optional documentation element can contain a human-readable description of the web service.

· The optional import element can import XML Schemas or other WSDL files.

As a result, the skeleton WSDL document looks as shown in Listing 5-3.

Listing 5-3. Skeleton WSDL Document

The first part of all WSDL files is the definition of the service or services within the description root element, which also includes the standard namespace declarations, as well as the targetNamespace, the logical namespace for information about the service (see Listing 5-4).

Listing 5-4. XML Prolog and Namespace Declarations in WSDL

<?xml version="1.0" encoding="UTF-8"?>
<description
xmlns="http://www.w3.org/ns/wsdl"
xmlns:tns="http://www.example.com/wsdl"
xmlns:whttp="http://www.w3.org/ns/wsdl/http"
xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
targetNamespace="http://www.example.com/wsdl">

The xmlns attribute sets the default namespace of the description element to the standard WSDL namespace, http://www.w3.org/ns/wsdl. The default namespace is applied to all elements throughout the WSDL document that do not explicitly declare another namespace. The xmlns:tns attribute declares a namespace URI identical to the value of the targetNamespace (the namespace of your web service this schema is intended to target), providing a mechanism to refer to the target namespace via this namespace prefix (tns). The xmlns:stnsattribute can be used to declare the Schema Target Namespace URI, which is the URI of the namespace of the XML Schema used for the web service types on the types element. The xmlns:wsoap declares the WSDL SOAP URI used in the bindings element. The xmlns:soap can be used to point to the SOAP URI of the SOAP version used by the web service described by the WSDL document. The xmlns:wsdlx declares the WSDL Extensions URI.

Complex data types are required in WSDL documents, to define web service requests and responses (see Listing 5-5). A web service typically has an input type, an output type, and sometimes a fault type. If the web service has more than one operation, each operation might have its own input type, output type, and fault type. The data types can be declared in any language as long as it is supported by the API of your web service, but most commonly, they are specified using XML Schema. This document section can be omitted if you use simple data types only.

Listing 5-5. Abstract Types in WSDL

The operations supported by your web service can be described by the interface element (see Listing 5-6). Each operation represents an interaction between the client and the service. The client can only call one operation per request. The fault element defines a fault that can be sent back to the client, which can be used by multiple operations. The operation element describes a method or procedure.

Listing 5-6. Abstract Interfaces in WSDL

The next part defines how the operation should be performed, by declaring protocol and data format specifications for the operations and messages. This is done by “binding” the web service to the protocol through which it is accessible, using the binding element. The value of thename attribute on the binding element is referenced by the service element (see Listing 5-7). The interface attribute refers to the name of the interface element defined in the same WSDL file (using the prefix of the same document’s target namespace). The type attribute defines the message format, to which the interface is bound.

Listing 5-7. Binding over HTTP in WSDL

SOAP bindings can be specified by the wsoap:protocol attribute (see Listing 5-8). The fault element, when present, declares a fault, which can be sent back by the web service through the binding. The fault is defined in the interface element the binding refers to. The refattribute on the operation element declares an operation defined in the interface element the binding refers to. The wsoap:mepDefault attribute specifies SOAP’s default Message Exchange Pattern (MEP).

Listing 5-8. Binding with SOAP in WSDL

The last part specifies the port address or addresses of the binding. The service element is the container of the network endpoints, or ports, through which the web service can be reached (see Listing 5-9).

Listing 5-9. Offering Endpoints for Both Bindings

The name attribute on the service element describes the name of the web service. The interface attribute specifies the interface element, to which the service is related. The address attribute of the endpoint element declares the web address of the service.

Semantic Annotations for WSDL (SAWSDL)

Semantic Annotations for Web Service Description Language (SAWSDL) is a standard to specify how web service data bindings can be mapped to formal models [5]. SAWSDL offers a repeatable way to connect RDF or OWL to Semantic Web Services with fixed data bindings, making it easier to programmatically find service data that meets application needs. The description of additional semantics for WSDL components is provided by SAWSDL through a set of extension attributes for the Web Services Description Language and XML Schema definition language. The namespace prefixes for SAWSDL are sawsdl, pointing to www.w3.org/ns/sawsdl, and sawsdlrdf, which refers to www.w3.org/ns/sawsdl#.

The interfaces in WSDL documents can be annotated using modelReference, which provides a reference to a concept or concepts in a semantic model that describe the WSDL interface (see Listing 5-10).

Listing 5-10. SAWSDL Model Reference for a WSDL Interface

<wsdl:interface name="Order" sawsdl:modelReference="http://yourbookshop.com/textbooks">
…
</wsdl:interface>

WSDL operations can also be annotated using modelReference, referring to a concept in a semantic model to provide a high-level description of the operation, by specifying behavioral aspects or further semantic definitions for the operation (see Listing 5-11).

Listing 5-11. SAWSDL Model Reference for a WSDL Operation

<wsdl:operation name="order" pattern="http://www.w3.org/ns/wsdl/in-out"
sawsdl:modelReference="http://www.example.com/purchaseorder#RequestPurchaseOrder">
<wsdl:input element="OrderRequest" />
<wsdl:output element="OrderResponse" />
</wsdl:operation>

Another example for the implementation of SAWSDL’s model reference is fault annotation pointing to a high-level description of the fault, which may include further semantic annotations as well (see Listing 5-12).

Listing 5-12. SAWSDL Model Reference for a WSDL Fault

<wsdl:interface name="Order">
<wsdl:fault name="ItemUnavailableFault" element="AvailabilityInformation"
sawsdl:modelReference="http://www.example.com/purchaseorder#ItemUnavailable" />
…
</wsdl:interface>

Assume we have an online shop with a Semantic Web Service interface. The WSDL description of the service can be annotated with SAWSDL, as shown in Listing 5-13.

Listing 5-13. SAWSDL Annotations in the WSDL File of a Semantic Web Service

<wsdl:description
targetNamespace="http://www.example.com/wsdl/order#"
xmlns="http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order#"
xmlns:wsdl="http://www.w3.org/ns/wsdl"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:sawsdl="http://www.w3.org/ns/sawsdl">
<wsdl:types>
<xs:schema targetNamespace="http://www.example.com/wsdl/order#"
elementFormDefault="qualified">
<xs:element name="OrderRequest"
sawsdl:modelReference="http://example.com/purchaseorder#OrderRequest"
sawsdl:loweringSchemaMapping="http://www.example.com/mapping/lower.xml">
<xs:complexType>
<xs:sequence>
<xs:element name="customerNo" type="xs:integer" />
<xs:element name="orderItem" type="item" minOccurs="1" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="item">
<xs:all>
<xs:element name="UPC" type="xs:string" />
</xs:all>
<xs:attribute name="quantity" type="xs:integer" />
</xs:complexType>
<xs:element name="OrderResponse" type="confirmation" />
<xs:simpleType name="confirmation"
sawsdl:modelReference="http://www.example.com/purchaseorder#OrderConfirmation">
<xs:restriction base="xs:string">
<xs:enumeration value="Confirmed" />
<xs:enumeration value="Pending" />
<xs:enumeration value="Rejected" />
</xs:restriction>
</xs:simpleType>
</xs:schema>
</wsdl:types>
<wsdl:interface name="Order" sawsdl:modelReference="http://example.com/textbooks">
<wsdl:operation name="order" pattern="http://www.w3.org/ns/wsdl/in-out"
sawsdl:modelReference="http://www.example.com/purchaseorder#RequestPurchaseOrder">
<wsdl:input element="OrderRequest" />
<wsdl:output element="OrderResponse" />
</wsdl:operation>
</wsdl:interface>
</wsdl:description>

The loweringSchemaMapping on the OrderRequest element points to a mapping, which shows how the elements within the order request can be mapped from semantic data in the model to the actual execution format of the WS, for example, string or integer. In other words,loweringSchemaMapping lowers the data from the semantic model to XML. In contrast, LiftingSchemaMapping lifts data from XML to a semantic model.

XML Schema documents can be similarly annotated with SAWSDL.

Web Ontology Language for Services (OWL-S)

As an extension of the Web Ontology Language (OWL), Web Ontology Language for Services (OWL-S) facilitates the automation of web service tasks, such as discovery, composition, interoperation, execution, and execution monitoring [6]. OWL-S focuses on web service capabilities as well as functional and nonfunctional properties. OWL-S represents web service behavior based on situation calculus, a formal logic for representing and reasoning dynamic domains expressed in second-order logic. As an upper ontology language, OWL-S is suitable for describing web services through a Service class. Each entity of the Service class is a ServiceProfile.

OWL-S organizes a service description into four conceptual areas: the service model, the profile, the grounding, and the service. The process model describes how a client can interact with the service, including the sets of inputs, outputs, preconditions, and service execution results. Theservice profile describes the tasks performed by the service as human-readable data, including service name, service description, implementation limitations, quality of service, publisher, and contact information. The grounding provides all the details required by the client to interact with the service, including communication protocols, message formats, and port numbers. For grounding, the most commonly used language is WSDL. Because OWL-S atomic processes correspond to WSDL operations, the inputs and outputs of OWL-S atomic processes correspond to WSDL messages, while the input and output types of OWL-S atomic processes correspond to WSDL abstract types. The service binds the other parts into a unit that can be searched, published, and invoked.

Note The different parts of the service can be reused and connected in various ways. For instance, the service provider might connect the process model with several profiles, in order to provide customized advertisements to different markets.

Using OWL-S, software agents can automatically discover web services to fulfill a specific need with certain quality constraints. OWL-S also allows software agents to automatically read the description of inputs and outputs of web services and invoke the service. Furthermore, OWL enables automatic execution of complex tasks that involve the coordinated invocation of various web services, based exclusively on the high-level description of the objective.

The ServiceProfile superclass of OWL-S is suitable for the different high-level service descriptions. The basic information provided by ServiceProfile links a profile instance to a service instance. The presents property can be used to express the relation between a service instance and a profile instance. The presentedBy property expresses that a profile is related to a service.

The serviceName, textDescription, and contactInformation OWL-S properties provide descriptions primarily for human consumption. Only one value is allowed for the first two properties, while an arbitrary number of contact persons can be provided. The value ofserviceName is the name of the service that can be used as a service identifier. The textDescription provides a short service description, covering the service offering, the service prerequisites, and additional information to be shared with the receivers. The contactInformationdeclares contact persons using widely deployed vocabularies, such as FOAF, vCard, or Schema.

The service functionality, required conditions, and the expected and unexpected results can be defined with OWL-S properties such as hasInput and hasOutput datatype properties and the hasPrecondition and hasResult object properties, all of which are subproperties of the hasParameter object property. Additional profile attributes, such as the guaranteed service quality, can be expressed by serviceParameter, an optional property list for the profile description. The value of the serviceParameter property is an instance of theServiceParameter class.

The service category can be expressed using ServiceCategory, usually by referring to a definition in an external vocabulary. The categoryName property declares the name of the service category either as a string literal or the URI of the property used as a process parameter. The value of taxonomy defines the taxonomy scheme as the URI of the taxonomy. The value property explicitly refers to a taxonomy value. The property value of code is the code associated with a taxonomy. The serviceParameterName is the name of the parameter as a literal or URI. The sParameter points to the parameter value in an external ontology.

The serviceClassification and serviceProduct properties specify the provided service type and the products that are handled by the service. In other words, serviceClassification is a mapping between the service profile and a service ontology, whileserviceProduct is a mapping between a service profile and a product ontology.

To represent services as processes, OWL-S 1.1 defines Process (a subclass of ServiceModel). The Parameter class has the Input and Output subclasses to describe process parameters (see Listing 5-14).

Listing 5-14. Input and Output Are Subclasses of Parameter

<owl:Class rdf:ID="Input">
<rdfs:subClassOf rdf:resource="#Parameter" />
</owl:Class>

<owl:Class rdf:ID="Output">
<rdfs:subClassOf rdf:resource="#Parameter" />
</owl:Class>

Process parameters are typically expressed as SWRL variables (see Listing 5-15), because SWRL is a language specifically designed for expressing OWL rules [7].

Listing 5-15. A Process Parameter as a SWRL Variable

<owl:Class rdf:about="#Parameter" rdf:ID="/parameterType/">
<rdfs:subClassOf rdf:resource="&swrl;#Variable" />
</owl:Class>

Each parameter has a type with a URI value that specifies the type of a class or datatype (see Listing 5-16). The type can be used, for example, to evaluate a credit card number for an e-commerce service.

Listing 5-16. Parameter Type Specified by a URI

<owl:Class rdf:ID="Parameter">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#parameterType" />
<owl:minCardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>

A process has at least two agents, namely TheClient and TheServer. Further agents can be listed using the hasParticipant property (see Listing 5-17).

Listing 5-17. Process Agents in OWL-S

<owl:ObjectProperty rdf:ID="hasParticipant">
<rdfs:domain rdf:resource="#Order" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasClient">
<rdfs:subPropertyOf rdf:resource="#hasContract" />
</owl:ObjectProperty>

<process:Parameter rdf:ID="TheClient">
<process:Parameter rdf:ID="TheServer">

If a process has a precondition, the process cannot be performed unless the precondition is true. Preconditions can be express in OWL-S, as shown in Listing 5-18.

Listing 5-18. Precondition Definition

<owl:ObjectProperty rdf:ID="hasPrecondition">
<rdfs:domain rdf:resource="#Order" />
<rdfs:range rdf:resource="#Payment" />
</owl:ObjectProperty>

Inputs and outputs specify the data transformation of the service process. The input specifies the information required for process execution, while the output provides the transformed data (see Listing 5-19).

Listing 5-19. The hasInput, hasOutput, and hasLocal Subproperties of hasParameter

<owl:ObjectProperty rdf:ID="hasParameter">
<rdfs:domain rdf:resource="#Order" />
<rdfs:range rdf:resource="#Status" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasInput">
<rdfs:subPropertyOf rdf:resource="#validCard" />
<rdfs:range rdf:resource="#Input" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasOutput">
<rdfs:subPropertyOf rdf:resource="#orderPlaced" />
<rdfs:range rdf:resource="#Ordering" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasLocal">
<rdfs:subPropertyOf rdf:resource="#ordered" />
<rdfs:range rdf:resource="#Local" />
</owl:ObjectProperty>

The output and the state change (effect) together are called a result (see Listing 5-20).

Listing 5-20. A Result

<owl:Class rdf:ID="Result">
<rdfs:label>Result</rdfs:label>
</owl:Class>

<owl:ObjectProperty rdf:ID="hasResult">
<rdfs:label>hasResult</rdfs:label>
<rdfs:domain rdf:resource="#Order" />
<rdfs:range rdf:resource="#Ordering" />
</owl:ObjectProperty>

If a result is declared, the output and effect conditions can be expressed using the four ResultVar (scoped to a particular result) or Local variables (bound in preconditions and used in the result conditions): inCondition, withOutput, hasEffect, and hasResultVar (seeListing 5-21). The inCondition property specifies the condition under which the result occurs. The withOutput and hasEffect properties determine what happens when the declared condition is true. The hasResultVar property declares the variables bound in theinCondition property.

Listing 5-21. Output and Effect Conditions

<owl:ObjectProperty rdf:ID="inCondition">
<rdfs:label>inCondition</rdfs:label>
<rdfs:domain rdf:resource="#Order" />
<rdfs:range rdf:resource="#Payment" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasResultVar">
<rdfs:label>hasResultVar</rdfs:label>
<rdfs:domain rdf:resource="#Order" />
<rdfs:range rdf:resource="#Ordering" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="withOutput">
<rdfs:label>withOutput</rdfs:label>
<rdfs:domain rdf:resource="#Order" />
<rdfs:range rdf:resource="#Output" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasEffect">
<rdfs:label>hasEffect</rdfs:label>
<rdfs:domain rdf:resource="#Order" />
<rdfs:range rdf:resource="#Ordering" />
</owl:ObjectProperty>

While OWL-S is suitable for its primary purpose by describing service offers and requirements, owing to its limited expressiveness, unrelated operations are not supported.

Web Service Modeling Ontology (WSMO)

The Web Service Modeling Ontology (WSMO, pronounced “Wizmo”) is a conceptual model for Semantic Web Services, covering the core Semantic Web Service elements as an ontology using the WSML formal description language and the WSMX execution environment [8]. WSMO is derived from and based on the Web Service Modeling Framework (WSMF) [9]. WSMO enables partial or full automation of discovery, selection, composition, mediation, execution, and monitoring tasks involved in web services. The four main components of WSMO are the goals, themediators, the web service descriptions, and the ontologies that are represented as top-level elements (see Figure 5-2).

9781484210505_Fig05-02

Figure 5-2. Top-level WSMO elements

Similar to OWL-S, WSMO also defines a mapping to WSDL, but with an ontology-based grounding, which prevents the loss of ontological descriptions throughout the service usage process. Whereas OWL-S does not have the concept of mediator, and mediation is a byproduct of orchestration or is derived from translation axioms, in WSMO, mediators are core conceptual elements.

WSMO has a goal-based approach to service description, which can be used when searching for services based on goals. The goals are the wishes of the client to be fulfilled by the service. Mediators are connectors between components that provide interoperability between different ontologies and resolve structural, semantic, and conceptual mismatches.

There are four types of WSMO mediators: mediators that link two goals, mediators that import ontologies and resolve possible representation mismatches between ontologies, mediators that link web services to goals, and mediators that link two web services. The Semantic Web Service descriptions can cover functional and usage descriptions. The functional descriptions describe the capabilities of the service, while the usage description describes the interface. The ontologies provide the formal description of the information used by all other components.

WSMO elements are described by nonfunctional properties, using the Dublin Core Metadata Set (Contributor, Coverage, Creator, Description, Format, Identifier, Language, Publisher, Relation, Rights, Source, Subject, Title, Type) for complete item description and resource management (see Listing 5-22).

Listing 5-22. Core WSMO Nonfunctional Properties Expressed Using Dublin Core in an Example Ontology

ontology <"http://www.example.com/holidayplanner">
nonFunctionalProperties
dc:title hasValue "Holiday Planner Example Ontology"
dc:creator hasValue "Leslie Sikos"
dc:subject hasValues {"Trip", "Itinerary", "Stop", "Ticket"}
dc:description hasValue "Our Holiday Packages"
dc:publisher hasValue "Leslie Sikos"
dc:date hasValue "2015-02-21"
dc:format hasValue "text/html"
endNonFunctionalProperties

The service class can be used to describe services both from the client’s and the service provider’s point of view, featuring general metadata with nonfunctional properties, imported ontologies (if any), mediators, service capability, service interface, functions, axioms, and ontology instances (see Listing 5-23).

Listing 5-23. The Definition of the service Class

Class service
hasNonFunctionalProperties type nonFunctionalProperties
importsOntology type ontology
usesMediator type {ooMediator, wwMediator}
hasCapability type capability multiplicity = single-valued
hasInterface type interface
hasFunction type function
hasInstance type instance
hasAxiom type axiom

Nonfunctional properties can express much more than general service metadata, as they cover Quality of Service (QoS) information for availability and stability, such as Accuracy, NetworkRelatedQoS, Performance, Reliability, Robustness, Scalability,Security, Transactional, and Trust, as well as other financial, ownership, and versioning information (Financial, Owner, Version). For example, a service provider can describe student discounts or pensioner concession criteria using nonfunctional WSMO properties.

Beyond the nonfunctional properties, the ontology definitions can contain imported ontologies (importsOntology). To handle heterogeneities, you can define mediators using usesMediators (see Listing 5-24).

Listing 5-24. Defining a Mediator

usesMediators {<<http://www.example.com/externalMediator.wsml>>}

The entity sets of the knowledge domain of the ontology can be defined using concept. For a vacation booking service, for example, you have to define the concept of country and its properties, such as ISO country code (see Listing 5-25).

Listing 5-25. Defining Entity Sets for the Domain

concept country subConceptOf {cnt:country, geo:country}
nonFunctionalProperties
dc:description hasValue "Country Codes"
endNonFunctionalProperties
isoCode ofType xsd:string
nonFunctionalProperties
dc:description hasValue "ISO 3166 Country Code"
endNonFunctionalProperties

The relationships between concepts can be defined using relation (see Listing 5-26).

Listing 5-26. Defining Relations between Concepts[10]

relation equalDistance
nonFunctionalProperties
dc:description hasValue "Computes equality of a distance"
endNonFunctionalProperties
d1 ofType distance
d2 ofType distance
definedBy
forAll ?x,?y ( equalDistance[d1 hasValue ?x, d2 hasValue ?y] equivalent
kilometers(?x,?k1) and kilometers(?y,?k2) and ?k1=?k2).

relation lessThanDistance
nonFunctionalProperties
dc:description hasValue "Computes -less than- for a distance"
endNonFunctionalProperties
d1 ofType distance
d2 ofType distance
definedBy
forAll ?x,?y ( equalDistance[d1 hasValue ?x, d2 hasValue ?y] equivalent
kilometers(?x,?k1) and kilometers(?y,?k2) and ?k1<?k2).

relation moreThanDistance
nonFunctionalProperties
dc:description hasValue "Computes -more than- for a distance"
endNonFunctionalProperties
d1 ofType distance
d2 ofType distance
definedBy
forAll ?x,?y ( equalDistance[d1 hasValue ?x, d2 hasValue ?y] equivalent
kilometers(?x,?k1) and kilometers(?y,?k2) and ?k1>?k2).

Algorithms can be added to your WSMO ontology by defining functions. For instance, if your vacation booking service supports distances expressed in kilometers and miles, you can write functions to convert distances from one unit to the other (see Listing 5-27).

Listing 5-27. Defining Functions in WSMO[10]

function kilometers
nonFunctionalProperties
dc:description hasValue "Expressing a distance in kilometers"
endNonFunctionalProperties
d ofType distance
range ofType xsd:float
definedBy
forAll ?x,?y (kilometers[d hasValue ?d, result hasValue ?y] equivalent
?d[amount hasValue ?a, units hasValue ?u] and ((?u="Kilometers" and ?y=?a) or
(?a="Miles" and ?y=?a*1.609344))).

function miles
nonFunctionalProperties
dc:description hasValue "Expressing a distance in miles"
endNonFunctionalProperties
d ofType distance
range ofType xsd:float
definedBy
forAll ?x,?y (miles[d hasValue ?d, result hasValue ?y] equivalent
?d[amount hasValue ?a, units hasValue ?u] and ((?u="Miles" and ?y=?a) or
(?a="Kilometers" and ?y=?a/1.609344))).

Ontology instances can be defined using instance. In a flight booking service, for example, you can define destination countries offered by your service, as shown in Listing 5-28.

Listing 5-28. An Instance in a WSMO Ontology

instance Australia memberOf country
isoCode hasValue "AU"^^xsd:string

Logical statements (axiomatic expressions) of an ontology can be defined by axiom (see Listing 5-29).

Listing 5-29. An Instance in a WSMO Ontology

axiom validDistance
nonFunctionalProperties
dc:description hasValue "The distance must be larger than 0km or 0m."
endNonFunctionalProperties
definedBy
constraint
?D[amount hasValue ?A, units hasValue ?U] memberOf distance and ?A < 0 and not
(U="Kilometers" or U="Miles").

The functional capabilities of a service can be expressed using the capability class, which covers precondition, assumption, post-condition, and effect (state change) axioms, and variables shared among preconditions, post-conditions, assumptions, and effects (see Listing 5-30).

Listing 5-30. The Definition of the capability Class in WSMO

Class capability
hasNonFunctionalProperties type nonFunctionalProperties
importsOntology type ontology
usesMediator type {ooMediator, wgMediator}
hasSharedVariables type sharedVariables
hasPrecondition type axiom
hasAssumption type axiom
hasPostcondition type axiom
hasEffect type axiom

For example, if you use a government service to register pensioners, the effect of the service execution is that the user becomes a pensioner.

The web service interface describes operational competence of a web service using the interface class in two ways: through choreography and orchestration (see Listing 5-31). Choreography expresses web service capability from the interaction point of view, in other words, it models all service interactions, including the invariant elements of the state description (state signature), the state described by an instance set, and state changes (guarded transitions). Orchestration expresses web service capability from the functionality point of view.

Listing 5-31. Choreography and Orchestration Defined for the interface Class

Class interface
hasNonFunctionalProperties type nonFunctionalProperties
importsOntology type ontology
usesMediator type ooMediator
hasChoreography type choreography
hasOrchestration type orchestration

The purpose of a web service can be expressed by the goal class (see Listing 5-32). For example, the goal of a service can be a user registration, a ticket purchase, or a room reservation.

Listing 5-32. The Definition of the goal Class in WSMO

Class goal sub-Class wsmoTopLevelElement
importsOntology type ontology
usesMediator type {ooMediator, ggMediator}
requestsCapability type capability multiplicity = single-valued
requestsInterface type interface

MicroWSMO and WSMO-Lite

MicroWSMO is an extension of hRESTS [11] designed for semantic annotations through SAWSDL extensions such as model (indicates that a link is a model reference) and lifting (lowering links to the respective data transformations) [12]. hRESTS provides a WSDL equivalent for RESTful services, making it possible to annotate the HTML markup of the service description. An example is shown in Listing 5-33.

Listing 5-33. Annotated Service Description

<div class="service">
<p><span class="label">Dream Holidays</span> is a
<a rel="model" href="/BookingService/"> hotel room reservation</a> service.
</p>
<p class="operation" …>
</p>
</div>

These annotations can be used by microWSMO to refer to elements of the same lightweight service modeling ontology as WSMO-Lite, which fills the annotations with concrete service semantics. WSMO-Lite is not bound to a particular service description format and allows the creation of matching stacks for SOAP and REST.

Web Service Modeling Language (WSML)

The Web Service Modeling Language (WSML) is a formal language for axiomatic expressions that provides the conceptual syntax and semantics for the elements of WSMO, the Web Service Modeling Ontology [13]. WSML can be used to formally describe WSMO elements as ontologies, Semantic Web services, goals, and mediators. WSML is based on mathematical logic, such as description logic and first-order logic, as well as logic programming.

WSML has two syntaxes: the conceptual syntax and the logical expression syntax. The conceptual syntax is used for the ontology, goal, web service, and mediator modeling. Logical expressions refine the ontology, goal, web service, and mediator definitions, using a logical language. The conceptual syntax has a frame-like style by which classes, relations, and instances, as well as their attributes, are specified in a single syntactic construct. However, attribute names are global in WSML. Argument lists are separated by commas and surrounded by curly brackets. Statements start with a keyword and can be spread over multiple lines. WSML implements the RDF namespace mechanism. The WSML keywords are defined at the namespace www.wsmo.org/wsml/wsml-syntax# and commonly abbreviated with the prefix wsml. WSML identifiers can be data values, Internationalized Resource Identifiers (IRIs, which are URIs that can contain Unicode characters such as Chinese ideographs, Japanese kanji, Cyrillic characters, etc.), or anonymous identifiers. The basic data types are string, integer, and decimal. Data values are based on the XML Schema datatypes but expressed with a different syntax (see Listing 5-34).

Listing 5-34. The Date “22 February 2015” in WSML

_date(2015,2,22)

There are three syntactical shortcuts for string, integer, and decimal data types. String data values can be written between double quotation marks (see Listing 5-35). Double quotation marks inside a string should be escaped using \.

Listing 5-35. A String in Double Quotation Marks

dc#title hasValue "Your Amigo"

Integer values can be written without declaring the number type. For example, 5 is a shortcut for _integer("5"). If a decimal symbol is present, the number is assumed to be a decimal number. For example, 22.5 is a shortcut for _decimal("22.5").

IRIs start with an underscore and are written in double quotes (see Listing 5-36).

Listing 5-36. A Full IRI in WSML

_"http://example.org/YourOntology#YourTerm"

IRIs can be abbreviated as a serialized Qualified Name (sQName), which combines the namespace prefix and the local entity name separated by #. In Listing 5-35, for example, dc#title corresponds to http://purl.org/dc/elements/1.1#title, foaf#name abbreviateshttp://xmlns.com/foaf/0.1/name, xsd#string refers to http://www.w3.org/2001/XMLSchema#string, and schema#Person corresponds to http://schema.org/Person. WSML defines two IRIs, one for universal truth (http://www.wsmo.org/wsml/wsml-syntax#true) and another one for universal falsehood (http://www.wsmo.org/wsml/wsml-syntax#false).

The third WSML identifier type, the anonymous identifier, represents a globally unique IRI.

The optional namespace references can be defined at the top of WSML documents, below the WSML variant identification. The namespace reference block is preceded by the namespace keyword. All namespace references, except for the default namespace, consist of the prefix and the IRI that identifies the namespace (see Listing 5-37).

Listing 5-37. Namespace Declarations in WSML

namespace {_"http://www.yourdefaultns.com/yourOntology/term#",
dc _"http://purl.org/dc/elements/1.1#",
foaf _"http://xmlns.com/foaf/0.1/",
xsd _"http://www.w3.org/2001/XMLSchema#",
wsml _"http://www.wsmo.org/wsml-syntax#"}

WSML headers might contain nonfunctional properties, may import ontologies, and may use mediators. Nonfunctional property blocks are delimited by the nonFunctionalProperties and endNonFunctionalProperties keywords that can be abbreviated as nfp andendnfp. The list of attribute values within the block contains the attribute identifier, the hasValue keyword, and the attribute value, which can be any kind of identifier (data value, IRI, anonymous identifier, or a comma-separated list). The Dublin Core properties are recommended for nonfunctional property definitions; however, terms of other external vocabularies are also allowed (see Listing 5-38).

Listing 5-38. A Nonfunctional Property Block in WSML

nonFunctionalProperties
dc#title hasValue "WSML Example"
dc#subject hasValue "training"
dc#description hasValue "WSML non-functional property examples"
dc#contributor hasValue {_"http://lesliesikos.com/datasets/sikos.rdf#sikos"}
dc#date hasValue _date("2015-02-22")
dc#format hasValue "text/html"
dc#language hasValue "en-AU"
endNonFunctionalProperties

In the header, ontologies can optionally be imported using the importsOntology keyword, by declaring the namespace IRI (see Listing 5-39).

Listing 5-39. Importing Ontologies

importsOntology {_"http://purl.org/dc/elements/1.1#", _"http://schema.org/Person"}

Mediators can be optionally defined in the header with the usesMediator keyword to link different WSML elements (ontologies, goal, and web services) and resolve heterogeneities between the elements (see Listing 5-40).

Listing 5-40. Using a Mediator

usesMediator _"http://example.com/importMediator"

Web Services Business Process Execution Language (WS-BPEL)

Business processes require sophisticated exception management, enterprise collaboration, task sharing, and end-to-end control. The Web Services Business Process Execution Language (WS-BPEL), often abbreviated as BPEL (Business Process Execution Language), is an XML-based standard language for specifying web service actions for business processes. BPEL is suitable for Service-Oriented Architectures (SOA), and is implemented by industry giants such as Oracle and based on earlier execution languages, such as IBM’s Web Service Flow Language (WSFL) and Microsoft’s XLang. The ten original design goals of BPEL are the following:

1. Define business processes that interact with external entities through web service operations and that manifest themselves as web services. Both the operations and the web services are defined using WSDL 1.1.

2. Define business processes based on an XML serialization. Do not define a graphical representation of processes or provide any particular design methodology for processes.

3. Define a set of web service orchestration concepts to be used by external (abstract) and internal (executable) views of a business process.

4. Provide hierarchical as well as graph-like controls.

5. Provide data manipulation functions for process data and control flow.

6. Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level.

7. Support the implicit creation and termination of process instances as the basic life cycle mechanism.

8. Define a long-running transaction model based on compensation actions and scoping to support failure recovery for parts of long-running business processes.

9. Use web services as the model for process decomposition and assembly.

10.Build on web services standards.

In order to define logic for service interactions, BPEL defines business process behavior through web service orchestration. BPEL processes transfer information using the web service interfaces. BPEL can model web service interactions as executable business processes, as abstract business processes, or through the behavior of processes. The BPEL programming language supports

· Message sending and receiving

· XML and WSDL typed variables

· A property-based message correlation mechanism

· An extensible language plug-in model to allow writing expressions and queries in multiple languages¹

· Structured-programming constructs, such as if-then-elseif-else, while, sequence, and flow

· Logic in local variables, fault-handlers, compensation-handlers, and event-handlers

· Scopes to control variable access

Some of the popular BPEL engines are Apache ODE, BizTalk Server, Oracle BPEL Process Manager, SAP Exchange Infrastructure, Virtuoso Universal Server, and WebSphere Process Server.

Semantic Web Service Software

Developers can use semantic execution environments such as WSMX and IRS to provide automatic discovery, composition, selection, mediation, and invocation of Semantic Web Services. The development of Semantic Web Services can be speeded up using purpose-built frameworks and plug-ins such as the Web Services Modeling Toolkit (WSMT) and the Semantic Automated Discovery and Integration plug-in for Protégé.

Web Service Modeling eXecution environment (WSMX)

The Web Service Modeling eXecution environment (WSMX) is the reference implementation of the Web Service Modeling Ontology using WSML as the internal language and WSMT for modeling [14]. It is an open source execution environment for business applications, with integrated web services available at http://sourceforge.net/projects/wsmx/, providing increased business processes automation and scalability. WSMX consumes semantic messages, discovers semantically annotated web services, and processes them. Between the back-end applications of requested services and the provided services, WSMX has a system interface, an administration interface, resource manager interfaces for mapping and datastore access, and a reasoner framework.

Internet Reasoning Service (IRS-III)

The Internet Reasoning Service (IRS) is the Open University’s Semantic Web Services framework, which allows applications to semantically describe and execute Web services [15]. It supports the provision of semantic reasoning services within the context of the Semantic Web. The best-known implementation of the Internet Reasoning Service is IRS-III.

Web Services Modeling Toolkit (WSMT)

The Web Services Modeling Toolkit (WSMT) is a lightweight framework for rapid Semantic Web Service development and deployment available at http://sourceforge.net/projects/wsmt/. It also collects existing SWS tools within one application. The Web Services Modeling Toolkit can be integrated into the WSMX and IRS-III execution environments.

The Web Services Modeling Toolkit is primarily designed for Java programmers developing software in Integrated Development Environments such as Eclipse or NetBeans. The Toolkit aims to help developers of Semantic Web Services using the WSMO paradigm. Java developers can combine the Web Services Modeling Toolkit with other plug-ins, such as the Eclipse Web Tools Platform (WTP), which provides tools with XML and WSDL support for creating Semantic Web Services and describes them semantically using WSMO. The Web Services Modeling Toolkit supports the creation of common document types used in Semantic Web Services through editing, validation, testing, and deployment. The Toolkit features a text editor, a form-based editor, and a validator for WSML and provides different views for reasoning and discovery.

Because mappings between two ontologies are created at design time and applied automatically at runtime in order to perform instance transformation, the Web Services Modeling Toolkit provides guidance for ontology-ontology mappings. WSMT mappings are expressed in the Abstract Mapping Language (AML), which is then transformed to WSML. The Toolkit features an AML text editor and a visual editor, an AML validator, and provides mapping and testing view for AML.

Semantic Automated Discovery and Integration (SADI)

Semantic Automated Discovery and Integration (SADI) is a lightweight set of Semantic Web Service design patterns (https://code.google.com/p/sadi/). It was primarily designed for scientific service publication and is especially useful in bioinformatics. Powered by web standards, SADI implements Semantic Web technologies to consume and produce RDF instances of OWL-DL classes, where input and output class URIs resolve to an OWL document through HTTP GET. SADI supports RDF/XML and Notation3 serializations. The SADI design patterns provide automatic discovery of appropriate services, based on user needs, and can automatically chain these services into complex analytical workflows. SADI is available as a plug-in for the Protégé ontology editor, the IO Informatics Knowledge Explorer to graph visualization, as well as Taverna, an open-source workflow design and enactment workbench.

UDDI Semantic Web Service Listings

Universal Description, Discovery and Integration (UDDI) is a platform-independent XML-based directory service for businesses offering web services. It describes web services and business processes programmatically in a single, open, and secure environment. UDDI is described in WSDL and communicates via SOAP. UDDI can be used to improve e-commerce interoperability between streamline online transactions. Similar to the White Pages or Yellow Pages of telephone books, UDDI allows business listings with business name, location, and offered products and/or web services. Any company can be added to the UDDI registry, regardless of the business size. Already listed enterprises include Microsoft, IBM, Ariba, HP, Compaq, American Express, SAP, and Ford, just to mention the most well-known ones. UDDI can help business owners to discover relevant businesses and decision makers to increase access to current customers and reach potential customers, expand offerings, and extend market reach.

Summary

In this chapter, you learned what Semantic Web Services are and how they can be described using WSDL, annotated using SAWSDL, and modeled using OWL-S, WSMO, MicroWSMO and WSMO-Lite, and WSML. You became familiar with the Semantic Web Service software, such as the WSMX and IIR-III execution environments, as well as the WSMT Toolkit and the SADI Protégé plug-in. You learned about the UDDI service listing used to dynamically look up and discover services provided by external business partners and service providers.

The next chapter will show you how to store triples and quads efficiently in purpose-built graph databases: triplestores and quadstores.

References

1. Domingue, J., Martin, D. (2008) Introduction to the Semantic Web Tutorial. The 7th International Semantic Web Conference, 26–30 October, 2008, Karlsruhe, Germany.

2. Facca, F. M., Krummenacher, R. (2008) Semantic Web Services in a Nutshell. Silicon Valley Semantic Web Meet Up, USA.

3. Stollberg, M., Haller, A. (2005) Semantic Web Services Tutorial. 3rd International Conference on Web Services, Orlando, FL, USA, 11 July 2005.

4. Chinnici, R., Moreau, J.-J., Ryman, A., Weerawarana, S. (eds.) (2007) Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. www.w3.org/TR/wsdl20/. Accessed 2 April 2015.

5. Farrell, J., Lausen, H. (eds.) (2007) Semantic Annotations for WSDL and XML Schema. www.w3.org/TR/sawsdl/. Accessed 2 April 2015.

6. Martin, D. et al. (2004) OWL-S: Semantic Markup for Web Services. www.w3.org/Submission/OWL-S/. Accessed 2 April 2015.

7. Horrocks, I. et al. (2004) SWRL: A Semantic Web Rule Language. Combining OWL and RuleML. www.w3.org/Submission/SWRL/. Accessed 2 April 2015.

8. Lausen, H., Polleres, A., Roman, D. (eds.) (2005) Web Service Modeling Ontology (WSMO). www.w3.org/Submission/WSMO/. Accessed 2 April 2015.

9. Fensel, D., Bussler, C. (2002) The Web Service Modeling Framework WSMF. www.swsi.org/resources/wsmf-paper.pdf. Accessed 2 April 2015.

10. Stollberg, M., Lausen, H., Polleres, A., Lara, R. (eds.) (2004) Locations Ontology. www.wsmo.org/2004/d3/d3.2/b2c/20041004/resources/loc.wsml.html. Accessed 4 April 2015.

11. Roman, D., Kopecký, J., Vitvar, T., Domingue, J., Fensel, D. (2014) WSMO-Lite and hRESTS: Lightweight semantic annotations for Web services and RESTful APIs. Web Semantics: Science, Services and Agents on the World Wide Web,http://dx.doi.org/10.1016/j.websem.2014.11.006.

12. Kopecký, J., Vitvar, T. (2008) MicroWSMO: Semantic Description of RESTful Services. http://wsmo.org/TR/d38/v0.1/20080219/d38v01_20080219.pdf. Accessed 4 April 2015.

13. de Bruijn, J. et al. (2005) Web Service Modeling Language (WSML). www.w3.org/Submission/WSML/. Accessed 2 April 2015.

14. DERI and STI2 (2008) Web Service Modelling eXecution environment. www.wsmx.org. Accessed 4 April 2015.

15. Domingue, J. et al. (2011) Internet Reasoning Service. http://technologies.kmi.open.ac.uk/irs/. Accessed 2 April 2015.

_________________

¹BPEL has native XPath 1.0 support.