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 fundamental knowledge required to effectively use WSMO. It presents the basic concepts of WSMO in regard to Version 0.2 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.
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
The WSMO language is especially suitable for modeling Web Services, aiming at providing the facilities required by its usage process namely, discovery, invocation, composition, execution, monitoring, mediation and compensation.
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 suchlike techniques, and its appropriateness for the purpose. In order to allow suitable logic-based reasoning on Semantic Web Service, the description language has to provide reasonable expressiveness for describing relevant aspects of the Services, together with well defined formal semantics that 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, 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 D2v02. Web Service Modeling Ontology - Standard (2004-03-06) final draft, which sets the pillars of the Web Service Modeling Ontology (WSMO), presenting its core elements and the relation among them. The WSMO specification and in particular the Web Service Modeling Ontology - Standard takes as starting point the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002] further refining and extending concepts.
It is the principal aim of the primer to provide an introduction to WSMO - Standard, describing it with a great deal of detail, and showing how to model Goals, Mediators and Semantic Web Services; further, it exemplifies the use of ontologies. 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:
It is not the primer intention to provide a WSMO specification, for such purpose a close look should be taken into the rest of the documents (working drafts and final drafts) which currently are part of the project.
In order to introduce the basic concepts and model, 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 D2v02. Web Service Modeling Ontology
- Standard (2004-03-06) final draft, it is assumed that one Web Service 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, together with its principles; Section 3 describes in detail the use case that guides the primer; Section 4 provides a detailed overview and understanding on the main elements that compose the WSMO specification, this section is divided in five subsections, Section 4.1 shows how to model non-functional properties; Section 4.2 exemplifies the use of ontologies, together with the essential components used to define them; Section 4.3 overviews goals and how they are used to specify Web Services objectives; Section 4.4 presents Web Services, and Section 4.5 exemplifies the use of mediators, which provide the means to bypass interoperability differences among the rest of the elements that compose the specification. Section 5 presents the WSMO specification, while Section 6 provides some useful 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 further develop a solution for the Enterprise Application 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 grounding of WSMO is based on the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002], 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 specification since, they give meaning to the different elements, providing
the terminology that can be aligned to allow its interoperability from a semantic point of view. WSMO specifies the following constituents as part of
the description of an ontology: non-functional properties, used mediators, axioms, concepts, relations and instances.
Ontologies are used to: (1) express goals in a machine processable and understandable language, i.e buy a plane ticket; (2) they permit to enhance Web
Services so they can be matched against goals, i.e Web Services provided by on-line travel agencies; and (3) 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
4.2 Ontologies.
Goals represent the objectives to be fulfilled when consulting a Web Service. The WSMO definition of goal is restricted to post-condition, effects, non-functional properties and used mediators, leaving aside pre-conditions and assumptions. A goal is conceptualize as buying a plane ticket, in our concrete example. Goals provide the means to express high level description of a concrete task. For a more detail look at goals refer to section 4.3 Goals.
Web Services provide the functional behavior that is to be described, in order to allow its discovery, invocation, composition, execution, monitoring, mediation and compensation if required. 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 paradigm, with the advantage of its natural platform independence and distribution over the Web. In the WSMO specification Web Service are described, by means of capability, interfaces, used mediators and non functional properties. A Service is describe by one and only one capability, contrary to interface, where a Service can have multiple interfaces. 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. For more detail information about how to model Web Services within WSMO please refer to section 4.4 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, which are classified in two main classes: refiners and bridges. While refiners are used to define new components as a specialization of an existing one, bridges help to overcome interoperability problems by enabling components to interact with each other. Among the four types of mediators that currently build the specification, ggMediators and ooMediators are refiners, while wgMediators and wwMediators are counted as bridges. In the general case WSMO defines mediators by means of non-functional properties, source component target component and mediation service, where source and target component can be a mediator, a Web Service, and ontology or a goal. In our particular example, mediators could be easily used to arbitrate among goals and the capabilities 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 4.5 Mediators.
Every ontology design is based on principles that can be abstracted from the domain that is going to formally represent. In the following the principles of the WSMO are outlined in order to provide a guide to the ontology design decisions.
Through out this document examples in regard to a buy plane ticket use case are presented. In a nutshell the use case can be resumed in the following sentence 'buy plane ticket to fly from Innsbruck (Austria) to Galway (Ireland)'. To make more concrete the problem the Web Service used to book and buy our flight should take under consideration the following premises, namely: (1) the total travel time including plane connecting time, if required, should be smaller than 7 hours; (2) the traveling date is on March 29th, 2004 and the ticket is a single way one; (3) the most expensive ticket that we are willing to pay should not cost more than 600 euros; (4) there are no restrictions about the company, as long as the ticket is the cheapest possible one; (5) the whole trip should not have more than two jumps, this is, we are willing to change planes once, but only once; (6) in case there are no direct flights from Innsbruck to Galway, our preferred intermediate destinations are Dublin, Amsterdam, Frankfurt or London; (7) the time between connecting flights should be smaller than 2 hours; and finally, (8) we would like to flight tourist class.
The following section explains the WSMO Modeling Elements, therein describing its position inside the WSMO.
Each element of WSMO (ontologies, goals, services and mediators) counts among its definition an instance of the so-called "Non Functional Properties". Non-functional properties specify information regarding the name of the item, authorship, copy rights, etc. WSMO uses Dublin Core Meta Data Set as reference to define non-functional properties. They are defined as a set of tuples, consisting on an attribute and its value. Non-functional properties are used to describe aspects that do not affect functional aspects of the element. Currently they are classified in two main categories: core properties and Web Service specific properties. Listing 1 provides an example of core properties, while in section 4.4.1 Non-functional properties the same can be found for a Web Service.
The following provides and example on non-functional properties for an ontology element. More concretely for the ontology presented in Listing 2.
|
ONFP:[ |
Listing 1. Non Functional Properties
The attribute Type has been defined following the Dublin Core Meta Data Set recommended best practice for encoding type values as defined in the DCMI Type Vocabulary [DCMI], which includes among others the selected type. Any other type defined in DCMI Type Vocabulary [DCMI] is also considered best practice for defining types within the WSMO specification.
The attribute Format has been defined following the Dublin Core Meta Data Set recommended best practice for encoding format values as defined in the Internet Media Types [MIME], which includes among others the selected type. Any other type defined in the Internet Media Types [MIME] is also considered best practice for defining formats within the WSMO specification.
The attribute Date has been defined following the Dublin Core Meta Data Set recommended best practice for encoding date values as defined in ISO 8601 [W3CDTF], which includes among others the selected format. Any other format defined in ISO 8601 [W3CDTF] is also considered best practice for defining dates within the WSMO specification.
The attribute coverage has been defined following the Dublin Core Meta Data Set recommended best practice for encoding spatial locations. A value has been selected from the Thesaurus of Geographic Names [TGN]. The Thesaurus of Geographic Names [TGN] is also considered best practice for defining spatial locations within the WSMO specification. For temporal periods or jurisdiction best practice is to select a name from a controlled vocabulary.
Ontologies are commonly understood as an "formal explicit specification of a shared conceptualization” [Gruber, 1993]. In WSMO, ontologies provide the machine-readable semantics of the information used by all other components, thus allowing interoperability and information interchange among components. An ontology is described by 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 links between concepts, which carry information on parameters. Axioms are specified as F-Logic expressions and help to formalize domain specific knowledge. Instances are concrete individuals of concepts, that carry concrete values for attributes and relations of the corresponding concept.
In regard to our 'buy plane ticket to fly from Innsbruck (Austria) to Galway (Ireland)' case study, Listing 2 shows a domain ontology for a flight that agrees on the defined restrictions. It showcases the specification of ontologies in F-Logic with respect to the ontology modeling elements defined in WSMO. The ontology states the following:
Listing 2 formalized the domain knowledge.
|
ontologyBuyPlaneTicket[ axioms[ t.b.d. ] instances ->> {inn gway dub price.inn-dub price.dub-gwy lufthansa price.inn-dub ticket.inn-dub ticket.dub-gwy }
inn:location[name -> Innsbruck, airport -> TRUE] |
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 ooMediators are used to define the concrete connection between an ontology and another WSMO component (see section 4.5). In addition, ooMediator 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 by interoperability problems into account. In this version of the case study, and so of the primer, the used of ooMediators is not required. Further versions of the primer will show detailed examples on how to use them.
A Goal specifies objectives that a client may have when consulting a Web Service, i.e. functionalities that a Web Service provides from the user perspective. A goal in WSMO is described by non-functional properties, post-conditions, and effects. WSMO restricts the definition of goals to post-conditions and effects, leaving aside preconditions and assumptions. Post-conditions define the state of the desired information space. Effects describe the desired state of the world after the execution of the Web Service. Furthermore, a goal can import existing ontologies to make use of concepts and relations defined elsewhere, either extending or simply reusing them as appropriate, by means of used mediators.
Listing 3 provides a detailed description of the non-functional properties of the goal:
|
GNFP:[ |
Listing 3. Goal Non Functional Properties
Post-conditions define the state of the desired information space. In our concrete use case, post-conditions can be summarized as by the following statements:
Listing 4 models the post-conditions by means of F-Logic:
|
buyPlaneTicketInn-Gwy[travelTime => X, date => Y, price => Z, carrier => U, connections => V, connectingDestinations => W, connectingTime => R, class => N, origin => M, destination => S] |
Listing 4. Goal post-condition description
Currently this example only counts with one effect:
Description in WSMO:
|
effects => [deliveredTicket]:effects |
Listing 5. Effect Description
ggMediators can be used to describe complex goals which can be decomposed into simpler or atomic goals. In the case that similar goals are defined
elsewhere, a ggMediator can then be applied to re-use such existing goal and further adopt or refine it to the target goal.
In our concrete case study the goal can be verbalized as 'buy a plane ticket to fly from Innsbruck (Austria) to Galway (Ireland)'. Let us assume
that there already exists an identified goal suitable for reuse in this concrete scenario, which allows to 'buy plane tickets'. In addition,
there is another one which is defined as 'fly from Innsbruck (Austria) to Galway (Ireland)'. By means of ggMediators both goals can be imported
and combined to actually achieve the desire objective. In case that the terminologies used to define the two different goals are not the same, an ooMediator should
be used in order to aligned them, as is the case in our case study. Listing 4 provides the detailed description of the ggMediator.
|
buyPlaneTicketInn-GwyGGMediator:[ ggMediatorNFP [ggMediatorNFP]:nonFunctionalProperties goalBuyPlaneTicket[ goalBuyPlaneTicketNFP:[goalNonFunctionalProperties]: nonFunctionalProperties usedMediators: [] postconditions:[travelTime => X, date => Y, price => Z, carrier => U, connections => V, connectingDestinations => W, connectingTime => R, class => N, origin => M, destination => S] and any(X) and correct (Y) and any(Z) and any(U) and any(V) and any(W) and any(R) and any(N) and any(M) and any(S) ]:postConditions effects[deliveredTicket] ]:sourceComponent goalBuyPlaneticketInn-Gwy[ nonFunctinalPorperties[goalBuyPlaneTicketInn-GwyNFP]:nonFunctinalPorperties goalBuyPlaneTicketInn-GwyUsedMediators: [] goalBuyPlaneTicketInn-GwyPostconditions:[travelTime => X, date => Y, price => Z, carrier => U, connections => V, connectingDestinations => W, connectingTime => R, seat => N, origin => M, destination=> S] and any(X) and correct (Y) and any(price) and any(U) and any(V) and any(W) and any(R) and any(N) and innsbruck(M) and galway(S) ]:postConditions goalBuyPlaneTicketInn-GwyEffects[deliveredTicket]:effects ]:targetComponent ooMediator:[ ooMediatorNFP[]:nonFunctionalProperties ooSourceComponent[ontologyBuyPlaneTicket]:sourceComponent ooTargetComponent[ontologyBuyPlaneTicketInn-Gwy]:targetComponent ggReduction[origin => M, destination => S] and innsbruck(M) and galway(S) ]:reduction ]:usedMediators goalMediationService[ goalMediationServiceNFP[]:nonFunctionalProperties goalMediationServiceUsedMediators[]:usedMediators goalMediationServicePostconditions[goalBuyPlaneTicket => X, goalBuyPlaneTicketInn-Gwy => Z] and ggMediation (X, Y) ]:postConditions goalMediationServiceEffects[goalsMediated]:effects ]:mediationService ]: ggMediator |
Listing 6. Goal ggMediator
A Web Service description in WSMO consists of four sub-components:
Non functional properties provide relevant information for the concrete usage of a Web Service, without affecting its functional aspect. Used Mediators permit to import ontologies by means of ooMediators in order to reuse concepts and relations defined elsewhere. The capability of a Web Service defines its functionality in terms of pre and postconditions, assumptions and effects. The Interface provides further information on how the functionality can be achieved, describing the communication pattern that allows to consume the functionality choreography, and/or how the overall functionality is achieved by means of cooperation of different service providers orchestration.
|
WSNFP:[ |
Listing 7. Web Service Non Functional Properties
In addition to the core properties, WSMO allows the definition of Web Service specific non-functional properties, which allow describing quality aspects of a Web Service (QoS):|
QoSNFP:[ |
Listing 8. Additional Web Service Non Functional Properties
It is important to notice that at the moment the specification does not provide a controlled vocabulary for the values of the Web Service specific non-functional properties. In future versions of the specification, recommended best practice to define this terms will be made available. In the mean while, a short description of the meaning of each value is provided:
The capability of a Web Service defines the service by means of its functionality. To do so it makes use of: non functional properties, used mediators, pre-conditions, post-conditions, assumptions, and effects. A Web Services defines one capability.
|
capability:[ |
Listing 9. Web Service Capability
The current version of the WSMO specification distinguishes among two types of mediators namely, refiners and bridges. While refiners allow to define a component as a refinement of an existing one, bridges provide support for re-use, by enabling two heterogeneous components to interact with each other. Currently the specification counts with four types of mediators, ggMediators and ooMediators are refiners, while wgMediators and wwMediators are counted as bridges. 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.
In this current version of the primer, a ggMediator is used to import and combine two goals, while a ooMediator is used to aligned the different ontologies used in its definition. In future versions of the primer the use of wwMediators and wgMediators will also be shown. For further reference in regard the concepts around mediators please refer to WSMO Specification: D2v02. Web Service Modeling Ontology - Standard.
[DCT1] DCMI Type Vocabulary. DCMI Recommendation, 11 July 2000. <http://dublincore.org/documents/dcmi-type-vocabulary/>
[MIME] Internet Media Types. <http://www.isi.edu/in-notes/iana/assignments/media-types/media-types>
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[W3CDTF] Date and Time Formats, W3C Note. <http://www.w3.org/TR/NOTE-datetime>
[TGN] Getty Thesaurus of Geographic Names. <http://www.getty.edu/research/tools/vocabulary/tgn/index.html>
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.