wsmo logo

D4.2v01 Formal Comparison WSMO/OWL-S

DERI Working Draft 15 March 2004

This version:
Latest version:
Previous version:
Axel Polleres
Ruben Lara

Axel Polleres
Ruben Lara
Dumitru Roman

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.

Table of contents

1. Introduction
2. Use Cases in OWL-S
2.1 The BravoAir Web Service
2.2 The Congo Web Services
3. From OWL-S to WSMO
3.1 The BravoAir Web Service in WSMO-Standard
3.2 The Congo Web Services in WSMO-Standard
4. Use Cases in WSMO
5. From WSMO to OWL-S
6. What is Missing?
7. Discussion and Open Points
8. Conclusions and Further Work

1. Introduction

In this document it is our aim to formally compare the Web Service Modeling Ontology (WSMO) [Roman et al., 2004] and the Semantic Web Services ontology OWL-S [Martin et al., 2004] by hand of some well-known examples. For this purpose we consider examples provided by the OWL-S Coalition [Martin et al., 2004b] and some preliminary WSMO use cases defined in [Stollberg & Arroyo, 2004]. WSMO and OWL-S are the most salient initiatives to describe Semantic Web Services, aiming at describing the various aspects related to Semantic Web Services in order to enable the automation of Web Service discovery, composition, interoperation and invocation.

By trying to match the chosen examples in either formalization manually we want to achieve a better understanding how far one can get using either approach, which are the disjoint features, and which compatibilities exist. In this sense, the present document shall refine and substantiate the conceptual comparison we provided in [Lara et al., 2004]

One crucial point for use case specifications is that the authors normally tend to take only into account what is expressible in their own particular formalism. In trying to deploy WSMO and OWL-S, respectively, in Use case scenarios originally designed for the other formalism, this document should be a helpful starting point in detecting mismatches and flaws in both approaches. Eventually this shall lead to a fruitful combination of both or in the conclusion that one simply subsumes the other, respectively. We plan to extend the results of this comparison in the following in the direction of an automatic mapping tool for (syntactic fragments of) web service descriptions in WSMO or OWL-S in either direction.

The comparison presented in this document exposes the relation between the latest stable versions of WSMO and OWL-S, i.e WSMO-Standard v0.2 [Roman et al., 2004] and OWL-S v1.0 [OWL-S, 2004]. The purpose of the comparison is to highlight the conceptual overlaps and conceptual differences between the two specifications. This document is based on previous results in [Lara et al., 2004]. A previous comparison between DAML-S and WSMF is presented. [Flett, 2002].

Section 2 presents some use case examples specified in OWL-S taken from [Martin et al., 2004b] and we analyze which particular features of OWL-S are addressed in the particular examples and which are not. In the following Section 3 we investigate how far we can get in formulating these examples in WSMO highligting differences between the two formalisms, difficulties, and general patterns which can be recognized from these manual translations. Section 4 and Section 5 will cover the other way from WSMO to OWL based on the WSMO use case examples from [Stollberg & Arroyo, 2004]. In Section 6 we elaborate a more on the lack of a logical formalism for representing conditions, rules and variables in OWL which hampers the specification of complex services in OWL-S. Since the conctrete formalism to be chosen for this purpose is still left open in the current version of OWL as, we will discuss the most likely candidates DRS and SWRL briefly and compare their expressive and syntactic features with F-Logic, the proposed logical formalism underlying WSMO. In order to exemplify the difference we again chose some examples from ???(Rules examples from: ORL (=SWRL) copy paste by Ian Horrocks, reference?) and [Stollberg & Arroyo, 2004] We will summarize and discuss our findings in Section 7 pinpointing to open questions. Finally, we conclude with an outlook to further work in Section 8.

2. Use Cases in OWL-S

In this section we describe the examples that accompany the version 1.0 of OWL-S [Martin et al., 2004b]. Two examples are given by the OWL-S Coalition in order to illustrate the use of the service ontology, namely:

In the next subsections, we summarize the most important aspects of the examples. For more details (including the OWL files for the examples), we refer the reader to [Martin et al., 2004b].

2.1 The BravoAir Web Service

This example models a Web Service for gathering information about fligths and booking the selected flight.

Main classes:


Process model:

Figure 1. BravoAir Web Service process composition
BravoAir Web Service process composition

Grounding (WSDL grounding provided for the example):

Each atomic process is mapped to a WSDL operation (defined in a WSDL file), each OWL-S input message to the correspondent message parts in the WSDL definition, and each OWL-S output message to the correspondent message parts in the WSDL definition. A WSDL file is also given, defining the mappings from the WSDL interface to the OWL-S description (operations to atomic processes, and message parts to the corresponding OWL-S inputs and outputs).

2.2 The Congo Web Services

This example models two Web Services that offer the electronic purchase of books: the ExpressCongoBuy service and the FullCongoBuy service. We will first present the express version of the service, a one-step form, CongoBuy, with the service treated as atomic; i.e., no interactions between buying and selling agents are required, apart from invocation of the service and receipt of its outputs by the buyer. Given certain inputs and preconditions, the service provides certain outputs and has specific effects [Martin et al., 2004b].

Main classes:


Process model:

Grounding (WSDL grounding provided for the example):

As in the BravoAir example, each atomic process is mapped to a WSDL operation, each OWL-S input message to the correspondent message parts in the WSDL definition, and each OWL-S output message to the correspondent message parts in the WSDL definition. A WSDL file is also given, defining the mappings from the WSDL interface to the OWL-S description.

The Full version of the Congo example shows its composition from its component services. The full-fledged version of the service, FullCongoBuy, includes an arrangement of subprocesses LocateBook, PutInCart, SignIn, CreateAcct, CreateProfile, LoadProfile, SpecifyDeliveryDetails, and FinalizeBuy each, with its own specification of inputs and outputs [Martin et al., 2004b].

Main classes:


Process model:

Figure 2. FullCongoBuy Web Service process composition
FullCongoBuy Web Service process composition

Grounding (WSDL grounding provided for the example):

As for the other examples, atomic processes are mapped to a WSDL operation, each OWL-S input message to the correspondent message parts in the WSDL definition, and each OWL-S output message to the correspondent message parts in the WSDL definition. A WSDL file is also given, defining the mappings from the WSDL interface to the OWL-S description. Nevertheless, some of the atomic processes used in the service decomposition have no grounding defined.

3. From OWL-S to WSMO

In this section, we use the Web Service Modeling Ontology WSMO-Standard v0.2 [Roman et al., 2004] to model the examples described in the previous section.

The OWL-S examples assume the homogeneity of the terminologies (domain ontologies) used to describe the Web Services. As a consequence, the ooMediators in WSMO-Standard are not necessary to model the examples given.

Regarding wwMediators, they would be used to define the decomposition of the service, i.e. the WSMO-Standard orchestration. Unfortunately, the current version of WSMO-Standard does not sufficiently define how the orchestration is described, which makes the use of wwMediators and the definition of the decomposition of the service not possible. Future versions of WSMO-Standard will define this aspect in detail, and the modelling of the service orchestration will be included in the following versions of this document.

As a consequence, we focus in the following sections on the modelling of WSMO-Standard goals, ggMediators, wgMediators and Web Services for the OWL-S examples presented. We assume that the OWL domain ontologies defined in the examples are valid, and we will not redefine them here.

3.1 The BravoAir Web Service in WSMO-Standard

The OWL-S profile is interpreted as advertising both the capability of the service and the requirements of the requester. As discussed in [Lara et al., 2004], this unified view is split in WSMO-Standard into two different views: the requester view (modelled as a goal) and the provider view (modelled as a capability). Therefore, we start the modelling of the BravoAir service by defining the goal for the requester.

In the OWL-S modelling, the profile of the service is classified using a profile hierarchy. This can be modelled in WSMO-Standard via ggMediators, that can define the reuse and refinement of other goals. Therefore, we will model the profile hierarchy given in the example as a succesive refinement of goals.

Nevertheless, it can be seen that the OWL-S profile hierarchy does not define real profiles i.e. does not define the IOPEs of the service, but a taxonomy of profiles. In WSMO-Standard, this taxonomy is defined by REAL goals i.e. the categorization is given by the use and refinement of existing goals.

In order to give a more accurate idea of the use of goals and ggMediators in WSMO-Standard, we will sligthly adapt the OWL-S example. We will assume that the properties defined for the profile hierarchy, such as merchandise or deliveryMode, mean that the profile describes an effect of performing a purchase and having the goods delivered, and we will model them as effects in the goal. The OWL-S taxonomy could be defined using subclassing of goals, but this is not the intended use of goals and ggMediators in WSMO-Standard.

In the following, we model the taxonomy defined in the OWL-S profile hierarchy using goals and ggMediators.

Listing 1. Goal definition for E-commerce
effects ->> eCommerceEffect

Listing 2. Effect for the E-commerce goal
definedBy -> X:purchase[goodType -> product], Y:delivery[deliveryMode -> transportation]

Listing 3. Goal definition for AirlineTicketing
usedMediators ->> eCommerceAirlineTicketingMediator

Listing 4. Mediator between E-commerce goal and AirlineTicketing goal
sourceComponent -> eCommerceGoal
targetComponent -> airlineTicketingGoal
reduction -> airlineTicketingReduction

Listing 5. AirlineTicketing reduction
definedBy -> X:purchase[goodType -> AirlineTicket]

Once the goals and their relationship are defined, we will model the actual Web Service and link it to the appropriate goal using a wgMediator.

Listing 6. Web Service definition for BravoAir
nonFunctionalProperties -> nonFunctionalPropertiesBravoAir
capability -> capabilityBravoAir
interfaces ->> interfaceBravoAir

Listing 7. Non functional properties definition for the BravoAir Web Service
title -> "BravoAir Web Service"
subject -> naics561599
description -> "The service provides flight reservations based on the specification of a flight request. This typically involves a departure airport, an arrival airport, a departure date, and if a return trip is required, a return date. If the desired flight is available, an itinerary and reservation number will be returned."
publisher -> reservationDepartment
identifier -> ""
source -> ""
performance -> goodRating
reliability -> goodRating
security -> goodRating
scalability -> goodRating
robustness -> goodRating
accuracy -> goodRating
networkRelatedQoS -> goodRating

Notice that some non-functional properties that are available in WSMO-Standard but that are not defined in the OWL-S example, have not been used.

Some values, such as naics561599, reservationDepartment or goodRating are defined as instances of the appropriate domain ontologies. The exact definition of these instances and the correspondent ontologies is out of the scope of this document.

In the OWL-S modelling of the BravoAir non-functional properties, two contacts and two categorizations are described. However, the cardinality constrainsts in WSMO-Standard do not allow the definition of more than one value for the non-functional properties of the service.

The contact information given in the OWL-S example has been included as the publisher of the service. It can be argued that it could also be the creator or either the contributor, but with the information available about the OWL-S example, defining the contact information as the publisher seems to be the original intention of the authors.

The OWL-S modelling includes information about the geographical radius of the service. There is not such a non-functional property in WSMO-Standard.

The rating property in OWL-S could be interpreted in different ways. As WSMO-Standard provides a more detailed non-functional characterization of the service, we chose to interpret the rating given in the example as representing several non-functional aspects of the service, such as performance, reliability, security, etc. In general, a service modelled using WSMO-Standard will describe specific values for each of these properties.

Listing 8. Capability definition for the BravoAir Web Service
usedMediators ->> airlineTicketingBravoAirMediator
preconditions ->> bravoAirPrecondition
postconditions ->> bravoAirPostcondition
effects ->> bravoAirEffect

We do not define non-functional properties for the capability because this information is not defined in the OWL-S example. However, for other use cases, they could be used.

As discussed before, we do not define ooMediators because in the example homogeneity of terminologies is assumed.

Listing 9. Mediator between AirlineTicketing goal and BravoAir capability
sourceComponent -> airlineTicketingGoal
targetComponent -> capabilityBravoAir
reduction -> bravoAirReduction

The reduction includes the postconditions that are defined by the BravoAir capability but not defined in the goal, stating the difference of functionality between the goal and the service.

Listing 10. BravoAir reduction
definedBy -> O1:output, O1:preferredFlightItinerary_Out, O2:output, O2:acctName_Out, O3:output, O3:reservationID_Out

Listing 11. BravoAir precondition
definedBy -> I1:input, I1:departureAirport_In, I2:input, I2:arrivalAirport_In, I3:input, I3:outboundDate_In, I4:input, I4:inboundDate_In, I5:input, I5:roundTrip_In, I6:input, I6:preferredFlightItinerary_In, I7:input, I7:availableFlightItineraryList_Out, I8:input, I8:acctName_In, I9:input, I9:password_In, I10:input, I10:reservationID_In, I11:input, I11:confirm_In

Listing 12. BravoAir postcondition
definedBy -> O1:output, O1:preferredFlightItinerary_Out, O2:output, O2:acctName_Out, O3:output, O3:reservationID_Out ]

In WSMO-Standard, the postcondition defines the relationship between the input and the output. However, as this information is not capture in OWL-S, it cannot be extracted from the BravoAir example. For that reason, we cannot include that information here, although it is necessary to completely describe the functionality of the service.

Listing 13. BravoAir effect
definedBy -> X:purchase[goodType -> airlineTicket], Y:delivery[deliveryMode -> transportation] ]

It can be seen that the BravoAir effect has been sligthly adapted from the OWL-S example, in order to make it consistent with the interpretation of the service effect given for the goal.

Listing 14. Interface definition for the BravoAir Web Service
choreography => choreographyBravoAir
orchestration => orchestrationBravoAir

Non-functional properties and used mediators are not defined for the interface for the same reasons they were not defined for the capability. Regarding the choreography and orchestration, the current version of WSMO-Standard does not provide the required modeling elements to describe them yet. Future versions of WSMO-Standard will define the required modeling elements and the details of the choreography and orchestration of the BravoAir Web Service will be added to this document.

3.2 The Congo Web Service in WSMO-Standard

4. Use Cases in WSMO

At the current state, the use cases in WSMO are still underdefined to allow for a concrete analysis of the feasibility of translations to OWL-S. [We prefer to wait for the final version of these specifications in favor of just some adhoc encodings in OWL-S at the moment.]

5. From WSMO to OWL-S

6. What is Missing in OWL-S?

At the current state, OWL-S still lacks of a formal specification of a logical formalism to define rules and logical expressions, in particular for describing relations of inputs and outputs or preconditions and postconditions respectively. The OWL-S use cases above to not require the definition of such relations, but as we shall see by more complex examples, the capability to model such relations is essention for the functional descpription of Semantic Web Services. However, it shall be mentioned that in the latest OWL-S version several extensions for incorporating rules in OWL-S are mentioned. In particular, the authors mention DRS and SWRL as potiential candidates for a formal language for conditions in the context of OWL-S. Short comparison between - OWL - OWL+DRS - OWL+SWRL - F-Logic Rules examples from: ORL (=SWRL) copy paste.

7. Discussion and Open Points

Summarizing, for a more formal comparison, we would need examples covering all features of the respective approaches (WSMO and OWL-S)as well as more elaborate versions of both.

8. Conclusions and Further Work

Based on the manual translations here, we try to come up with a first mapping from OWL-S to WSMO (refer D.4.3). Note that this should also be aligned with the proof obligations defined in D5.


[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.

[Flett, 2002] A. Flett: A comparison of DAML-S and WSMF, Technical report, 2002.

[Keller et al., to appear] U. Keller, A. Polleres, R. Lara, and Y. Ding: Language Evaluation and Comparison, to appear.

[Kifer et al., 1995] M. Kifer, G. Lausen, and James Wu: Logical foundations of object oriented and frame-based languages.Journal of the ACM, 42(4):741-843, 1995.

[Lara et al., 2004] R. Lara, D. Roman, and A.Polleres: Conceptual Comparison WSMO/OWL-S., version 0.1 available at

[McIlraith et al., 2001] S. A. McIlraith, T. C. Son, H. Zeng:Semantic Web Services , IEEE Intelligent Systems, 16(2), March/April, 2001.

[Martin et al., 2004] D. Martin, et al.: OWL-S: Semantic Markup for Web Services, version 1.0 available at

[Martin et al., 2004b] D. Martin, et al.: OWL-S 1.0 Release: Examples, available at

[Roman et al., 2004] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology - Standard (WSMO - Standard), version 0.2 available at

[Stollberg & Arroyo, 2004] M. Stollberg, S. Arroyo (eds.): WSMO Use Case Modeling and Testing, version 0.1 available at


The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto, COG and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate programme.

The editors would like to thank to all the members of the WSMO working group for their advice and input to this document.

[1] There is a mistake in the example, as the Service definition refers to Profile_Congo_BookBuying_Service via the presents property, but the real profile that references the service via the presentedBy property is Profile_Full_Congo_BookBuying_Service.

[2] There is a mistake in the example. SignInSequence is defined as atomic in the choice definition, although this process is defined as a composite process later on. We will consider it as a composite process, as this seems to be the intention of the authors.

[3] The CreateProfile process is not defined in the example.