Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Web services provide a standards-based foundation for exchanging information between distributed software systems. The W3C Recommendation Web Services Description Language (WSDL) specifies a standard way to describe the interfaces of a Web Service at a syntactic level and how to invoke it. While the syntactic descriptions provide information about the structure of input and output messages of an interface and about how to invoke the service, semantics are needed to describe what a Web service actual does. These semantics, when expressed in formal languages, disambiguate the description of Web services interfaces, paving the way for automatic discovery, composition and integration of software components. WSDL does not explicitly provide mechanisms to specify the semantics of a Web service. Semantic Annotations for WSDL and XML Schema (SAWSDL) defines mechanisms by which semantic annotations can be added to WSDL components. This usage guide is an accompanying document to SAWSDL specification. It presents examples illustrating how to associate semantic annotations with a Web service. These annotations could be used for classifying, discovering, matching, composing, and invoking Web services.
Some of the examples illustrated in this document use RDF and OWL Web Ontology Language for representing ontologies. Some knowledge of RDF and OWL is useful for understanding this document, but not essential.
As the set of available Web Services expands, it becomes increasingly important to have automated tools to help identify services that match a requester's requirements. Finding suitable Web services automatically depends on the facilities available for service providers to describe the capabilities of their services and for service requesters to describe their requirements in an unambiguous and ideally, machine-interpretable form. Adding semantics to represent the requirements and capabilities of Web services is essential for achieving this clarity and machine-interpretability.
Semantics play an important role in all aspects of the lifecycle of Web services. During development, a service provider can explicate the intended semantics by annotating the appropriate parts of the Web service with concepts from a richer semantic model. Since semantic models provide agreement on the terms and intended use of terms, and may provide formal and informal definitions of the entities, there will be less ambiguity in the intended semantics of the provider. During discovery, a service requestor can describe the service requirements using terms from the semantic model. Reasoning techniques can be used to find service descriptions that match the request. During composition, these annotations can be used to aggregate the functionality of multiple services to create useful service compositions. Also, semantics based schema mappings can facilitate data transformations from which mediation code can be generated to enable Web services invocation. Therefore, once represented, semantics can be leveraged by tools to automate service discovery, mediation, composition and monitoring.
The W3C Recommendation Web Services Description Language (WSDL) specifies a standard way to describe the interfaces of a Web Service at a syntactic level and how to invoke it. However, WSDL does not explicitly provide mechanisms to specify the semantics of a Web service. Semantic Annotations for WSDL and XML Schema (SAWSDL) defines mechanisms by which semantic annotations can be added to WSDL components. This usage guide is an accompanying document to SAWSDL specification. It presents examples illustrating how to associate semantic annotations with a Web service. These annotations could be used for classifying, discovering, matching, composing, and invoking Web services.
The sections in this document are organized to show how to associate semantic annotations with a WSDL document for use in service classification, discovery, matching, composition and invocation in that order.
The XML namespace name URIs used by this specification are as follows:
Throughout this document, we use two Web services and several variations on these Web services to illustrate how semantic annotations on a WSDL can be used to do Web service interface matching and composition. One of these two Web services is presented as a request of a desirable Web service while the other is used as an advertisement or a service being offered by a service provider. Some readers may be new to the concept of representing the requirements of a client as a Web service - WSDL. While there may be different ways of representing the requirements of a client, in this document, for illustrative purposes we adopted the notion of a request WSDL where the requirements of a client are modeled as a Web service - WSDL. The inputs and outputs of this request WSDL codify the available inputs that a client can provide and the expected outputs from a service respectively. We then use the concepts of annotating a request similar to the way that one can annotate a service provider's WSDL and illustrate how a request WSDL interface can be matched, composed and transformed to invoke a service provider's advertised service.
We present these two Web services here so as to allow the reader to get familiarized with the examples used in the rest of the document. These are 'vanilla' WSDL files with no semantic annotations. In the following sections, these WSDLs are shown with suitable semantic annotations that suit the specific illustration. First a WSDL representation of a request WSDL is given followed by a service provider's advertisement WSDL.
<wsdl:description
targetNamespace="http://org1.example.com/wsdl/CheckAvailabilityRequestService/"
xmlns="http://org1.example.com/wsdl/CheckAvailabilityRequestService/"
xmlns:wsdl="http://www.w3.org/ns/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<xsd:schema targetNamespace=http://org1.example.com/wsdl/CheckAvailabilityRequestService">
<xsd:element name="CheckAvailabilityRequestServiceRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="itemCode" type="xsd:string"/>
<xsd:element name="date" type="xsd:string"/>
<xsd:element name="qty" type="xsd:float"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CheckAvailabilityRequestServiceResponse" type="itemConfirmation"/>
<xsd:simpleType name="itemConfirmation">
<xsd:restriction base="xsd:boolean"/>
</xsd:simpleType>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="CheckAvailabilityRequestService">
<wsdl:operation name="CheckAvailabilityRequestOperation" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="CheckAvailabilityRequestServiceRequest"/>
<wsdl:output element="CheckAvailabilityRequestServiceResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
Listing 1.2-1: A WSDL sample for CheckAvailabilityRequest service. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/CheckAvailabilityRequestService.wsdl.
<wsdl:description
targetNamespace="http://org2.example.com/wsdl/CheckInventoryService/"
xmlns="http://org2.example.com/wsdl/CheckInventoryService/"
xmlns:wsdl="http://www.w3.org/ns/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<xsd:schema targetNamespace="http://org2.example.com/wsdl/CheckInventoryService">
<xsd:element name="CheckInventoryServiceRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SKU" type="xsd:string"/>
<xsd:element name="deliveryDate" type="xsd:string"/>
<xsd:element name="numBundles" type="xsd:float"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CheckInventoryServiceResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="conf" type="xsd:boolean"/>
<xsd:element name="numBundles_available" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="CheckInventoryService">
<wsdl:operation name="checkInventoryService" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="CheckInventoryServiceRequest"/>
<wsdl:output element="CheckInventoryServiceResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
Listing 1.2-2: A WSDL sample for CheckInventoryService. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/CheckInventoryService.wsdl.
A Web service can be semantically annotated to carry categorization information that could be used to publish it for instance in a service registry. The SAWSDL extension mechanism modelReference can be used to add this categorization information to Web services. This categorization information could be used when automatically publishing services in registries such as UDDI [UDDI]. Below, we illustrate a couple of ways in which categorization information can be associated with a Web service.
If a categorization semantic model already exists (for example a taxonomy), then a modelReference element could be defined either on an interface or on an operation of a Web service to point to a particular category in the taxonomy. For example, if a purchase order taxonomy was created as shown in Listing 2.1-1 below (shown in RDF Turtle [Turtle] format for readability), then the interface of an item availability check Web service (introduced in Listing 1.2-1) could be annotated with taxonomy information as shown in Listing 2.1-2.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix : <http://www.w3.org/2002/ws/sawsdl/spec/examples/taxonomy/POServiceClassification#> .
<http://www.w3.org/2002/ws/sawsdl/spec/examples/taxonomy/POServiceClassification#> rdf:type owl:Ontology .
:PurchaseOrderServices rdf:type owl:Class .
:OrderModification rdf:type owl:Class;
rdfs:subClassOf :PurchaseOrderServices .
:ItemAvailabilityCheck rdf:type owl:Class;
rdfs:subClassOf :PurchaseOrderServices .
:OrderPlacement rdf:type owl:Class;
rdfs:subClassOf :PurchaseOrderServices .
:ProductInfoInquiry rdf:type owl:Class;
rdfs:subClassOf :PurchaseOrderServices .
:OrderTracking rdf:type owl:Class;
rdfs:subClassOf :PurchaseOrderServices .
Listing 2.1-1: A taxonomy to organize Web services related to checking, placing, and tracking purchase orders. This taxonomy is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/taxonomy/POServiceClassification.n3.
...
<wsdl:interface name="CheckItemAvailabilityRequestService"
sawsdl:modelReference="http://www.w3.org/2002/ws/sawsdl/spec/examples/taxonomy/POServiceClassification#ItemAvailabilityCheck">
...
</wsdl:interface>
...
Listing 2.1-2: Shows how a WSDL interface could be annotated with categorization information that could be used in publishing a Web service (for example, into a service registry)
Some taxonomies may not provide direct URIs for their categories and may require multiple pieces of information to identify the categories.In such a case, users can define such information as per the requirements and associate a modelReference to point to such user-defined taxonomic information. For example, if a particular taxonomy specifies two pieces of information namely, an identifier of the taxonomy and a unique non-URI code for every specific category in that taxonomy, then it can be defined as follows.
@prefix categorization: <http://www.w3.org/2002/ws/sawsdl/spec/examples/taxonomy/Categorization#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xs: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
categorization:Category rdf:type rdfs:Class .
categorization:hasValue rdf:type rdf:Property;
rdfs:domain categorization:Category;
rdf:range rdfs:Literal .
categorization:usesTaxonomy rdf:type rdfs:Property;
rdfs:domain categorization:Category;
rdf:range rdfs:Resource .
Listing 2.2-1: Schema for defining a taxonomy with specific properties. This scehma is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/taxonomy/Categorization.n3.
Then, an instance such as the one below in Listing 2.2-2 that adheres to the above schema in Listing 2.2-1 can be defined and either imported or inserted into the WSDL file whose interface (or operation) is to be annotated.
@prefix categorization: <http://www.w3.org/2002/ws/sawsdl/spec/examples/taxonomy/Categorization#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xs: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ex: <http://example.org/Categorization#> .
ex:Electronics rdf:type categorization:Category ;
categorization:hasValue "443112" ;
categorization:usesTaxonomy <http://naics.com/> .
Listing 2.2-2: An instance of a taxonomy defined using the schema defined in Listing 2.2-1.
The annotation can be associated with the interface of a Web service as follows.
<wsdl:interface name="CheckAvailabilityRequestService" sawsdl:modelReference="http://example.org/Categorization#Electronics"> ... </wsdl:interface>
Listing 2.2-3: A WSDL sample showing how a wsdl:interface could be annotated with taxonomy information defined in Listing 2.2-2.
Using similar modelReference annotation operations within an interface can also be annotated. SAWSDL does not specify any relationship between the categorization information specified at the level of an interface and the one that is specified on an operation that is contained within that interface. The example in Listing 2.2-4 below shows how an operation within a Web service interface could be annotated using the same 'categorization' scheme.
<wsdl:operation name="CheckAvailabilityRequestOperation" sawsdl:modelReference="http://www.w3.org/2002/ws/sawsdl/spec/examples/taxonomy/Categorization#Electronics" ... </wsdl:operation>
Listing 2.2-4: A WSDL sample showing how a wsdl:operation could be annotated with taxonomy information from Listing 2.2-2.
In this subsection, we discuss how one can use the categorization annotation information defined by using the mechanisms described in Section 2 to publish Web services in a UDDI registry. This is provided as an example for illustrative purpose. One can use similar mechanisms to publish the Web services in registries or repositories other than UDDI.
Following the example in Listing 2.2-2, one can define taxonomy references to point to a specific category, for example, defined in NAICS [NAICS] taxonomy that is registered in a UDDI registry as shown in Listing 2.3-1. This information can then be reused when a service (such as the CheckItemAvailability Service whose interface definition is shown in Listing 2.2-3) is published in the UDDI registry. In the following example we use the NAICS taxonomy registered in UDDI.
@prefix categorization: <http://www.w3.org/2002/ws/sawsdl/spec/examples/taxonomy/Categorization#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
ex:Electronics rdf:type categorization:Category ;
categorization:hasValue "443112" ;
categorization:usesTaxonomy <uddi:uddi.org:ubr:categorization:naics:2002> .
Listing 2.3-1: An instance of a taxonomy defined using the schema defined in Listing 2.2-1 that refers to NAICS taxonomy registered in UDDI registry.
To publish a Web service that is represented in SAWSDL in a UDDI registry, an automatic Web service publishing engine can dereference the taxonomy information from its interface and use that information to determine the correct category of a related taxonomy in the registry to publish the service to. For example, when publishing the service in UDDI V3, a category bag can be created to classify the service using this information. Listing 2.3-2 below shows the UDDI categoryBag structure that could be created from the categorization information in Listing 2.3-1.
<categoryBag>
<keyedReference
tModelKey="uddi:uddi.org:ubr:categorization:naics:2002"
keyName="Electronics"
keyValue="443112"/>
</categoryBag>
Listing 2.3-2: UDDI Category bag structure derived from the taxonomy instance in Listing 2.3-1.
In this section we have discussed the usage of modelReference concepts on an interface and operation for associating categorization relation information for illustrative purposes. Users may choose to use modelReferences on interfaces and operations for associating other, for instance behavioral, aspects with a service.
One of the main motivations for SAWSDL specification is to provide mechanisms using which semantic annotations can be added to WSDL documents so that these semantics can be used to help automate the matching and composition of Web services. In this section we present some examples to show how to add such annotations for use during Web service interface matching and composition. First we present an example to illustrate the use of annotations in Web service interface matching.
Consider the the following scenario. A requestor submits a request to verify the availability of an item from a preferred supplier. This request is represented as a CheckAvailabilityRequest WSDL (introduced in Listing 1.2-1). A service provider has a service to offer that enables the requesters to check for the availability of items it offers. This is called CheckInventoryService and is also represented as WSDL with the same name (also introduced in Listing 1.2-2). The request WSDL codifies the inputs it can supply and the outputs it expects of an item availability check service by the service provider. The service WSDL specifies the interface of a service that allows requesters to check for the availability of an inventory item by exposing the inputs it requires in order to provide item availability confirmation. At a high level the service offered by the service provider should match the request. However, the differences in the vocabulary used by the two services to represent their interfaces may prevent making a match. For example, the term itemCode used by the requester and the term SKU (Stock Keeping Unit) used by the provider are meant to uniquely identify the item in question. Also, the requester term qty and the provider term numBundles in this context may refer to the number of items (for the requester, it is the number of items being requested and for the provider, it is the number of items being offered). A matching engine may not have sufficient information to identify them as related terms unless explicitly specified. Semantic annotations, in cases such as these, could be significant. A simple case, if there were to be a common semantic model that can be used to annotate the WSDLs of the requester and the service provider as shown below (in Listings 3.1-1 and 3.1-2), then a semantic engine could use this information to match the two Web services. In this example, annotation is done using modelReference extensibility attribute defined in SAWSDL.
The WSDL sample shown below in Listing 3.1-1 represents one of the ways of semantically annotating WSDL document of the request for checking item availability.
<wsdl:description
targetNamespace="http://org1.example.com/wsdl/CheckAvailabilityRequestService/"
xmlns="http://org1.example.com/wsdl/CheckAvailabilityRequestService/"
xmlns:wsdl="http://www.w3.org/ns/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sawsdl="http://www.w3.org/2002/ws/sawsdl/spec/sawsdl#">
<wsdl:types>
<xsd:schema targetNamespace="http://org1.example.com/wsdl/CheckAvailabilityRequestService">
<xsd:element name="CheckAvailabilityRequestServiceRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="itemCode" type="xsd:string"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntology#PartNumber"/>
<xsd:element name="date" type="xsd:string"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntology#DueDate"/>
<xsd:element name="qty" type="xsd:float"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntology#Quantity/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CheckAvailabilityRequestServiceResponse" type="itemConfirmation"/>
<xsd:simpleType name="itemConfirmation"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntology#AvailabilityConfirmation">
<xsd:restriction base="xsd:boolean"/>
</xsd:simpleType>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="CheckAvailabilityRequestService">
<wsdl:operation name="checkAvailabilityRequestOperation" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="CheckAvailabilityRequestServiceRequest"/>
<wsdl:output element="CheckAvailabilityRequestServiceResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
Listing 3.1-1: A WSDL sample of a semantically annotated service request that shows the usage of modelReference. This WSDL is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/SemannCheckAvailabilityRequestService.wsdl.
The WSDL sample in Listing 3.1-2 represents a way of semantically annotating the WSDL document of the service offered by the service provider for checking item availability.
<wsdl:description
targetNamespace="http://org2.example.com/wsdl/CheckInventoryService/"
xmlns="http://org2.example.com/wsdl/CheckInventoryService/"
xmlns:wsdl="http://www.w3.org/ns/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sawsdl="http://www.w3.org/2002/ws/sawsdl/spec/sawsdl#"
xmlns:SampleOntology="http://org1.example.com/ontologies/SampleOntology#">
<wsdl:types>
<xsd:schema targetNamespace="http://org2.example.com/wsdl/CheckInventoryService">
<xsd:element name="CheckInventoryServiceRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SKU" type="xsd:string"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntology#SKU"/>
<xsd:element name="deliveryDate" type="xsd:string"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntology#DueDate"/>
<xsd:element name="numBundles" type="xsd:float"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntology#Quantity"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CheckInventoryServiceResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="conf" type="xsd:boolean"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntology#AvailabilityConfirmation"/>
<xsd:element name="numBundles_available" type="xsd:string"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntology#Quantity"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="CheckInventoryService">
<wsdl:operation name="checkInventoryOperation" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="CheckInventoryServiceRequest"/>
<wsdl:output element="CheckInventoryServiceResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
Listing 3.1-2: A WSDL sample of a semantically annotated service (advertisement) that shows the usage of modelReference. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/SemannCheckInventoryService.wsdl.
In this example both WSDL documents are annotated with concepts from the same semantic model SampleOntology (shown in Listing 3.1-3). The ontology contains the relationship between the concepts PartNumber and SKU i.e., a SKU Code is a subClassOf PartNumber. A semantic engine can use this relationship during Web service interface matching by parsing and reasoning over this semantic model. Therefore, the WSDL elements 'itemCode' in the request WSDL and the 'SKU' in the service WSDL match with one another. In the case of the other input elements namely 'qty' vs 'numBundles' and 'date' vs 'deliveryDate', since both these sets of elements are annotated with shared semantic concepts namely 'Quantity' and 'DueDate' respectively the semantic ambiguity can be resolved by direct matching of semantic annotations. The same applies to matching outputs as well. The ontology that represents the subClassOf relationship between the two concepts PartNumber and SKU can be modeled in OWL as follows.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix: <http://org1.example.com/ontologies/SampleOntology#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
<http://org1.example.com/ontologies/SampleOntology#> rdf:type owl:Ontology .
:PartNumber rdf:type owl:Class .
:SKU rdf:type owl:Class;
rdfs:subClassOf :PartNumber .
:Quantity rdf:type owl:Class .
:DueDate rdf:type owl:Class .
:AvailabilityConfirmation rdf:type owl:Class .
Listing 3.1-3: A simple SampleOntology that captures the subClassOf relationship between PartNumber and SKU concepts. This sample ontology is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/ontologies/SampleOntology.n3.
In Section 3.1 we made a shared ontology assumption between the requester and service provider domains. This assumption may not always hold good. The vocabulary differences may result in two different ontologies one for each side albeit for the same domain. In such a case one can create a mapping ontology by capturing the relationships between the concepts used in the different ontologies. Below we annotate the same two request and advertisement WSDLs using concepts from different ontologies. When a mapping ontology such as the one shown in Listing 3.2-5 is available, then the semantic annotations extracted from the request and the advertisement WSDL can be matched using such a mapping ontology.
The WSDL sample shown below in Listing 3.2-1 represents one of the ways of semantically annotating WSDL document of the request for checking item availability.
<wsdl:description
targetNamespace="http://org1.example.com/wsdl/CheckAvailabilityRequestService/"
....
xmlns:Org1Ont="http://org1.example.com/ontologies/SampleOntologyOrg1#>
<wsdl:types>
<xsd:schema targetNamespace="http://org1.example.com/wsdl/CheckAvailabilityRequestService">
<xsd:element name="CheckAvailabilityRequestServiceRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="itemCode" type="xsd:string"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntologyOrg1#PartNumber"/>
<xsd:element name="date" type="xsd:string"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntologyOrg1#DueDate"/>
<xsd:element name="qty" type="xsd:float"
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntologyOrg1#Quantity/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CheckAvailabilityRequestServiceResponse type="itemConfirmation"/>
<xsd:simpleType name="itemConfirmation">
sawsdl:modelReference="http://org1.example.com/ontologies/SampleOntologyOrg1#AvailabilityConfirmation"
<xsd:restriction base:"xsd:boolean"/>
</xsd:simpleType>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="CheckAvailabilityRequestService">
<wsdl:operation name="checkAvailabilityRequestOperation" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="CheckAvailabilityRequestServiceRequest"/>
<wsdl:output element="CheckAvailabilityRequestServiceResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
Listing 3.2-1: A WSDL sample of a semantically annotated service request that shows the usage of modelReference. This WSDL is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/SemannCheckAvailabilityRequestService.wsdl.
The WSDL sample shown below in Listing 3.2-2 represents a way of semantically annotating the WSDL document of the service offered by the service provider for checking item availability.
<wsdl:description
targetNamespace="http://org2.example.com/wsdl/CheckInventoryService/"
.....
xmlns:Org2Ont="http://org2.example.com/ontologies/SampleOntologyOrg2#>
<wsdl:types>
<xsd:schema targetNamespace="http://org2.example.com/wsdl/CheckInventoryService">
<xsd:element name="CheckInventoryServiceRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SKU" type="xsd:string"
sawsdl:modelReference="http://org2.example.com/ontologies/SampleOntologyOrg2#SKU"/>
<xsd:element name="deliveryDate" type="xsd:string"
sawsdl:modelReference="http://org2.example.com/ontologies/SampleOntologyOrg2#DeliveryDate"/>
<xsd:element name="numBundles" type="xsd:float"
sawsdl:modelReference="http://org2.example.com/ontologies/SampleOntologyOrg2#NumBundles/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CheckInventoryServiceResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="conf" type="xsd:boolean"
sawsdl:modelReference="http://org2.example.com/ontologies/SampleOntologyOrg2#AvailabilityConfirmation"/>
<xsd:element name="numBundles_available" type="xsd:string"
sawsdl:modelReference="http://org2.example.com/ontologies/SampleOntologyOrg2#NumBundles"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="CheckInventoryService">
<wsdl:operation name="checkInventoryOperation" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="CheckInventoryServiceRequest"/>
<wsdl:output element="CheckInventoryServiceResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
Listing 3.2-2: A WSDL sample of a semantically annotated service (advertisement) that shows the usage of modelReference. This WSDL is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/SemannCheckInventoryService2.wsdl.
As noted, in this case the concepts originating from different ontologies represented in the two WSDLs shown above are mapped in a mapping ontology such as the one shown below in Listing 3.2-5. It contains relationships between concepts such as Quantity & NumBundles and Due Date & DeliveryDate and PartNumber & SKU. Just as in the example in Section 3.1, a semantic matching engine can now be applied to reason over these relationships during Web service interface matching. The relationships between the concepts in this mapping ontology are shown pictorially in Figure 1 below.
Below, we list the three ontologies that are used in matching the checkAvailabilityRequest() request WSDL with the checkInventoryService() advertisement WSDL. The first ontology shown in Listing 3.2-3 is the one used by the requesting organization (referred to using the namespace http://org1.example.com/ontologies/SampleOntology) that defined the checkAvailabilityRequest() request WSDL. The second ontology shown in Listing 3.2-4 is the one used by the service advertising organization (referred to using the namespace http://org2.example.com/ontologies/SampleOntologyOrg2) that defined the checkInventoryService() advertisement WSDL. The third one shown in Listing 3.2-5 is the mapping ontology defined by a third organization (could possibly be defined by either of the first two organizations as well) that relates the concepts from the two ontologies defined by org1 and org2.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix: <http://org1.example.com/ontologies/SampleOntologyOrg1#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . <http://org1.example.com/ontologies/SampleOntologyOrg1#> rdf:type owl:Ontology . :PartNumber rdf:type owl:Class . :DueDate rdf:type owl:Class . :Quantity rdf:type owl:Class . :AvailabilityConfirmation rdf:type owl:Class .
Listing 3.2-3:Sample Ontology used by the organization that defined checkAvailabilityRequest() request WSDL. This ontology is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/ontologies/SampleOntologyOrg1.n3.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix: <http://org2.example.com/ontologies/SampleOntologyOrg2#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . <http://org2.example.com/ontologies/SampleOntologyOrg2#> rdf:type owl:Ontology . :SKU rdf:type owl:Class . :DeliveryDate rdf:type owl:Class . :NumBundles rdf:type owl:Class . :AvailabilityConfirmation rdf:type owl:Class .
Listing 3.2-4:Sample Ontology used by the organization that defined checkInventoryService() advertisement WSDL. This ontology is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/ontologies/SampleOntologyOrg2.n3.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix: <http://org3.example.com/ontologies/MappingOntology#> . @prefix Org1Ont: <http://org1.example.com/ontologies/SampleOntologyOrg1#> . @prefix Org2Ont: <http://org2.example.com/ontologies/SampleOntologyOrg2#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . <http://org3.example.com/ontologies/MappingOntology#> rdf:type owl:Ontology . Org2Ont:SKU rdfs:subClassOf Org1Ont:PartNumber . Org2Ont:NumBundles owl:equivalentClass Org1Ont:Quantity . Org2Ont:DeliveryDate owl:equivalentClass Org1Ont:DueDate . Org2Ont:AvailabilityConfirmation owl:equivalentClass Org1Ont:AvailabilityConfirmation .
Listing 3.2-5: Sample Ontology showing the mapping ontology mapping concepts from ontologies in Listings 3.2-3 and 3.2-4. This mapping ontology is used to match the request WSDL in Listing 3.2-1 with the advertisement WSDL in Listing 3.2-2. This ontology is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/ontologies/MappingOntology.n3.
Figure 1: A pictorial representation of a sample mapping ontology that can be used to match the request WSDL in Listing 3.2-1 with the advertisement WSDL in Listing 3.2-2
It is to be noted that SAWSDL specifies mechanisms to annotate WSDLs but does not say anything about how these annotations are generated. These annotations can either be created manually or by tools that can infer relationships between the terms used in the WSDLs and those that are given in a semantic model. Also, SAWSDL does not say anything about how the semantic models themselves are created. Just like the creation of annotations, these semantic models can either be created manually by a human expert or generated automatically using ontology learning tools or by a combination of both.
In the next section, we extend the above item availability check example to show how semantic annotations added to a WSDL can be used to compose Web services.
This section illustrates how semantic annotations can be used to compose Web services. The request and advertisement WSDLs to be considered in this scenario are the same as the ones shown in Listings 3.2-1 and 3.2-2 respectively. However, we introduce a variation to the mapping ontology from Section 3.2. Suppose that in the item availability checking scenario that we have been discussing so far, the subClassOf relationship between the concepts PartNumber and SKU is unspecified in the ontology. In this case, the request checkAvailabilityRequest() would not match with the service checkInventoryService() because there is no relationship between PartNumber and SKU. Also, suppose that there is another Web service called PartNumber2SKULookup() that can take a PartNumber as input and produce SKU as output (Listing 3.3-1). Say that a matching engine would be able to find this service in the appropriate category in a registry - in this case it would be in 'Utilities/LookupServices' category (because the modelReference on the operation of this service contains the categorization information. Presumably a publishing agent/program would have placed this service in the appropriate category that is referred to by the modelReference URI). Also, a mapping ontology such as the one shown in Listing 3.3-2 is available for the matching engine. The service PartNumber2SKULookup() can be composed with checkInventoryService() to match the request checkAvailabilityRequest() as shown in Figure 2. This can be achieved by simply extracting the semantic annotations from the request, and all the advertisement WSDLs and using the relationships in the mapping ontology to match the corresponding concepts. A simple Web service composition using the semantics annotations on the request and advertisement services is illustrated in Figure 2.
<wsdl:description
targetNamespace="http://org3.example.com/wsdl/PartNumber2SKULookupService/"
xmlns="http://org3.example.com/wsdl/PartNumber2SKULookupService/"
xmlns:wsdl="http://www.w3.org/ns/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sawsdl="http://www.w3.org/2002/ws/sawsdl/spec/sawsdl#"
xmlns:Org3Ont="http://org3.example.com/ontologies/SampleOntologyOrg3#">
<wsdl:types>
<xsd:schema targetNamespace="http://org3.example.com/wsdl/PartNumber2SKULookupService">
<xsd:element name="PartNumber2SKULookupServiceRequest" type="partNum"/>
<xsd:simpleType name="partNum">
sawsdl:modelReference="http://org3.example.com/ontologies/SampleOntologyOrg3#PartNumber">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:element name="PartNumber2SKULookupServiceResponse" type="SKU"/>
<xsd:simpleType name="SKU">
sawsdl:modelReference="http://org3.example.com/ontologies/SampleOntologyOrg3#SKU">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="PartNumber2SKULookupService">
<wsdl:operation name="PartNumber2SKULookupService" pattern="http://www.w3.org/ns/wsdl/in-out"
sawsdl:modelReference="http://org3.example.com/taxonomies/Utilities#LookupServices">
<wsdl:input element="PartNumber2SKULookupServiceRequest"/>
<wsdl:output element="PartNumber2SKULookupServiceResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
Listing 3.3-1: A WSDL sample representing PartNumber2SKULookup service. This WSDL is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/PartNumber2SKULookupService.wsdl.
Listing 3.3-2 below shows the variation on the mapping ontology discussed in Section 3.2. As noted, this ontology does not contain any relationship between PartNumber and SKU concepts. The additional differences from Listing 3.2-5 are shown below in bold font style. In this example, we assume that the same organization that provides the PartNumber2SKULookupService() provides the mapping ontology. In practice, this does not have to be the case. Any of the three organizations (org1, org2, and org3 referred to in the namespaces) or an entirely new organization (org4) can provide a mapping ontology. The namespaces, in such a case, should reflect the change accordingly. The ontologies that are used to annotate the request WSDL checkAvailabilityRequest() and the advertisement WSDL checkInventoryService() are unchanged from those presented in Listing 3.2-3 and 3.2-4.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix: <http://org1.example.com/ontologies/MappingOntology#> .
@prefix Org1Ont: <http://org1.example.com/ontologies/SampleOntologyOrg1#> .
@prefix Org2Ont: <http://org2.example.com/ontologies/SampleOntologyOrg2#> .
@prefix Org3Ont: <http://org3.example.com/ontologies/SampleOntologyOrg3#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
<http://org3.example.com/ontologies/MappingOntology#> rdf:type owl:Ontology .
Org2Ont:NumBundles rdf:type owl:Class;
owl:equivalentClass Org1Ont:Quantity .
Org2Ont:DeliveryDate rdf:type owl:Class;
owl:equivalentClass Org1Ont:DueDate .
Org2Ont:AvailabilityConfirmation rdf:type owl:Class;
owl:equivalentClass Org1Ont:AvailabilityConfirmation .
Org3Ont:PartNumber rdf:type owl:Class;
owl:equivalentClass Org1Ont:PartNumber .
Org3Ont:SKU rdf:type owl:Class;
owl:equivalentClass Org2Ont:SKU .
Listing 3.3-2: Revised Mapping Ontology that contains relationships between concepts from three different ontologies. This ontology is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/ontologies/RevisedMappingOntology.n3.
Figure 2. Simple Web service composition using the semantic annotations on the request and advertisement services.
We introduce three variations to our item availability checking scenario in this section to illustrate how one can use semantic annotations to compose Web services with ontology reasoning. First, suppose that we have a checkInventoryService() that takes an UPC as input inplace of SKU (as introduced in Listing 1.2-2 but with semantic annotations as in Listing 3.4-1 below). This service will not match the request checkAvailabilityRequest() (unchanged from Listing 3.2-1) because there is no relationship between the concepts PartNumber and UPC in the mapping ontology. Even semantic annotations will not be able to help in matching the request checkAvailabilityRequest() and the advertisement checkInventoryService(). Second, say that there is another Web service called SKU2UPCLookup() that can take an SKU as input and produce UPC (Universal Product Code) as output (Listing 3.4-2). Third, the original mapping ontology introduced in Listing 3.2-3 has an addition of UPC concept. But it is to be noted that the ontology does not specify any relationship between SKU and UPC codes. Figure 3 summarizes the relationships between the concepts PartNumber, SKU, and UPC in SampleOntology. Now with these three variations, we have enough information to see how a semantic engine can compose Web services to match the request checkAvailabilityRequest() with checkInventoryService().
<wsdl:description
targetNamespace="http://org2.example.com/wsdl/CheckInventoryService/"
....
xmlns:Org2Ont="http://org2.example.com/ontologies/SampleOntologyOrg2#">
<wsdl:types>
<xsd:schema targetNamespace="http://org2.example.com/wsdl/CheckInventoryService">
<xsd:element name="CheckInventoryServiceRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="UPC" type="xsd:string"
sawsdl:modelReference="http://org2.example.com/ontologies/SampleOntologyOrg2#UPC"/>
<xsd:element name="deliveryDate" type="xsd:string"
sawsdl:modelReference="http://org2.example.com/ontologies/SampleOntologyOrg2#DeliveryDate"/>
<xsd:element name="numBundles" type="xsd:float"
sawsdl:modelReference="http://org2.example.com/ontologies/SampleOntologyOrg2#NumBundles"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CheckInventoryServiceResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="conf" type="xsd:boolean"
sawsdl:modelReference="http://org2.example.com/ontologies/SampleOntologyOrg2#AvailabilityConfirmation"/>
<xsd:element name="numBundles_available" type="xsd:string"
sawsdl:modelReference="http://org2.example.com/ontologies/SampleOntologyOrg2#NumBundles"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="CheckInventoryService">
<wsdl:operation name="checkInventoryOperation" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="CheckInventoryServiceRequest"/>
<wsdl:output element="CheckInventoryServiceResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
Listing 3.4-1: CheckInventoryService() WSDL sample with a variation where the input SKU is replaced by UPC for the purpose of illustrating Web service composition with ontology reasoning. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/SemannCheckInventoryService2.wsdl.
A WSDL sample of SKU2UPCLookupService() is shown below.
<wsdl:description
targetNamespace="http://org3.example/com/wsdl/SKU2UPCLookupService/"
.....
xmlns:Org3Ont="http://org3.example.com/ontologies/SampleOntologyOrg3#">
<wsdl:types>
<xsd:schema targetNamespace="http://org3.example.com/wsdl/SKU2UPCLookupService">
<xsd:element name="SKU2UPCLookupServiceRequest" type="SKU"/>
<xsd:simpleType name="SKU">
sawsdl:modelReference="http://org3.example.com/ontologies/SampleOntologyOrg3#SKU">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:element name="SKU2UPCLookupServiceResponse" type="UPC"/>
<xsd:simpleType name="UPC">
sawsdl:modelReference="http://org3.example.com/ontologies/SampleOntologyOrg3#UPC">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="SKU2UPCLookupService">
<wsdl:operation name="SKU2UPCLookupService" pattern="http://www.w3.org/ns/wsdl/in-out"
sawsdl:modelReference="http://org3.example.com/taxonomies/Utilities#LookupServices">
<wsdl:input element="SKU2UPCLookupServiceRequest"/>
<wsdl:output element="SKU2UPCLookupServiceResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
Listing 3.4-2: A WSDL sample representing SKU2UPCLookup service. This WSDL is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/SKU2UPCLookupService.wsdl.
Below, we list the three ontologies that are used in matching the checkAvailabilityRequest() request WSDL with the checkInventoryService() advertisement WSDL according to the scenario described in this section. The first ontology shown in Listing 3.4-3 is the one used by the requesting organization (referred to using the namespace http://org1.example.com/ontologies/SampleOntologyOrg1) that defined the checkAvailabilityRequest() request WSDL. Please note that this differs from the Listing in 3.2-3 because this ontology contains the 'subClassOf' relationship between SKU and PartNumber concepts. The second ontology shown in Listing 3.4-4 is the one used by the service advertising organization (referred to using the namespace http://org2.example.com/ontologies/SampleOntologyOrg2) that defined the checkInventoryService() advertisement WSDL. Please note that this differs from the Listing in 3.2-4 because this contains the concept UPC instead of SKU. The third one shown in Listing 3.2-5 is the mapping ontology defined by a third organization (could possibly be defined by either of the first two organizations as well) that relates the concepts from the two ontologies defined by org1 and org2.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix: <http://org1.example.com/ontologies/SampleOntologyOrg1#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
<http://org1.example.com/ontologies/SampleOntologyOrg1#> rdf:type owl:Ontology .
:PartNumber rdf:type owl:Class .
:SKU rdf:type owl:Class;
rdfs:subClassOf :PartNumber .
:DueDate rdf:type owl:Class .
:Quantity rdf:type owl:Class .
:AvailabilityConfirmation rdf:type owl:Class .
Listing 3.4-3:Sample Ontology used by the organization that defined checkAvailabilityRequest() request WSDL. This ontology is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/ontologies/SampleOntologyOrg1.n3.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix: <http://org2.example.com/ontologies/SampleOntologyOrg2#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . <http://org2.example.com/ontologies/SampleOntologyOrg2#> rdf:type owl:Ontology . :UPC rdf:type owl:Class; :DeliveryDate rdf:type owl:Class . :NumBundles rdf:type owl:Class . :AvailabilityConfirmation rdf:type owl:Class .
Listing 3.4-4: Sample Ontology used by the organization that defined checkInventoryService() advertisement WSDL. This ontology is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/ontologies/SampleOntologyOrg2.n3.
Listing 3.4-5 represents the updated sample ontology that enables composition in this example. It relates the concepts in the ontologies shown in Listings 3.4-3 and 3.4-4. Note that the ontology as such does not specify any relationship between SKU and UPC. Given a SKU, its corresponding UPC code is retrieved by the Web service SKU2UPCLookup(). Here also, we assume that the organization that is providing the SKU2UPCLookupService() is providing the mapping ontology as well. As mentioned earlier in Section 3.3, this does not always have to be the case.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix: <http://org1.example.com/ontologies/MappingOntology#> .
@prefix Org1Ont: <http://org1.example.com/ontologies/SampleOntologyOrg1#> .
@prefix Org2Ont: <http://org2.example.com/ontologies/SampleOntologyOrg2#> .
@prefix Org3Ont: <http://org3.example.com/ontologies/SampleOntologyOrg3#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
<http://org3.example.com/ontologies/MappingOntology#> rdf:type owl:Ontology .
Org2Ont:NumBundles owl:equivalentClass Org1Ont:Quantity .
Org2Ont:DeliveryDate owl:equivalentClass Org1Ont:DueDate .
Org2Ont:AvailabilityConfirmation owl:equivalentClass Org1Ont:AvailabilityConfirmation .
Org3Ont:SKU rdf:type owl:Class;
owl:equivalentClass Org1Ont:SKU .
Org3Ont:UPC rdf:type owl:Class;
owl:equivalentClass Org2Ont:UPC .
Listing 3.4-5: Revised Mapping Ontology that contains relationships between concepts PartNumber, SKU, and UPC among other things that is used in this section to illustrate Web service composition using ontology reasoning. This ontology is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/ontologies/RevisedMappingOntology.n3.
Figure 3 represents an altered version of the ontology that enables composition in this example.
Figure 3: An altered version of the simple sample retail ontology that enables composition
Figure 4 shows how Web service composition can be achieved by using the semantic annotations in the WSDL files discussed in this example. As can be noted, in this scenario, a semantic engine retrieves the semantic annotations from checkAvailabilityRequest() for element itemCode namely PartNumber and for the element SKU in SKU2UPCLookup() service namely SKU. The annotation PartNumber does not match lexically with the concept SKU. So, the semantic engine could then consult the MappingOntology to see if there is any relationship between PartNumber and SKU. The ontology reasoner can return the existence of 'subClassOf' relationship between SKU and PartNumber. This information can then be used in composing SKU2UPCLookup() with CheckInventoryService() as shown in Figure 4 to match the request CheckAvailabilityRequest(). Again, as mentioned earlier in Section 3.3, a matching engine would be able to find a utility service such as SKU2UPCLookup() in the appropriate category in a registry - in this case it would be in 'Utilities/LookupServices' category because the modelReference on the operation of this service contains the categorization information. So, presumably a publishing agent/program would have placed this service in the appropriate category that is referred to by the modelReference URI.
Figure 4: A Web Service Composition Scenario with Ontology Reasoning
The example presented in this section was a variation of the one discussed in Section 3.4. It illustrated how Web service composition can be achieved using the relationships between concepts in an ontology even when the semantic annotations on the services don't match directly.
SAWSDL allows multiple annotations to be associated with those WSDL elements that can have a modelReference extension. These annotations could be pointing to different concepts from the same semantic model or from different models altogether. For example, a WSDL element with the name itemCode can be associated with SampleOntology#PartNumber and SampleOntology#SKU concepts. SAWSDL does not specify any relationship between these multiple annotations other than saying that they all apply. It is up to the consumers of these annotated WSDLs to use the ones that are relevant to them or to figure out the relationship between the concepts, if they so choose, by consulting the ontology that defines them. The following example in Listing 3.5-1 shows the annotation of itemCode with multiple annotations. If a requesting WSDL is annotated with multiple concepts like shown in Listing 3.5-1, this increases the likelihood of matching this request with other advertisement/service WSDLs. Similarly, if a service WSDL is annotated with multiple concepts, possibly more request WSDLs will match it.
...
<xsd:simpleType name="itemCode"
sawsdl:modelReference="http://org3.example.com/ontologies/SampleOntologyOrg3#PartNumber
http://org3.example.com/ontologies/SampleOntologyOrg3#SKU"/>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
...
Listing 3.5-1: A WSDL sample showing multiple annotations to a simple type
The example given in this section so far illustrated multiple annotations that come from the same ontology. It is possible for elements to be annotated with concepts from different ontologies as well. The mechanism for doing so is exactly the same as the one employed in Listing 3.5-1 except in the latter case, the namespaces for the concepts coming from different ontolgies would be different.
In the examples that we discussed so far, all annotations are added at the member element levels of a complex type. SAWSDL allows annotations to be added either at the complex type level (top level) or at the member element level (bottom level) or both. In cases where both complex type and the member elements have annotations, SAWSDL does not specify any relationship between the modelReferences on a complex type and those on the elements contained within a complex type. The listing below (Listing 3.6-1) illustrates the usage of modelReference for annotating the complex type 'ItemRequest' as well as the member elements.
<wsdl:types>
...
<xsd:element name="ItemRequest"
sawsdl:modelReference="http://org3.example.com/ontologies/SampleOntologyOrg3#OrderItem">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="itemCode" type="xsd:string"/>
<xsd:element name="date" type="xsd:string"/>
<xsd:element name="qty" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
...
</wsdl:types>
Listing 3.6-1: A WSDL sample from CheckAvailabilityRequest() showing the annotation of a complexType.
Here is one possible way in which the annotation on a complex type can be used. The annotation on the complex type 'itemRequest' such as the one in Listing 3.6-1 which is part of checkAvailabilityRequest() can be used to match another complex type such as the one in checkInventoryService() shown in Listing 3.6-2 below. The annotation on a complex type can be used a first level of matching in structure matching i.e., a semantic matching engine could use these annotations to see if two complex types have any relationship at all. If they do, perhaps spending more time on matching the member elements of complex types may be worth the time. If not, perhaps there is no need to do detailed matching of complex structures. Therefore, the annotations on complex types can be used for first level of structure matching.
<wsdl:types>
...
<xsd:element name="Item"
sawsdl:modelReference="http://org3.example.com/ontologies/SampleOntologyOrg3#OrderItem">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SKU" type="xsd:string"/>
<xsd:element name="deliveryDate" type="xsd:string"/>
<xsd:element name="numBundles" type="xsd:float"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
...
</wsdl:types>
Listing 3.6-2: A WSDL sample from CheckInventoryService() showing the annotation of a compex type.
We have discussed how to annotate WSDL documents with semantic concepts for use in Web service discovery, matching and composition.These annotations that can be added to a WSDL using modelReferences are meant to add semantic clarity to WSDL elements by pointing to concepts in a semantic model that describes the larger context. They help understand whether a service matches clients' requests at a semantic level. However, there may still be mismatches at the data level that would need to be addressed and captured to enable the invocation of a Web service. In the following section, we discuss the mechanisms defined in SAWSDL to capture such data transformation maps (knowns as schema mappings) to enable Web service invocation.
The modelReference attribute can be used to represent behavioral constraints related with services. For example, in the purchase order scenario, if we were to add constraints as shown below related to shipping details, they can be represented in SAWSDL using modelReferences as shown in Listing 3.7-1.
We would like to represent the following effects on the outputs of a purchase order service.
Listings 3.7-1 captures these shipment conditions in SWRL abstract syntax. Listing 3.7-2 presents the same rule in human-readable syntax and Listing 3.7-3 encodes them in XML concrete syntax. The listing also contains an OWL ontology which represents the concepts such as 'shipment', 'continent', 'country' etc. that are used in the rules. Listing 3.7-4 presents the same rule in WSML syntax.
Implies (Antecedent (
swrlb:substract (2 I-variable(deliveryDay) I-variable(orderDay))
I-variable(hour) swrlb:greaterThanOrEqual 7
I-variable(hour) swrlb:lessThanOrEqual 20
I-variable(continent) swrlb:equal (http://en.wikipedia.org/wiki/North_america)
I-variable(weight) swrlb:lessThanOrEqual 50
)
Consequent (shipment(I-variable(package) true))
Implies (Antecedent (
swrlb:substract (2 I-variable(deliveryDay) I-variable(orderDay))
I-variable(hour) swrlb:greaterThanOrEqual 7
I-variable(hour) swrlb:lessThanOrEqual 20
I-variable(continent) swrlb:equal (http://en.wikipedia.org/wiki/Europe)
I-variable(weight) swrlb:lessThanOrEqual 50
)
Consequent (shipment(I-variable(package) true))
Note: syntax subject to verification!
Listing 3.7-1: A SWRL abstract syntax representation of the rules as described above. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/rule/shipmentRuleAbstract.swrlx.
waitingTime (≥ 2 ?deliveryDay, ?orderDay)
^ deliveryTime (≥ 7 ?hour)
^ deliveryTime (≤ 20 ?hour)
^ packageWeight (≤ 50 ?wright)
^ deliveryLocation(?continent, "http://en.wikipedia.org/wiki/North_america")
=> shipment(?package)
waitingTime (≥ 2 ?deliveryDay, ?orderDay)
^ deliveryTime (≥ 7 ?hour)
^ deliveryTime (≤ 20 ?hour)
^ packageWeight (≤ 50 ?wright)
^ deliveryLocation(?continent, "http://en.wikipedia.org/wiki/Europe")
=> shipment(?package)
Note: syntax subject to verification!
Listing 3.7-2: A SWRL human-readable syntax representation of the rules as described above. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/rule/shipmentRuleHR.swrlx.
<?xml version="1.0" encoding="utf-8"?>
<!-- background knowledge about shipment -->
<owl:Class rdf:ID="shipment"/>
<owl:Class rdf:ID="order"/>
<owl:Class rdf:ID="package"/>
<owl:Class rdf:ID="continent"/>
<owl:Class rdf:ID="country">
<rdfs:subClassOf rdf:resource="#continent">
</owl:Class>
<owl:DatatypeProperty rdf:ID="orderDate">
<rdfs:domain rdf:resource="#shipment"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="deliveryDate">
<rdfs:domain rdf:resource="#shipment"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="packageWeight">
<rdfs:domain rdf:resource="#shipment"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="deliveryHour">
<rdfs:domain rdf:resource="#shipment"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#dateTime"/>
</owl:DatatypeProperty>
<owl:ObjectProperty rdf:ID="deliveryLocation">
<rdfs:domain rdf:resource="#shipment"/>
<rdfs:range rdf:resource="#country"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasOrder">
<rdfs:domain rdf:resource="#package"/>
<rdfs:range rdf:resource="#order"/>
</owl:ObjectProperty>
<ruleml:imp>
<ruleml:_rlab ruleml:href="#inputRule"/>
<owlx:Annotation>
<owlx:Documentation>
Only packages weighing 50 lbs or less can be shipped.
Shipping is possible only in North America, and Europe.
Delivery is possible only between 7am and 8pm.
Delivery has to be ordered at least 2 working days in advance.
</owlx:Documentation>
</owlx:Annotation>
<ruleml:_body>
<!-- compute waiting time: diff of deliveryDate and orderDate -->
<swrlx:builtinAtom swrlx:builtin="swrlb:subtractDates">
<ruleml:var>waitingTime</ruleml:var>
<ruleml:var>deliveryDate</ruleml:var>
<ruleml:var>orderDate</ruleml:var>
</swrlx:builtinAtom>
<!-- waiting time should be greater-than 2 -->
<swrlx:builtinAtom swrlx:builtin="swrlb:greaterThanOrEqual">
<ruleml:var>waitingTime</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:int">2</owlx:DataValue>
</swrlx:builtinAtom>
<!-- only delivery between 07:00-20:00 -->
<swrlx:builtinAtom swrlx:builtin="swrlb:greaterThanOrEqual">
<ruleml:var>deliveryHour</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:time">T7H</owlx:DataValue>
</swrlx:builtinAtom>
<swrlx:builtinAtom swrlx:builtin="swrlb:lessThanOrEqual">
<ruleml:var>deliveryHour</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:time">T20H</owlx:DataValue>
</swrlx:builtinAtom>
<!-- only deliver things below 50 pounds -->
<swrlx:builtinAtom swrlx:builtin="swrlb:lessThanOrEqual">
<ruleml:var>packageWeight</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:int">50</owlx:DataValue>
</swrlx:builtinAtom>
<!-- compute places where package can be delivered -->
<swrlx:builtinAtom swrlx:builtin="swrlb:listConcate">
<ruleml:var>memberCountries</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:list">http://en.wikipedia.org/wiki/North_america</owlx:DataValue>
<owlx:DataValue owlx:datatype="xsd:list">http://en.wikipedia.org/wiki/Europe</owlx:DataValue>
</swrlx:builtinAtom>
<!-- only delivery to Europe or NorthAmerica -->
<swrlx:builtinAtom swrlx:builtin="swrlb:member">
<ruleml:var>deliveryLocation</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:list">memberCountries</owlx:DataValue>
</swrlx:builtinAtom>
</ruleml:_body>
</ruleml:imp>
<ruleml:imp>
<ruleml:_rlab ruleml:href="#outputRule1"/>
<owlx:Annotation>
<owlx:Documentation>
If more than 50lbs was ordered, order is taken only for 50lbs
</owlx:Documentation>
</owlx:Annotation>
<ruleml:_body>
<swrlx:individualPropertyAtom swrlx:property="hasOrder">
<ruleml:var>order</ruleml:var>
<ruleml:var>packageWeight</ruleml:var>
</swrlx:individualPropertyAtom>
<swrlx:builtinAtom swrlx:builtin="swrlb:greaterThan">
<ruleml:var>packageWeight</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:int">50</owlx:DataValue>
</swrlx:builtinAtom>
</ruleml:_body>
<ruleml:_head>
<swrlx:individualPropertyAtom swrlx:property="hasOrder">
<ruleml:var>order</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:int">50</owlx:DataValue>
</swrlx:individualPropertyAtom>
</ruleml:_head>
</ruleml:imp>
<ruleml:imp>
<ruleml:_rlab ruleml:href="#outputRule2"/>
<owlx:Annotation>
<owlx:Documentation>
ItemConfirmation # can be tracked only for 30 days after the order was placed
</owlx:Documentation>
</owlx:Annotation>
<ruleml:_body>
<swrlx:builtinAtom swrlx:builtin="swrlb:subtractDates">
<ruleml:var>trackingTime</ruleml:var>
<ruleml:var>orderDate</ruleml:var>
<ruleml:var>currentDate</ruleml:var>
</swrlx:builtinAtom>
<swrlx:builtinAtom swrlx:builtin="swrlb:greaterThanOrEqual">
<ruleml:var>trackingTime</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:time">T30H</owlx:DataValue>
</swrlx:builtinAtom>
</ruleml:_body>
<ruleml:_head>
<swrlx:individualPropertyAtom swrlx:property="itemConfirmationID">
<ruleml:var>order</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:String">null</owlx:DataValue>
</swrlx:individualPropertyAtom>
</ruleml:_head>
</ruleml:imp>
<ruleml:imp>
<ruleml:_rlab ruleml:href="#outputRule3"/>
<owlx:Annotation>
<owlx:Documentation>
If the order does not arrive the shipping location within the required date,
no charge will be made to the account.
</owlx:Documentation>
</owlx:Annotation>
<ruleml:_body>
<swrlx:builtinAtom swrlx:builtin="swrlb:subtractDates">
<ruleml:var>arrivalDate</ruleml:var>
<ruleml:var>deliveryDate</ruleml:var>
<ruleml:var>currentDate</ruleml:var>
</swrlx:builtinAtom>
<swrlx:builtinAtom swrlx:builtin="swrlb:greaterThan">
<ruleml:var>arrivalDate</ruleml:var>
<ruleml:var>deliveryDate</ruleml:var>
</swrlx:builtinAtom>
</ruleml:_body>
<ruleml:_head>
<swrlx:individualPropertyAtom swrlx:property="payment">
<ruleml:var>order</ruleml:var>
<owlx:DataValue owlx:datatype="xsd:boolean">false</owlx:DataValue>
</swrlx:individualPropertyAtom>
</ruleml:_head>
</ruleml:imp>
Note: syntax subject to verification!
Listing 3.7-3: A SWRL represention of the rules as described above. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/rule/shipmentRule.swrlx.
wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-full"
namespace { _"http://example.org#",
dc _"http://purl.org/dc/elements/1.1#",
onto _"http://example.org/ontology#",
wsml _"http://www.wsmo.org/wsml/#"
}
ontology _"http://www.example.org/ontologies/example"
axiom shipmentRule definedBy
?p[weight hasValue ?w, address hasValue ?a] memberOf onto#package
and
wsml#lessEqual(?w,50)
and
?a[continent hasValue ?c] memberOf onto#address
and
(wsml#equal(?c, "Europe") or wsml#equal(?c, "North America"))
and
?d[date hasValue ?dt] memberOf onto#delivery
and
?dt[hour hasValue ?h, day hasValue ?deliveryDay] memberOf onto#date
and
wsml#greaterEqual(?h,"07:00")
and
wsml#lessEqual(?h,"20:00")
and
?order[day hasValue ?orderDay] memberOf onto#order
and
numericGreaterThan(wsml#subtract\-dateTimes\-yielding\-day(?deliveryDay, ?orderDay),2).
Listing 3.7-4: A WSML represention of the rules as described above. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/rule/shipmentRule.wsml.
Implies (Antecedent (
Order(I-variable(order))
hasWeight(I-variable(order) I-variable(packageWeight))
swrlb:greaterThanOrEqual(I-variable(packageWeight) 50)
)
Consequent (hasWeight(I-variable(order) 50))
Implies (Antecedent (
Order(I-variable(order))
daysSincePlaced(I-variable(order) I-variable(days))
swrlb:greaterThanOrEqual(I-variable(days) 30)
)
Consequent (itemConfirmationID(I-variable(order) null))
Implies (Antecedent (
Order(I-variable(order))
daysSincePlaced(I-variable(order) I-variable(days))
daysRequiredWithin(I-variable(order) I-variable(requiredDays))
swrlb:greaterThan(I-variable(days) I-variable(requiredDays))
)
Consequent (charge(I-variable(order) false))
Note: Syntax subject to verification!
Listing 3.7-5: A SWRL abstract syntax representing the rules as described above. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/rule/shipmentEffectRuleAbstract.swrlx.
Order(?order) ^ hasWeight(?order,?weight) ^ ?weight > 50 => hasWeight(?order,50) Order(?order) ^ daysSincePlaced(?order,?days) ^ ?days >= 30 => itemConfirmationID(?order,null) Order(?order) ^ daysSincePlaced(?order,?days) ^ daysRequiredWithin(?order,?requiredDays) ^ ?days > ?requiredDays => charge(?order,false)
Note: Syntax subject to verification!
Listing 3.7-6: A SWRL human-readable syntax representing the rules as described above. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/rule/shipmentEffectRuleHR.swrlx.
<wsdl:description
targetNamespace="http://org1.example.com/wsdl/CheckAvailabilityRequestService/"
xmlns="http://org1.example.com/wsdl/CheckAvailabilityRequestService/"
xmlns:wsdl="http://www.w3.org/ns/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<xsd:schema targetNamespace=http://org1.example.com/wsdl/CheckAvailabilityRequestService">
<xsd:element name="CheckAvailabilityRequestServiceRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="itemCode" type="xsd:string"/>
<xsd:element name="date" type="xsd:string"/>
<xsd:element name="qty" type="xsd:float"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CheckAvailabilityRequestServiceResponse" type="itemConfirmation"/>
<xsd:simpleType name="itemConfirmation">
<xsd:restriction base="xsd:boolean"/>
</xsd:simpleType>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="CheckAvailabilityRequestService">
<wsdl:operation name="CheckAvailabilityRequestOperation" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="CheckAvailabilityRequestServiceRequest"
sawsdl:modelReference="http://www.w3.org/2002/ws/sawsdl/spec/examples/rule/swrl.swrlx#inputRule"/>
<wsdl:output element="CheckAvailabilityRequestServiceResponse"
sawsdl:modelReference="http://www.w3.org/2002/ws/sawsdl/spec/examples/rule/swrl.swrlx#outputRule1
http://www.w3.org/2002/ws/sawsdl/spec/examples/rule/swrl.swrlx#outputRule2
http://www.w3.org/2002/ws/sawsdl/spec/examples/rule/swrl.swrlx#outputRule3"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
Listing 3.7-8: An example showing the usage of modelReference to represent conditions
Consider the example where a client/requester may have a 'first name' and 'last name' among its data as shown in Listing 4-1 and the advertisement service requires a 'full name' as shown in Listing 4-2. In this case, when the client invokes the Web service of the service provider, the data values of firstName and lastName need to be concatenated in the message to the advertisement Web service to pass the correct values for the Name element.
.. <xsd:element name="firstName" type="xsd:string"/> <xsd:element name="lastName" type="xsd:string"/> ..
Listing 4-1: An XML sample showing two elements firstName and lastName.
.. <xsd:element name="Name" type="xsd:string"/> ..
Listing 4-2: An XML sample showing an element Name.
To facilitate the association of such types of data transformations with Web services, SAWSDL provides a mechanism called schema mapping. A Schema mapping allows the specification of transformation functions on the WSDL elements to map instance data defined by that XML schema document to the semantic data of the concepts in a semantic model. It also allows the specification of transformation functions that map the semantic data of ontological concepts to the instance data values that adhere to the XML schema document that is being annotated. In the former case, the transformation functions are referred to using the extensibility attribute liftingSchemaMapping and in the latter case it is called loweringSchemaMapping. These kinds of mappings are useful in general when the structure of the XML instance data does not correspond directly to the organization of the semantic data. Also, these types of mappings can be used to generate mediation code to support invocation of a Web service.
In the remaining part of this section, we illustrate these lifting and lowering schema mappings in the context of a purchase order scenario. We use XSLT [XSLT] as the mapping language for illustrative purposes. SAWSDL specification by itself does not prescribe any specific mapping language. Users can choose a mapping language of their choice. The purchase order scenario is very similar to the check availability scenario we have been discussing throughout this document so far.
A liftingSchemaMapping takes as input XML data (that adheres to a given XML schema) and produces semantic data (that adheres to a semantic model, in our case an RDF ontology) as output. Let us consider purchase order scenario. Listing 4.1-1 shows samples of a WSDL that has OrderRequest, item and OrderResponse complex types. Say that we would like to specify a lifting schema mapping notion on OrderRequest complex type so that an XML instance of an OrderRequest complex type can be mapped with the semantic data in the RDF graph shown in Listing 4.1-2. Then, we would specify OrderRequest2Ont.xslt as a lifting schema mapping notion on OrderRequest concept as shown in Listing 4.1-1 below.
<wsdl:description>
...
<wsdl:types>
<xsd:schema
targetNamespace="http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/PurchaseOrderService#" elementFormDefault="qualified">
<xsd:element name="OrderRequest">
<xsd:complexType sawsdl:liftingSchemaMapping="http://www.w3.org/2002/ws/sawsdl/spec/examples/mapping/OrderRequest2Ont.xslt">
<xsd:sequence>
<xsd:element name="firstName" type="xsd:string"/>
<xsd:element name="lastName" type="xsd:string"/>
<xsd:element name="item" type="item" minOccurs="1" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="item">
<xsd:all>
<xsd:element name="itemCode" type="xsd:string"/>
<xsd:element name="quantity" type="xsd:float"/>
<xsd:element name="dueDate" type="xsd:string"/>
<xsd:element name="billingInfo" type="xsd:POBilling"/>
</xsd:all>
</xsd:complexType>
<xsd:element name="OrderResponse" type="Confirmation"/>
<xsd:simpleType name="Confirmation">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Confirmed"/>
<xsd:enumeration value="Pending"/>
<xsd:enumeration value="Rejected"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="Order">
<wsdl:operation name="order" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="OrderRequest"/>
<wsdl:output element="OrderResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
...
Listing 4.1-1: A WSDL sample showing liftingSchemaMapping notion. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/PurchaseOrderService.wsdl.
Listing 4.1-1 refers to http://www.w3.org/2002/ws/sawsdl/spec/examples/mapping/OrderRequest2Ont.xslt. This XSLT maps the elements of OrderRequest complex type with the corresponding ones in the ontology shown in 4.1-2.
@prefix xs: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix : <http://org1.example.com/ontologies/PurchaseOrder#> .
<http://org1.example.com/ontologies/PurchaseOrder#> rdf:type owl:Ontology .
:OrderRequest rdf:type owl:Class .
:hasLineItems rdf:type owl:ObjectProperty ;
rdfs:domain :OrderRequest ;
rdfs:range :LineItem .
:LineItem rdf:type owl:Class .
:hasPart rdf:type owl:ObjectProperty , owl:FunctionalProperty ;
rdfs:domain :LineItem ;
rdfs:range :Part .
:Part rdf:type owl:Class .
:hasPartCode rdf:type owl:ObjectProperty ;
rdfs:domain :Part ;
rdfs:range :PartNum .
:PartNum rdf:type owl:Class .
:hasLexicalRespresentation rdf:type owl:DatatypeProperty , owl:FunctionalProperty ;
rdfs:domain
[ rdf:type owl:Class ;
owl:unionOf (:Name :PartNum :Date)
] ;
rdfs:range xs:string .
:hasDueDate rdf:type owl:ObjectProperty ;
rdfs:domain :LineItem ;
rdfs:range :Date .
:Date rdf:type owl:Class .
:hasQuantity rdf:type owl:DatatypeProperty ;
rdfs:domain :LineItem ;
rdfs:range xs:float .
:hasBillingInfo rdf:type owl:DatatypeProperty ;
rdfs:domain :LineItem ;
rdfs:range xs:billingInfo .
:hasCustomer rdf:type owl:ObjectProperty , owl:FunctionalProperty ;
rdfs:domain :OrderRequest ;
rdfs:range :Customer .
:Customer rdf:type owl:Class .
:hasCustomerName rdf:type owl:ObjectProperty ;
rdfs:domain :Customer ;
rdfs:range :Name .
:Name rdf:type owl:Class .
Listing 4.1-2: A PurchaseOrder ontology. This ontology is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/ontologies/PurchaseOrder.n3.
Given a OrderRequest message (as shown in Listing 4.1-3) which corresponds to the schema in Listing 4.1-1, the part where an XSLT would be of most value in this example is where the values of firstName and lastName are concatenated to match with the semantic data of the concept 'Name' in the PurchaseOrder Ontology. A sample of such a transformation in XSLT is shown in Listing 4.1-4 below.
<OrderRequest
xmlns="http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/PurchaseOrderService#">
<firstName>John</firstName>
<lastName>Smith</lastName>
<item>
<itemCode>052053811</itemCode>
<quantity>12.0</quantity>
<dueDate>20061114</dueDate>
<billingInfo>88 Park Road, Lower Dangan, Galway, Ireland</billingInfo>
</item>
<item>
<itemCode>45001113</itemCode>
<quantity>10.0</quantity>
<dueDate>20061224</dueDate>
<billingInfo>70 Sandyhill Road, Shalthill, Galway, Ireland</billingInfo>
</item>
</OrderRequest>
Listing 4.1-3: A sample XML data that adheres to the WSDL in Listing 4.1-1.
<!DOCTYPE rdf:RDF
[<!ENTITY xs "http://www.w3.org/2001/XMLSchema#">
]
>
<xsl:transform version="2.0"
xmlns:order="http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/PurchaseOrderService#"
xmlns:po="http://org1.example.com/ontologies/PurchaseOrder#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:owl="http://www.w3.org/2002/07/owl#">
<xsl:output method="xml" version="1.0" encoding="iso-8859-1" indent="yes" />
<xsl:template match="/order:OrderRequest">
<rdf:RDF>
<owl:Ontology/>
<po:OrderRequest>
<po:hasCustomer>
<po:Customer>
<po:hasCustomerName>
<po:Name>
<po:hasLexicalRepresentation>
<xsl:value-of select="concat(
order:firstName,
' ',
order:lastName)"/>
</po:hasLexicalRepresentation>
</po:Name>
</po:hasCustomerName>
</po:Customer>
</po:hasCustomer>
<po:hasLineItems>
<po:LineItem>
<po:hasPart>
<po:Part>
<po:hasPartCode>
<po:PartNum>
<po:hasLexicalRepresentation>
<xsl:value-of select="order:item/order:itemCode"/>
</po:hasLexicalRepresentation>
</po:PartNum>
</po:hasPartCode>
</po:Part>
</po:hasPart>
<po:hasDueDate>
<po:Date>
<po:hasLexicalRepresentation>
<xsl:value-of select="order:item/order:dueDate"/>
</po:hasLexicalRepresentation>
</po:Date>
</po:hasDueDate>
<po:hasQuantity rdf:datatype="&xs;float">
<xsl:value-of select="order:item/order:quantity"/>
</po:hasQuantity>
<po:hasBillingInfo rdf:datatype="&xs;POBilling">
<xsl:value-of select="order:item/order:billingInfo"/>
</po:hasBillingInfo>
</po:LineItem>
<xsl:apply-templates select="order:OrderRequest" />
</po:hasLineItems>
</po:OrderRequest>
</rdf:RDF>
</xsl:template>
</xsl:transform>
Listing 4.1-4: An XSLT sample that concatenates the values of firstName and lastName elements to form the semantic data of the concept Name in the ontology. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/mapping/OrderRequest2Ont.xslt.
A sample semantic data that is obtained by applying XSLT in Listing 4.1-4 to WSDL in Listing 4.1-3 is shown in Listing 4.1-5.
<!DOCTYPE rdf:RDF[
<!ENTITY xs "http://www.w3.org/2001/XMLSchema#" >
]
> <rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns="http://org1.example.com/ontologies/PurchaseOrder#"
xml:base="http://org1.example.com/ontologies/PurchaseOrder#">
<owl:Ontology />
<OrderRequest>
<hasLineItems>
<LineItem>
<hasPart>
<part>
<hasPartCode>
<partNum>
<hasLexicalRespresentation>052053811</hasLexicalRespresentation>
</partNum>
</hasPartCode>
</part>
</hasPart>
<hasDueDate>
<date>
<hasLexicalRespresentation>20061114</hasLexicalRespresentation>
</date>
</hasDueDate>
<hasQuantity rdf:datatype="&xs;float">12.0</hasQuantity>
<hasBillingInfo rdf:datatype="&xs;POBilling">88 Park Road, Lower Dangan, Galway, Ireland</hasBillingInfo>
</LineItem>
</hasLineItems>
<hasCustomer>
<Customer>
<hasCustomerName>
<Name>
<hasLexicalRespresentation>John Smith</hasLexicalRespresentation>
</Name>
</hasCustomerName>
</Customer>
</hasCustomer>
</OrderRequest>
</rdf:RDF>
Listing 4.1-5: A result semantic data that adheres to the PurchaseOrder ontology. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/ontologies/OrderRequest.rdf.
In this section, we have discussed how we can specify a liftingSchemaMapping notion for the OrderRequest schema in Listing 4.1-1 to generate an RDF instance as shown in 4.1-5. We can specify a loweringSchemaMapping notion for the same OrderRequest schema as well. One may want to specify both lifting and lowering schema mappings on a given schema to ensure that the same schema can be used to represent both requirements as well as capabilities. For example if the WSDL in 4.1-1 is used to represent a clients' requirements, then a lifting schema mapping can help translate the XML instances that correspond to OrderRequest schema into the RDF data in Listing 4.1-2. Where as if the WSDL in 4.1-1 is used as an advertisement, a lowering schema mapping would be useful because it can enable a client (that has already translated its XML instance into the common RDF semantic data using a liftingSchemaMapping) to map to its XML data. Below, we illustrate two scenarios:
As discussed, lowering schema mapping notion is used to map from RDF data to XML data. First, we present adding loweringSchemaMapping to the same OrderRequest XML schema discussed in Listing 4.1-1 (roundtripping scenario). Sample of Listing 4.1-1 is shown below with an addition of loweringSchemaMapping.
<xsd:element name="OrderRequest">
<xsd:complexType sawsdl:liftingSchemaMapping="http://www.w3.org/2002/ws/sawsdl/spec/examples/mapping/OrderRequest2Ont.xslt
sawsdl:loweringSchemaMapping="http://www.w3.org/2002/ws/sawsdl/spec/examples/mapping/Ont2OrderRequest.lowering">
<xsd:sequence>
<xsd:element name="firstName" type="xsd:integer">John</xsd:element>
<xsd:element name="lastName" type="xsd:integer">Smith</xsd:element>
<xsd:element name="item" type="item" minOccurs="1" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Listing 4.2-1: A sample of OrderRequest complex type from Listing 4.1-1 with loweringSchemaMapping added.
Below, we discuss what such a lowering schema mapping would look like. But before that we have to introduce one more concept.
When specifying a liftingSchemaMapping, an XSLT transform can create a specific XML that can be treated as the representation of semantic data for an RDF/OWL ontology. While specifying loweringSchemaMapping, on the other hand, it may not be clear what format the semantic data of the ontology is expressed in (since there are many variations of RDF semantic data representations in RDF/XML). To overcome this, one could use SPARQL language to query the semantic data of the ontology to obtain a specific XML format for the semantic data of the ontology so that it can then be used to formulate an XSLT transform to obtain an XML that could correspond with the instance of a Web service. A sample SPARQL query that could be used in loweringSchemaMapping is shown in Listing 4.2-2 below.
<lowering>
<sparqlQuery>
PREFIX po: <http://org1.example.com/ontologies/PurchaseOrder#>
SELECT ?name ?partNum ?quantity ?dueDate ?billingInfo
WHERE {
?order po:hasCustomer ?customer .
?customer po:hasCustomerName ?custName .
?custName po:hasLexicalRespresentation ?name .
?order po:hasLineItems ?item .
?item po:hasQuantity ?quantity .
?item po:hasBillingInfo ?billingInfo .
?item po:hasDueDate ?Date .
?date po:hasLexicalRepresentation ?dueDate .
?item po:hasPart ?part .
?part po:hasPartCode ?code .
?code po:hasLexicalRespresentation ?partNum }
</sparqlQuery>
Listing 4.2-2: A SPARQL query on the semantic data (of an ontology) to obtain an XML that could be used to specify XSLT transform in loweringSchemaMapping
When SPARQL [SPARQL] is applied to the RDF graph in Listing 4.1-5, the following XML will be generated as query answer.
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
<head>
<variable name="quantity" />
<variable name="partNum" />
<variable name="name" />
<variable name="dueDate" />
<variable name="billingInfo" />
</head>
<results>
<result>
<binding name="quantity">
<literal>12.0</literal>
</binding>
<binding name="partNum">
<literal>052053811</literal>
</binding>
<binding name="name">
<literal>John Smith</literal>
</binding>
<binding name="billingInfo">
<literal>88 Park Road, Lower Dangan, Galway, Ireland</literal>
</binding>
<binding name="dueDate">
<literal>20061114</literal>
</binding>
</result>
</results>
</sparql>
Listing 4.2-3: Result of applying SPARQL from Listing 4.2-2 to RDF in Listing 4.1-5.
Once an XML is obtained from SPARQL query an XSLT transform can be created. Listing 4.2-4 shows such an XSLT transform.
<xsl:transform version="2.0"
xmlns:po="http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/PurchaseOrderService#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:sp="http://www.w3.org/2005/sparql-results#">
<xsl:output method="xml" version="1.0" encoding="iso-8859-1" indent="yes" />
<xsl:template match="/sp:sparql">
<po:OrderRequest>
<xsl:variable name="fullName">
<xsl:value-of select="sp:results/sp:result[position()=1]/sp:binding[@name='name']/sp:literal"/>
</xsl:variable>
<po:firstName>
<xsl:value-of select="substring-before($fullName,' ')" />
</po:firstName>
<po:lastName>
<xsl:value-of select="substring-after($fullName,' ')" />
</po:lastName>
<xsl:apply-templates select="sp:results/sp:result" />
</po:OrderRequest>
</xsl:template>
<xsl:template match="sp:result">
<po:"item">
<po:itemCode>
<xsl:value-of select="sp:binding[@name='partNum']/sp:literal" />
</po:itemCode>
<po:quantity>
<xsl:value-of select="sp:binding[@name='quantity']/sp:literal" />
</po:quantity>
<po:dueDate>
<xsl:value-of select="sp:binding[@name='dueDate']/sp:literal" />
</po:dueDate>
<po:billingInfo>
<xsl:value-of select="sp:binding[@name='billingInfo']/sp:literal" />
</po:billingInfo>
</po:item>
</xsl:template>
</xsl:transform>
</lowering>
Listing 4.2-4: An XSLT sample that shows loweringSchemaMapping notion. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/mapping/Ont2OrderRequest.lowering.
The result of executing the above XSLT (in Listing 4.2-4) is shown below in Listing 4.2-5. As can be noted, this XML corresponds to the OrderRequest complex type schema. With this, we have completed a full cycle of lifting and lowering on the same schema to and from an RDF data.
<po:OrderRequest
xmlns:po="http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/PurchaseOrderService#"
xmlns:sp="http://www.w3.org/2005/sparql-results#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<po:firstName>John</po:firstName>
<po:lastName>Smith</po:lastName>
<po:item>
<po:itemCode>052053811</po:itemCode>
<po:quantity>12.0</po:quantity>
<po:dueDate>20061114</po:dueDate>
<po:billingInfo>88 Park Road, Lower Dangan, Galway, Ireland</po:billingInfo>
</po:item>
</po:OrderRequest>
Listing 4.2-5: Result of applying XSLT from Listing 4.2-4 to SPARQL result of Listing 4.2-3.
In the remaining part of this section, we will illustrate the second scenario (Web service invocation scenario). In this scenario, we will use another service/WSDL as the advertised service that the client in Listing 4.1-1 is trying to invoke. Such an advertisement service is shown below in Listing 4.2-6. As you can notice, the difference between this service and the client in Listing 4.1-1 is that in this service in MyOrderRequest schema, the format for the names is different from the one provided by the client. The client can supply a 'firstName' and 'lastName' where as this advertisement service only requires an initial for firstName and a last name- which requires an additional level of data translation/manipulation.
<wsdl:description>
...
<wsdl:types>
<xsd:schema
targetNamespace="http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/MyPurchaseOrder#" elementFormDefault="qualified">
<xsd:element name="MyOrderRequest">
<xsd:complexType
sawsdl:loweringSchemaMapping="http://www.w3.org/2002/ws/sawsdl/spec/examples/mapping/Ont2MyOrderRequest.lowering">
<xsd:sequence>
<xsd:element name="firstinitial" type="xsd:string"/>
<xsd:element name="lastName" type="xsd:string"/>
<xsd:element name="item" type="item" minOccurs="1" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="item">
<xsd:all>
<xsd:element name="itemCode" type="xsd:string"/>
<xsd:element name="quantity" type="xsd:float"/>
<xsd:element name="dueDate" type="xsd:string"/>
<xsd:element name="billingInfo" type="xsd:POBilling"/>
</xsd:all>
</xsd:complexType>
<xsd:element name="OrderResponse" type="Confirmation"/>
<xsd:simpleType name="Confirmation">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Confirmed"/>
<xsd:enumeration value="Pending"/>
<xsd:enumeration value="Rejected"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
</wsdl:types>
<wsdl:interface name="Order">
<wsdl:operation name="order" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input element="MyOrderRequest"/>
<wsdl:output element="OrderResponse"/>
</wsdl:operation>
</wsdl:interface>
</wsdl:description>
...
Listing 4.2-6: A WSDL sample of an advertisement service with loweringSchemaMapping notion. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/MyPurchaseOrder.wsdl.
To specify the lowering schema mapping for the schema in Listing 4.2-6 we could use the same SPARQL query as presented in Listing 4.2-2 to obtain the same result as in Listing 4.2-3. However, we need to supply a slightly altered version of a XSLT transform to extract only the first initial from the firstName. The modified XSLT transform for Ont2MyOrderRequest.xslt is shown below in Listing 4.2-7.
<xsl:transform version="2.0"
xmlns:po="http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/PurchaseOrderService#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:sp="http://www.w3.org/2005/sparql-results#">
<xsl:output method="xml" version="1.0" encoding="iso-8859-1" indent="yes" />
<xsl:template match="/sp:sparql">
<po:OrderRequest>
<xsl:variable name="fullName">
<xsl:value-of select="sp:results/sp:result[position()=1]/sp:binding[@name='name']/sp:literal"/>
</xsl:variable>
<po:firstinitial>
<xsl:value-of select="substring(substring-before($fullName,' '),1,1)" />
</po:firstinitial>
<po:lastName>
<xsl:value-of select="substring-after($fullName,' ')" />
</po:lastName>
<xsl:apply-templates select="sp:results/sp:result" />
</po:OrderRequest>
</xsl:template>
<xsl:template match="sp:result">
<po:item>
<po:itemCode>
<xsl:value-of select="sp:binding[@name='partNum']/sp:literal" />
</po:itemCode>
<po:quantity>
<xsl:value-of select="sp:binding[@name='quantity']/sp:literal" />
</po:quantity>
<po:dueDate>
<xsl:value-of select="sp:binding[@name='dueDate']/sp:literal" />
</po:dueDate>
<po:billingInfo>
<xsl:value-of select="sp:binding[@name='billingInfo']/sp:literal" />
</po:billingInfo>
</po:item>
</xsl:template>
</xsl:transform>
</lowering>
Listing 4.2-7: An XSLT sample that shows loweringSchemaMapping notion for an XML instance that adheres to MyOrderRequest schema in Listing 4.2-6. This example is also available at: http://www.w3.org/2002/ws/sawsdl/spec/examples/mapping/Ont2MyOrderRequest.xslt.
The corresponding XML data that can be obtained by executing the transform in Listing 4.2-7 is shown in Listing 4.2-8.
<po:OrderRequest
xmlns:po="http://www.w3.org/2002/ws/sawsdl/spec/examples/wsdl/PurchaseOrderService#"
xmlns:sp="http://www.w3.org/2005/sparql-results#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<po:firstinitial>J</po:firstinitial>
<po:lastName>Smith</po:lastName>
<po:item>
<po:itemCode>052053811</po:itemCode>
<po:quantity>12.0</po:quantity>
<po:dueDate>20061114</po:dueDate>
<po:billingInfo>88 Park Road, Lower Dangan, Galway, Ireland</po:billingInfo>
</po:item>
</po:OrderRequest>
Listing 4.2-8: Result of applying XSLT from Listing 4.2-7 to SPARQL result of Listing 4.2-3.
In summary, the lifting and lower schema mapping notions together enable the transformation of data between Web services which can be an important part of enabling the invocation of Web services.
Just as multiple annotations can be associated using modelReference concept, multiple schema mappings can be associated with elements as well. When multiple URIs are specified on liftingSchemaMapping or loweringSchemaMapping, SAWSDL specifies that the schema mappings they reference are to be treated as alternatives, i.e. the client processor should choose one of them to apply, and the choice is fully at the client processor's discretion. For example, a mapping can be selected based on what mapping language the processor supports (different alternatives can use different languages), based on the availability of the mapping document, or by other preferences.Just as SAWSDL does not prescribe any particular ontology representation language for specifying modelReferences, it does not prescribe any particular schema mapping representation language. In this user guide XSLT and SPARQL are used for illustrative purposes. Users are welcome to use transformation language of their choice to specify lifting and lowering schema mappings. Appendix B presents another example of such a language and additional examples using that language.
The SAWSDL Usage Guide is an accompanying document to SAWSDL specification. This guide presented examples to illustrate how to associate semantic annotations to a Web service (represented in SAWSDL format) and how to use these annotations for classifying, discovering, matching, composing, and invoking Web services. Arguably, this usage guide presents only some of the ways in which the annotations that can be associated with a WSDL document can be used.
This document is the work of the W3C Semantic Annotations for Web Service Description Language Working Group.
Members of the Working Group are (at the time of writing, and in alphabetical order): Rama Akkiraju (IBM Corporation), Carine Bournez (W3C), J.B. Domingue (The Open University), Joel Farrell (IBM Corporation), Laura Ferrari (Telecom Italia SpA), Laurent Henocque (ILOG, S.A.), Mathias Kleiner (ILOG, S.A.), Jacek Kopecký (DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria), Holger Lausen (DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria), Peter Matthews (CA), Antony Miguel (Scapa Technologies Limited), John Miller (University of Georgia Research Foundation, Inc (UGARF)) Carlos Pedrinaci (The Open University), Eric Prud'hommeaux (W3C), Brahmananda Sapkota (DERI Galway at the National University of Ireland, Galway, Ireland), Amit Sheth (Wright State University), Claudio Venezia (Telecom Italia SpA), Tomas Vitvar (DERI Galway at the National University of Ireland, Galway, Ireland).