This document is also available in non-normative PDF version.
Copyright © 2004 DERI®, All Rights Reserved. DERI liability, trademark, document use, and software licensing rules apply.
The Web Service Modeling Ontology (WSMO) is an ontology for describing various aspects related to Semantic Web Services. The primer is designed to provide the reader with the basic knowledge required to effectively use WSMO. It presents the basic concepts of WSMO in regard to Version 0.1 of the language specification. It describes how to model goals and Web Services, further it shows how to model the different types of mediators introduced in the specification, together with the role played by ontologies in WSMO. Finally it describes the content and purpose of other documents in the specification
WSMO Specification: D2v01. Web Service Modeling Ontology (WSMO)
WSMO Use Case Modeling and Testing: D3.2v01. WSMO Use Case Modeling and Testing
The Web Service Modeling Ontology (WSMO) is a formal ontology and language for describing the various aspects related to Semantic Web Services. WSMO language takes a layered approach that starts with a basic WSMO, called WSMO-Lite, continues with a mature set of concepts called WSMO-Standard and ends with a full ontology called WSMO-Full, as shown in figure 1.
 |
Figure 1. WSMO-Lite, WSMO-Standard, WSMO-Full
It is especially suitable for modeling Web Services, with the aim to allow discovery, invocation, composition, execution, monitoring, mediation and compensation of Web Services.
The objective of WSMO and its surrounding efforts is to define a coherent technology for Semantic Web Services. Means for semi-automated discovery, composition, and execution of Web Services shall be based on logical inference-mechanisms because of the well-known competences of these technologies for suchlike techniques. In order to allow suitable logic-based reasoning on Semantic Web Service, the description language has to provide reasonable expressiveness for describing the various aspects, together with well defined formal semantics in order to support effective reasoning. WSMO applies F-Logic as the underlying logic formalism since it provides a standard model theory, it is a full first order logic language, it provides second order syntax while staying in the first order logic semantics, and it has a minimal model semantics. A further benefit of F-Logic is that implemented inference engines are already available.
The primer is based on the work carried on D2v01. Web Service Modeling Ontology (2004-02-14) working draft, other deliverables that contribute to the specification at this point are:
The primer aims at providing an introduction to WSMO and describe it with a great deal of detail. It shows how to model Semantic Web Services, Goals, and Mediators together with its different aspects in regard to discovery, invocation, composition, execution, monitoring, mediation and compensation. The target audience is researches, software engineers and developers, besides anyone dealing with Semantic Web Services. It is the Primer intention to answer question such as:
In order to introduce the basic concepts and model from a high level point
of view, a flight ticket buying example will be used through out the Primer.
In such example an agent tries to buy a plane ticket to travel from Innsbruck
(Austria) to Galway (Ireland).
For the shake of simplicity, and in order to better show the concepts
detailed in D2v01. Web Service
Modeling Ontology (2004-02-14) working draft, it is assumed that one Web
Services fulfills all the functionality required through out the process of
buying a plane ticket, while this, of course might not be the case in many
systems, where a service might be invoked to search for a ticket, another to
reserve it, and probably third one to buy and pay.
The WSMO Primer is organized as follows: Section 2 introduces the basic concepts and model behind WSMO following a high level example, together with its principles; Section 3 provides a detail overview and understanding about the main elements that compose WSMO. This section is subdivided in three subsections. Section 3.1 exemplifies the use of ontologies together with the essential components which define them in an independent fashion in regard the language used to describe them; Section 3.2 overviews goals and how they are used to specify Web Services objectives; Section 3.3 presents Web Services within the WSMO framework, and how they are modeled; Finally, section3.4 introduces the mediators and how they are used to bypass differences among the previously defined elements. Section 4 provides some useful references, while Section 5 contains the references.
WSMO is intended to provide an efficient and simple way to describe the various aspects of Semantic Web Services with the aim of providing a solution to its semi-automated usage and solve the integration problem. This section describes the approach and basic ideas behind WSMO in order to tackle these problems.
WSMO defines the modeling elements for describing several aspects of Semantic Web Services. The conceptual basis of WSMO is the Web Service Modeling Framework WSMF, wherein four main components are defined, as shown in figure 2.
 |
Figure 2. WSMO Components
Ontologies represent the key element in WSMO. They serve a twofold purpose,
first they define the information formal semantics, and second allow to link
machine and human terminologies. They play a key role in the WSMO since they
give meaning to the different elements allowing to glue them together from a
semantic point of view.
Ontologies are used to express goals in a machine processable and
understandable language, i.e buy a plane ticket; they permit to enhance Web
Services so they can be matched against goals, i.e Web Services provided by
on-line travel agencies; and interconnect the different elements with each
other by means of mediators, i.e services and goals using different similar
terminology. A more detailed Ontology description is given in section 3.1 Modeling Ontologies
As previously stated goals represent the objectives to be fulfilled when consulting a Web Service. The WSMO definition of goal is restricted to postcondition and effects leaving aside pre-conditions and assumpitions.
In regard to the example, a goal is conceptualize as buying a plane ticket. Other requirements such as origin, destination, departure time, itinerary or price are part of the Service input, and so are not reflected in the goal. In this sense goals provide the means to express high level description of a concrete task. For a more detail look at goals refer to section 3.2 Modeling Goals
Web Services provide the functional behaviour that needs to be described
in order to be discovered, invoked, composed, executed, monitored, mediated
and compensated. They represent the atomic piece of functionality that can
be reused to build more complex ones. In this sense it is straight forward
to assimilate Web Services to procedures, methods or functions of any
programming language, with the advantage of its natural platform
independence and distribution over the Web.
In the WSMO specification Web Service are mainly described, by means of
capability, interfaces and groundings. Capabilities are associated to
services. A service might have many interfaces each one with its associated
grounding, but will provide only one capability for all of them. Each interface
counts with its own set of input, output, pre and post-conditions.
In respect to the plane ticket example, Web Services provide the search, book, buy and pay functionality (all in one service in this particular case), respectively expressed in the associated Web Service capability. Services are invoked using the provided interfaces through the appropriate grounding. For more detail information about how to model Web Services within WSMO please refer to section 3.3 Modeling Web Services.
Mediators allow to overcome functional and non-functional mismatches among the different elements that build the WSMO specification. Currently the specification counts with four different types of mediators, namely: ggMediators, ooMediators, wgMediators, and wwMediators, that provide different types of adaptation.
Mediators provide the means to overcome the inherited differences among the elements that build WSMO. In our particular example, mediators could be easily used to arbitrate among goals and the capabilities of a particular interface of a given Web Service, probably expressed using different ontology languages and terminology. Such would be the case of ooMediators as part of a wgMediator. More detail about the particular use of mediators and the role they play in WSMO will be provided in section 3.4 Modeling Mediators
Every ontology design is based on principles of the domain that is going to be formally represented. In the following the principles of the WSMO are outlined that guide the ontology design decisions.
In addition to principles that are underlying the domain of representation, ontologies have a purpose and are used in a specific context. The WSMO is not only describing the domain of Semantic Web Services, but also serves as the conceptual model for a formal language design as well as an execution environment for the actual execution of Semantic Web Service interactions.
The following explains the Modeling Elements of WSMO, therein describing the position inside the WSMO.
Each component of WSMO is described by the so-called "Non Functional Properties". Non Functional properties are used to identify and manage the items defined in a WSMO application, including information on the name of the item, on authorship and copy rights, etc. WSMO uses Dublin Core Meta Data Set for this purpose. These properties are called non functional because they do not affect the conceptual description of the WSMO elements. To make the idea more concrete each element of WSMO (ontologies, goals, services and mediators) includes a description of its non functional parameters. An example is giving in each section.
For example, for the ontology specified in Listing 1, the non-functional properties would look like this:
|
goalNonFunctionalProps:[ |
Listing 1. Non Functional Properties
Ontologies are commonly understood as an "explicit specification of a
shared specification”. In WSMO, ontologies provide the machine-readable
semantics of the information used by all other components, thus ensuring semantically
correct information interchange between the components. An ontology is described
by its concepts, relations, axioms and instances, conforming to the elements
of ontologies as defined in Open
Knowledge Base Connectivity. Concepts are defined by their subsumption hierarchy
and their attributes including range specification.
Relations describe relationships between concepts, carrying information on parameters.
Axioms are specified as F-Logic expressions, thus supporting the expressive
power of F-Logic. Instances are concrete individuals of concepts, thus carrying
concrete values for attributes and relations of the corresponding concept.
According to the example of booking flight tickets, Listing 2 shows a domain ontology for a flight connection. It showcases the specification of ontologies in F-Logic with respect to the ontology modelling elements defined in WSMO. The ontology states the following:
In order to assign the ontology elements to the description of an ontology in WSMO, we state the ontology elements in the beginning of the Listing.
|
flightConnection:ontology[ flight[ location[ date[value => `dd.mm.yy´]. time[value => `hh.mm´]. price[ // an axioms states that departureDate has to be at least 1 day later
than current date // instance definition |
Listing 2. Example for Domain Ontology Description
Ontologies are applied in every other WSMO element as domain specific vocabulary definitions. In order to support modularized development of ontologies WSMO allows to import other ontologies into an ontology specification by the “usedMediators” – primitive. Therefore, the so called OO Mediators are used to define the concrete connection between an ontology and another WSMO component (see section 3.4). In addition OO-Mediator does not only connect two ontologies, but defines the possibly needed mediation facility concurrently. This concept restricts the problems of ontology integration to the mediators, thus allowing ontology development and maintenance without taking interoperability problems into account.
A Goal specifies objectives that a client may have when he consults a web service, i.e. functionalities that a Web Service based system provides from the user perspective. A Goal in WSMO is described by nonFunctionalPropertis, postConditions, and effects. Furthermore it can also important existing ontologies to further normalize the terminology for describing goals or reuse the pre-defined or existing goals in the goal repositories.
WSMO restricts the definition of goals to Post-conditions. Post-conditions defines the conditions on outputs and the conditional relation between input and output. Post-condition is evaluated before invoking the web service to determine whether it is possible to achieve the output and also fulfil all the effects.
Let's take the example mentioned above.
Goal: buy a plane ticket from Innsbruck to Galway
Non functional properties of this goal can be modelled in WSMO as:
|
goalNonFunctionalProps:[ |
Listing 3. Goal Non Functional Properties
ggMediator can be used for complex goal description which can be easily decomposed into simple or atomic goals. Also there can exist similar goals defined somewhere else; ggMediator can then be applied to re-use such existing goal and further adopt or refine it to the target goal. Since the example here is very simple, ggMediator may not be need. Furthermore, the goal in the example can be described from other existing ontologies (already defined concepts or relations), this can be achieved by ooMediator.
In our current example the Post-condition is:
Description in WSMO:
|
postConditions => notAbovelimitation(CreditCardNumber) OR notAbovelimitation(bankAccountDetails) |
Listing 4. Post condition Description
Effects of the example is:
Description in WSMO:
|
effects => deliveredTicket |
Listing 5. Effect Description
A Web Service description in WSMO consists of four sub-components.
|
WSNonFunctionalProps:[ |
Listing 6. Web Service Non Functional Properties
Additional non functional properties:|
AdditionalWSNonFunctionalProps:[ |
Listing 7. Additional Web Service Non Functional Properties
A detailed overview on the use of mediators within Web Services is given in section 3.4 Modeling Mediators.
The Grounding of a Web Service describes aspect about how to access a Web Service. In the current version of the specification it details information about input, output and error messsages. The Web Service that is being modelled counts with two different groundings, with different input parameters. The first one accepts a credit card as payment method, while the second expects the bank account details. Having two groundings, implies having two interfaces, but one only capability.
Grounding 1:|
Grounding:[ |
Listing 8. Credit Card Grounding
Grounding 2:|
Grounding:[ |
Listing 9. Bank Account Grounding
The Capability of a Web Service is defines the service in terms of pre and post-conditions, assumptions and effects. A Web Services is associated to one capability.
Since pre and post-conditions are defined in regard the input and output specified in the grounding, the modeled capability must account for all the different inputs and outputs provided. This is done by means of the OR construct, that allows to specify alternate paths for pre and post-conditions. More concretely, since the input for the payment method might be either a credit card number or the bank account details the required validity conditions must be stablished for both in the pre-conditions section.
|
Capability:[ |
Listing 10. Web Service Capability
The Interface of a Web Service broadens the concept of capability providing the means for compensation, orchestration, message exchange, together with error data codes.
Interface 1:|
Interface:[ |
Listing 11. Credit Card Interface
Interface 2:|
Interface:[ |
Listing 12. Credit Card Interface
Mediators in WSMO fulfill 2 purposes: on the one hand, they define the connection between two components of WSMO and, on the other hand, they provide the possible needed mediation service between the connected components. This general architecture allows the linking of possibly heterogeneous resources and, at the same time, include description of the mediation facility and is employed in whenever WSMO components are linked. All interoperability aspects are concentrated in Mediators, which allows developers to focus on a specific aspect when defining a WSMO based application. Figure 3 shows the general concept of Mediators in WSMO. We differentiate the following types of Mediators, with regard to the type of mediation service that is needed to establish interoperability for the connection type:
 |
Figure 3. General Architecture of Mediators in WSMO
In general, a Mediator is described by the following notions (we omit the non functional properties here - of course every Mediator carries these as well):
The different types of mediators are sub-concepts of this description, thus carrying more specific or refined description elements as described in the subsequent sections.
An OO-Mediator is used to import ontologies into all other WSMO elements as the formal, machine-processable semantics. With respect to the mediation facility, an OO Mediator is used to establish semantic interoperability between two components. These might be heterogeneous with regard to the information structure represented in the domain ontologies applied.
OO Mediators are modelled by the general modeling elements of Mediators. The only refinement applies to the Source Component which can only be an ontology or another OO Mediator, while the Target Component can be any WSMO component. The Mediation Facility aligned with any OO Mediator qualifies as Ontology Integration technique. These enable semantically correct interoperability between two ontologies.
For example, the Ontology defined in Listing 2 is imported as the domain ontology of a Web Service Description. The corresponding OO Mediator would look like this:
ooMediatorWebService:ooMediator[ nFP:nonFunctionalProperties[ |
Listing 13: OO-Mediator for importing a Domain ontology into a Web Service Description
A GG Mediator is used to connect 2 Goals, meaning that hierarchies or other types of relations among Goals can be defined. Therefore, the Source Component is restricted to Goals or other GG Mediators. A GG Mediator uses an OO Mediator by means of the "usedMediators" primitive in order to import the needed terminology. The Mediation Facility of a GG Mediator is a Reduction of Post Conditions of a Goal. This means that the post conditions of the imported Goal are weakened or extended in order to describe a Subgoal.
Imagine that a Goal "G-1" defines in its postcondition that the startLocation of a flight has to be Innsbruck, for a flight to Galway, and a Goal "G-2" defines that a startLocation can as well be Munich. Therefore, the reduction weakens the postcondition of G-1 and makes it compatible to G-2.
| ggM:ggMediator[ nonFunctionalProperties -> nFP, sourceComponent ->> G-1, targetComponent ->> G-2, usedMediators ->> {ooM-G1, ooM-G2}, // conncetions to the domain ontologies of G-1 and G-2 reduction ->> ggM-reduction ]. nFP:nonFunctionalProperties[ ggM-reduction :- FORALL X: G-2 <- X:G-1 OR postcondition[location.startLocation.name -> 'Munich']. |
Listing 14: a GG-Mediator between two Goals
The purpose of WW Mediators is to connect 2 Web Services when interaction among them is required. Therefore, the Source Component as well as the Target Component are restricted to Web Services or other WW Mediators, respectively. The Mediation facilities required by WW Mediators are comprised of all levels of mediation: on the data level, on the business process level, and on the protocol level. For WW Mediators, the descriptions of the Web Service Interface are very important since they provide the information on the external behaviour of a Web Service.
According to the example, our plane ticket buying example could internally be decomposed on different services providing the different functionalities (search, booking, pay), requiring WW Mediation among them. A Web Services "A" that books flight tickets invokes another Web Service "B" for the payment process. Besides, A uses a ontology which defines a ticket for a flight and for a customer, and B employs an generic ontology that defines a product, a seller and a buyer. Therefore, we need a Mediation Service that aligns these two ontologies. Such service is modelled as a Goal, so it an arbitrary Service can applied which provides the desired mediation facility.
| wwM:wwMediator[ nonFunctionalProperties ->> nFP, sourceComponent ->> A, targetComponent ->> B, usedMediators ->> {ooM-A, ooM-B}, // conncetions to the domain ontologies of A and B mediationService ->> domMediation ]. nFP-wgm_g1:nonFunctionalProperties[ // the Mediation Service modeled as a Goal domMediation:goal[ nFP_domM:nonFunctionalProperties[ postCondition_domOOM :- |
Listing 15: WW-Mediator between two Web Services
Finally, WG Mediators are the link between Goals and Web Services, i.e. they define the connection between the user goals and the services available. The Source Component of a WG Mediator is either a Goal or another WG Mediator, and the Target Component is a Web Service (or another WG Mediator). The Mediation facility needed in WG Mediators is to make postconditions of Goals compatiblke to postconditions of Web Services. It is important to remark that a WG Mediator provides the actual link between Goals and Web Services, but does not provide the Discovery Mechanism for Web Service.
According to our example, we could say that a flight from Munich to Galway would also be acceptable, but the Goal only specifies Innsbruck as a desired startLocation. Thus, the reduction provided in a WG-Mediator will state that the post condition of a Web Service that has Munich as the startLocation also fulfills the Goal. and Galway.
| wgM:wgMediator[ nonFunctionalProperties -> nFP, sourceComponent ->> G-1, targetComponent ->> WebService-C, usedMediators ->> {ooM-G1, ooM-C}, // conncetions to the domain ontologies of G-1 and C reduction ->> wgM-reduction ]. nFP:nonFunctionalProperties[ ggM-reduction :- FORALL C <- |
Listing 16: a WG-Mediator
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, and SWWS; by Science Foundation Ireland under the DERI-Lion project; and by the Austrian government under the CoOperate programm.
The editors would like to thank to all the members of the WSMO working group for their advises and inputs to this document.