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.

1.
Introduction

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. Many of the
concepts in SAWSDL are based on an earlier effort WSDL-S [WSDL-S], a W3C submission. 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.

1.1 Namespaces

The XML namespace name
URIs
used by this specification are as follows:

1.2 Running Examples

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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().

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.

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.

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.

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.

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.

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 the following "inputRule" constraints related to shipping
details, they can be represented in SAWSDL using modelReferences as
shown in Listing 3.7-1.

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.

We would like to represent the following effects on the outputs of a purchase order service.

If more than 50lbs was ordered, order is taken only for 50lbs
("outputRule1").

ItemConfirmation # can be tracked only for 30 days after the order was
placed ("outputRule2").

If the order does not arrive the shipping location within the required
date, no charge will be made to the account ("outputRule3").

Listing 3.7-1: An example showing the usage of modelReference to represent conditions

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 (known as schema mappings) to enable Web service
invocation.

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.

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.

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.

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.

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:

Roundtripping scenario: A scenario where both lifting
and lowering schema mappings are specified on the same WSDL schema (we
use Listing 4.1-1 for this)

Web Service Invocation scenario: Second, where we
assume the WSDL in Listing 4.1-1 is that of a client/requester and
demonstrate how a loweringSchemaMapping when specified on another service
(advertisement) that shares the same ontology as the client could help
the client in Listing 4.1-1 to invoke this service.

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.

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.

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.

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.

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.

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.

SPARQL Query
Language for RDF, Eric Prud'hommeaux and Andy Seaborne,
Editors. World Wide Web Consortium, 6 April 2006. This version is
http://www.w3.org/TR/2006/CR-rdf-sparql-query-20060406/. The latest version is
available at http://www.w3.org/TR/rdf-sparql-query/.

This appendix contains listings that formalize the rules from Section 3.7. However, we do not guarantee validity or
correctness of these particular listings; they are provided here only for
illustration.

Listing A-1 captures the shipment conditions ("inputRule") in SWRL
abstract syntax. Listing A-2 presents the same rule in human-readable syntax
and Listing A-3 encodes it, together with the output rules, in XML concrete syntax. The listing also
contains an OWL ontology which represents the concepts such as 'shipment',
'deliveryContinent', 'country' etc. that are used in the rule. Listing A-4 presents
the same input rule in WSML syntax. Finally listings A-5 and
A-6 capture the output rules in SWRL abstract syntax and in a human-readable
syntax.