W3C W3C Member Submission

Web Service Modeling Ontology Primer

W3C Member Submission 3 June 2005

This version:
http://www.w3.org/submissions/2005/SUBM-WSMO-primer-20050603/
Latest version:
http://www.w3.org/submissions/WSMO-primer/
Editor:
Cristina Feier
Authors:
Sinuhe Arroyo
Emilia Cimpian
John Domingue (WSMO WG co-chair)
Cristina Feier
Dieter Fensel (WSMO WG co-chair, WSML WG co-chair)
Birgitta König-Ries
Holger Lausen
Axel Polleres
Michael Stollberg

Abstract

The Web Service Modeling Ontology (WSMO) is an ontology for describing various aspects related to Semantic Web services. This primer is designed to provide the reader with the fundamental knowledge required to use WSMO effectively. It presents the basic concepts of WSMO with respect to the conceptual specification. It describes how to model ontologies, Web services, goals and mediators using the language devised for formalizing WSMO, the Web Service Modeling Language (WSML).

Status of this Document

This document is a part of the WSMO Submission.

By publishing this document, W3C acknowledges that DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria, DERI Galway at the National University of Ireland, Galway, Ireland, BT, The Open University, and SAP AG have made a formal submission to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.

Table of contents

1. Introduction
2. Overview
   2.1 WSMO Design Principles
   2.2 Basic Concepts and Model
3. Use Case Description
4. WSMO Modeling Elements
   4.1 Ontologies
      4.1.1 Concepts
      4.1.2 Relations
      4.1.3 Functions
      4.1.4 Instances
      4.1.5 Axioms
   4.2 Web Services
      4.2.1 Web Service Capability
      4.2.2 Web Service Interface
   4.3 Goals
   4.4 Mediators
      4.4.1 OOMediators
      4.4.2 GGMediators
      4.4.3 WGMediators
      4.4.4 WWMediators
5. Conclusions
Acknowledgements
References
Appendix


1. Introduction

The Web Service Modeling Ontology (WSMO) is a conceptual model for describing various aspects related to Semantic Web services. The objective of WSMO and its accompanying efforts is to solve the application integration problem for Web services by defining a coherent technology for Semantic Web services. WSMO takes the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002] as starting point and further refines and extends its concepts. It is developed by the WSMO working group.

In order to achieve automated discovery, composition, and execution of Web services a conceptual model alone is insufficient. In addition, a formal language is required to write down annotations of Web services according to the conceptual model. Logical inference-mechanisms can be applied to the descriptions in this language. In order to allow appropriate, satisfactorily logic-based reasoning on Semantic Web services, the description language has to provide reasonable expressivity, together with well-defined formal semantics. The Web Service Modeling Language (WSML) is a family of languages which formalizes WSMO. A related goal of WSML is to provide a rule-based language for the Semantic Web. It is developed by the WSML working group, which is a subgroup of the WSMO working group.

Another working group related to WSMO is dedicated to the Web Service Execution Environment (WSMX working group). The goal of this working group is the development of an execution environment for the dynamic discovery, selection, mediation, invocation and inter-operation of Semantic Web services based on the WSMO specification. WSMX shall provide a reference architecture and implementation for this purpose.

The aim of this primer is to provide an introduction to WSMO and to describe it in sufficient detail to enable the reader to model goals, mediators and Web services. Further, it exemplifies the use and modeling of domain ontologies, which comprise the fourth pillar of WSMO. The target audience are researchers, software engineers and developers, and all other persons interested in and dealing with Semantic Web services. It is the primer's intention to answer questions such as:

The primer is mainly based on the Web Service Modeling Ontology (WSMO) document which presents the core elements of the Web Service Modeling Ontology and their interrelations. All examples provided throughout the primer use WSML. It is not intention of the primer to provide a complete specification of WSMO: further details can be found in the rest of the documents of the submission. The WSMO submission consists of the following documents:

An overview of each document from the W3C member submission is presented in the WSMO submission overview document. The intention of these documents is to provide a self-contained set of specifications which describe WSMO in sufficient detail for immediate usage and implementation. Several other documents and working drafts related to the WSMO specification, but not formally included in this specification, can be found at http://www.wsmo.org/TR/.

The WSMO Primer is organized as follows: Section 2 introduces the basic concepts and model behind WSMO, together with its underlying principles; Section 3 describes the use case that guides this primer; Section 4 provides an overview of the main elements of WSMO. Some conclusions regarding WSMO usability are drawn in Section 5. The WSML definitions of the entities used for describing the chosen use case, which are spread throughout the whole document in order to exemplify each entity in turn, are gathered as a unified example in a separate Appendix.

2. Overview

WSMO provides a means to describe all relevant aspects of Semantic Web services in a unified manner. Here, we particularly consider as relevant all aspects concerning the problems arising in Enterprise Application Integration . This section describes the approach and basic ideas behind WSMO in order to tackle these problems.

2.1 WSMO Design Principles

WSMO provides ontological specifications for the core elements of Semantic Web services. In fact, Semantic Web services aim at an integrated technology for the next generation of the Web by combining Semantic Web technologies and Web services, thereby turning the Internet from an information repository for human consumption into a world-wide system for distributed Web computing. Therefore, appropriate frameworks for Semantic Web services need to integrate the basic Web design principles, those defined for the Semantic Web, as well as design principles for distributed, service-orientated computing of the Web. WSMO is therefore based on the following design principles:

2.2 Basic Concepts and Model

WSMO defines the modeling elements for describing several aspects of Semantic Web services based on the conceptual grounding set up in the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002], wherein four main components are defined:

WSMO inherits these four top elements, further refining and extending them. Below there is a more detailed description of each of these top-level components of WSMO.

Ontologies represent a key element in WSMO because they provide (domain specific) terminologies for describing the other elements. They serve a twofold purpose: first, defining the formal semantics of the information, and second, linking machine and human terminologies. WSMO specifies the following constituents as part of the description of an ontology: concepts, relations, functions, axioms, and instances of concepts and relations, as well as non-functional properties, imported ontologies, and used mediators. The latter allows the interconnection of different ontologies by using mediators that solve terminology mismatches. A more detailed description of the structure of an ontology together with an example of such a description is given in Section 4.1.

Web services connect computers and devices with each other using the standard Web-based protocols to exchange data and combine data in new ways. Their distribution over the Web confers on them the advantage of platform independence. Each Web service represents an atomic piece of functionality that can be reused to build more complex ones. In order to allow their discovery, invocation, composition, execution, monitoring, mediation, and compensation, Web services are described in WSMO from three different points of view: non-functional properties, functionality and behavior. Thus, a Web service is defined by its non-functional properties, its imported ontologies, its used mediators, its capability and its interfaces. A Web service can be described by multiple interfaces, but has one and only one capability. The capability of a Web service encapsulates its functionality and an interface of a Web Service describes the behavior of the Web Service from two perspectives: communication and collaboration. For more detailed information about how to model Web services within WSMO please refer to Section 4.2.

Goals describe aspects related to user desires with respect to the requested functionality as opposed to the provided functionality described in the Web service capability. In WSMO a goal is characterized by a set of non-functional properties, imported ontologies, used mediators, the requested capability and the requested interface. Goals are described in Section 4.3.

Mediators describe elements that aim to overcome structural, semantic or conceptual mismatches that appear between the different components that build up a WSMO description. Currently the specification covers four different types of mediators:

More details about the particular use of mediators and the role they play in WSMO are provided in Section 4.4.

3. Use case description

In order to introduce the basic concepts and model, a use case from the domain of e-tourism is used throughout the Primer. In this use case, an agent wants to buy a ticket to travel from Innsbruck (Austria) to Venice (Italy) on a certain date. The goal that specifies the intent of buying a ticket for a trip from Innsbruck to Venice is abstracted from this agent desire. A hypothetical Book Ticket Web service, offered by a "Virtual Travel Agency" (VTA), is considered for achieving the goal. This Web service allows the service requester to search and buy tickets for itineraries starting in Austria. The only accepted payment method is credit card. For the execution of the transaction, the credit card must be a valid PlasticBuy or GoldCard (two fictitious credit card brands).

4. WSMO Modeling Elements

This section explains the WSMO modeling elements, describing their purpose and illustrating how they can be specified. This section is divided into four subsections: Section 4.1 describes ontologies and all the essential components used to define them, Section 4.2 presents Web services, Section 4.3 presents goals and how they are used to specify the functionality required from Web services, and finally Section 4.4 exemplifies the use of mediators which provide the means to bypass interoperability problems among the rest of the elements. The examples presented throughout this section are based on the previously presented use case.

4.1 Ontologies

A widespread definition of ontology is given in [Gruber, 1993] where an ontology is defined as "a formal explicit specification of a shared conceptualization". In WSMO, ontologies provide machine-readable semantics for the information used by all actors implied in the process of Web services usage, either providers or requesters, allowing interoperability and information interchange among components. As an example, we present the definition of an ontology used for specifying the "Book Ticket Web Service" described in the use case and for defining a goal that can be solved by this Web service. This ontology is called "Trip Reservation Ontology", since it defines the necessary terminology for describing trip and reservation related information.

A namespace declaration can appear at the beginning of each WSML file. Such a declaration may comprise the default namespace and abbreviations for other used namespaces. Listing 1 starts with the namespace declaration at the top of the WSML file where the "Trip Reservation Ontology" is specified.

Any ontology declaration starts with the keyword ontology optionally followed by the ontology identifier. A set of non-functional properties may follow this statement. Non-functional properties can be specified for almost any WSMO element and they describe information that does not affect the functionality of the element like title, authorship, copyrights, etc. For each different WSMO element, there is a recommended set of non-functional properties, but this set is extensible. The "Trip Reservation Ontology" is characterized by the non-functional properties that appear in Listing 1.

Note that, the majority of the recommended non-functional properties are properties defined in the Dublin Core Metadata Element Set. However, their values have types according to the WSMO recommendation:

The only non-functional property declared for this ontology that is not included in the Dublin Core Metadata Element Set is wsml#version, its value being a CVS revision tag, as recommended by WSMO.

Listing 1. Trip Reservation Ontology Header
namespace {_"http://example.org/tripReservationOntology#",
  dc     _"http://purl.org/dc/elements/1.1#",
  loc    _"http://example.org/locationOntology#",
  po     _"http://example.org/purchaseOntology#",
  foaf   _"http://xmlns.com/foaf/0.1/",
  wsml   _"http://www.wsmo.org/wsml/wsml-syntax#",
  prs    _"http://example.org/owlPersonMediator#"}

ontology  _"http://example.org/tripReservationOntology"
  nonFunctionalProperties
    dc#title hasValue "Trip Reservation Ontology"
    dc#identifier hasValue _"http://example.org/tripReservationOntology"
    dc#creator hasValue _"http://example.org/foaf#deri"
    dc#description hasValue
       "an ontology for describing trip reservations related knowledge"
    dc#publisher hasValue _"http://example.org/foaf#deri"
    dc#contributor hasValue  _"http://example.org/foaf#cristina"
    dc#date hasValue _date(2004,12,16)
    dc#format hasValue "text/x-wsml"
    dc#language hasValue "en-us"
    dc#rights hasValue _"http://deri.at/privacy.html"
    wsml#version hasValue "$Revision 1.17 $"
  endNonFunctionalProperties

  importsOntology  { _"http://example.org/locationOntology",
                   _"http://example.org/purchaseOntology"}

  usesMediator _"http://example.org/owlPersonMediator"

Ontologies are applied in every other WSMO element as domain specific vocabulary definitions. WSMO allows the importing of other ontologies into an ontology either directly, when no conflicts need to be resolved, or indirectly, by using mediation, which is the process of resolving any conflicts that may appear through aligning, merging or transforming imported ontologies. In the first case the imported ontologies are specified by using the keyword importsOntology, while in the second case the usesMediator statement points to the mediators, the components that realize the mediation. Mediation may be done not only between ontologies, but also between other components involved in the Web service descriptions, the mediators that realize the mediation between ontologies being named ooMediators. More about the possible types of mediators can be found in Section 4.4. In the "Trip Reservation Ontology", two ontologies are imported without any mediation and one mediator is used for importing one OWL [OWLSemantics] ontology.

The basic blocks of an ontology are concepts, relations, functions, instances, and axioms. The examples provided in the next subsections for each of these elements are taken mainly from the "Trip Reservation Ontology".

4.1.1 Concepts

Concepts are defined by their subsumption hierarchy and their attributes, including range specification. The range of the attributes can be a datatype or another concept. There are two kinds of attribute definitions: constraining definitions, using the keyword ofType and inferring definitions using the keyword impliesType. In the first case, the values of the attribute are constrained to having the mentioned type, while in the latter, the values of the attribute are inferred to have the mentioned type. For specifying that an attribute can have any type we can declare its type as being wsml#true. Like for other WSMO entities, a set of non-functional properties can be used for specifying additional information about concepts. Below the definitions of some concepts from the "Trip Reservation Ontology" are presented, that will be further used for defining other elements of WSMO.

Listing 2. Concept definitions
concept trip
    origin impliesType loc#location
    destination impliesType loc#location
    departure ofType _date
    arrival ofType _date

  concept tripFromAustria subConceptOf trip
    nonFunctionalProperties
       dc#relation hasValue tripFromAustriaDef
    endNonFunctionalProperties

  axiom tripFromAustriaDef
    definedBy
         forall {?x ,?origin}
                (?x memberOf tripFromAustria
                  implies
                  ?x[
                      origin hasValue ?origin] and
                  ?origin[
                      loc#locatedIn hasValue loc#austria]
                ).

  concept ticket
    provider ofType _string
    trip ofType trip
    recordLocatorNumber ofType _integer

  concept reservationRequest
    nonFunctionalProperties
      dc#description hasValue "This concept represents a
      reservation request for some trip for a particular person"
    endNonFunctionalProperties
    reservationItem impliesType wsml#true
    reservationHolder impliesType prs#person

  concept reservation
    nonFunctionalProperties
       dc#description hasValue "concept of a confirmation for some item"
    endNonFunctionalProperties
    reservationItem impliesType wsml#true
    reservationHolder impliesType prs#person

For expressing subsumption relations between concepts the keyword subConceptOf is used. In the example above, the concept tripFromAustria is subsumed by the concept trip.

The extension of a concept can be defined or restricted by one or more logical expressions that specify a necessary and/or a sufficient condition for an instance to be an element of the extension of the concept. Such logical expressions are embedded in axioms. It is recommended that the concept refers to its related axioms by declaring their identifiers as values for the non-functional property dc#relation. The definition of the concept tripFromAustria is completed with an axiom, tripFromAustriaDef, that specifies that a necessary and sufficient condition for an individual to be an instance of this concept is to have as the values of its origin attribute the location Austria.

4.1.2 Relations

Relations describe interdependencies between a set of parameters. Optionally, the domain of parameters which can be a datatype or a certain concept can be specified using the impliesType or ofType keywords. Thus, a relation declaration comprises the keyword relation, the identifier of the relation and optionally: its arity, its superrelations, the domain of its parameters, and a set of non-functional properties. Axioms can be used for defining/constraining the relation extension. If there are such axioms, it is recommended to refer to them in the dc#relation non-functional property.

Below is a relation definition taken from a different ontology, the "Purchase Ontology", that has a single argument, a credit card, and holds when the credit card is valid. Accompanying this relation is an axiom that compares the credit card expiry date with the current date for establishing its validity. For completeness, the definition of the concept creditCard is also provided, since it is used in the function definition. Note that this listing is taken from a different WSML file (the file in which the "Purchase Ontology" is defined) than the file to which the other examples presented in this section belong (the file in which the "Trip Reservation Ontology" is defined).

Listing 3. The definition of the relation validCreditCard
namespace { _"http://example.org/purchaseOntology#",
   dc              _"http://purl.org/dc/elements/1.1",
   wsml            _"http://www.wsmo.org/wsml/wsml-syntax#",
   prs             _"http://example.org/owlPersonMediator.wsml#"}

ontology  _"http://example.org/purchaseOntology"

concept creditCard
    owner impliesType prs#person
    number ofType _integer
    type ofType _string
    expiryDate ofType _date
    balance ofType _integer


relation validCreditCard(ofType creditCard)
  nonFunctionalProperties
      dc#description hasValue "Relation that holds for a valid credit card"
      dc#relation hasValue ValidCreditCardDef
  endNonFunctionalProperties


axiom ValidCreditCardDef
definedBy
   forall {?x, ?y}  (
         validCreditCard(?x)  impliedBy
         ?x[expiryDate hasValue ?y] memberOf creditCard 
         and
         neg (wsml#dateLessThan(?y, wsml#currentDate()))).

4.1.3 Functions

Functions are a special type of relations that have a unary range beside the set of parameters. Although in the conceptual model, they are regarded as entities distinct from relations, in WSML they are modeled as a special type of relations that have one functional parameter. Besides the typical declaration for a relation, when declaring a function one must include an axiom that states the functional dependency. The function ticketPrice is modeled as a relation with three parameters: the first one is a ticket, the second one is a currency, while the third one is the result returned by the function: the price of the ticket in the given currency.

Listing 4. Modeling the function tripPrice as a relation
relation ticketPrice(ofType ticket, ofType po#currency, ofType _integer)
  nonFunctionalProperties
     dc#description hasValue
         "Function that returns the price of a ticket in a given currency"
     dc#relation hasValue {FunctionalDependencyTripPrice}
   endNonFunctionalProperties


axiom FunctionalDependencyTicketPrice
     definedBy
       !-  ticketPrice(?x,?y,?z1) and ticketPrice(?x,?y,?z2) and ?z1 != ?z2 .

4.1.4 Instances

Instances are embodiments of concepts or relations, being defined either explicitly by specifying concrete values for attributes or parameters or by a link to an instance store. In the listing below three instances are presented, the first two being instances of the concepts trip, respectively ticket, presented in Listing 2, and the third one being an instance of the function (relation) ticketPrice introduced in Listing 4. Instances explicitly specified in an ontology are those that are shared together with the ontology. This may be the case for the first instance, tripInnVen. However, most instance data exists outside the ontology in private data stores. These private data stores are called instance stores and they are linked to the ontology. We expect the second and the third instance which represent the coordinates of a ticket for a trip from Innsbruck to Venice, respectively the price for that given ticket instance, to reside in such an instance store, since they are specific to the Web service provider. For simplicity, here we consider them to be declared in the same file as the "Trip Reservation Ontology". We will come back to this issue in a later section.

Listing 5. Instance definitions
instance tripInnVen memberOf trip
   origin hasValue loc#innsbruck
   destination hasValue loc#venice
   departure hasValue  _date(2005,11,22)
   arrival hasValue  _date(2005,11,22)

instance ticketInnVen memberOf ticket
   provider hasValue "Book Ticket Service"
   trip hasValue tripInnVen
   recordLocatorNumber hasValue 93

relationInstance ticketPrice(ticketInnVen, po#euro, 120)

4.1.5 Axioms

Axioms are specified as logic expressions and help to formalize domain specific knowledge. Different WSML variants allow different expressivities for the logical expressions. For more detail about that, see the WSML specification. As already described in the previous sections, they are declared by using the keyword axiom optionally followed by the axiom identifier, by a set of non-functional properties and by the logical expression introduced by the keyword definedBy.

4.2 Web Services

A Web service description in WSMO consists of five sub-components: non-functional properties, imported ontologies, used mediators, a capability and interfaces.

In this section we illustrate the declaration of a Web service, by defining the "Book Ticket Web Service" offered by the "Virtual Travel Agency" described in Section 3.

The declaration of a Web service starts with the keyword webService followed by the identifier of the Web service. After this, comes the declaration of the non-functional properties of the Web service. A Web service can import ontologies either directly, by using the importsOntology statement, or via oomediators declared in the usesMediator statement. The "Book Ticket Web Service" imports the "Trip Reservation Ontology". It must be noted that the Web service has its own instance store linked to this ontology in which there are instances specific to the Web service like the available tickets and the prices of those tickets. Below is the definition of this Web service.

Listing 6. Definition of the "Book Ticket Web Service"
namespace {_"http://example.org/bookTicket#",
   dc       _"http://purl.org/dc/elements/1.1#",
   tr        _"http://example.org/tripReservationOntology#",
   foaf     _"http://xmlns.com/foaf/0.1/",
   wsml   _"http://www.wsmo.org/wsml/wsml-syntax#",
   bti      _"http://www.example.org/BookTicketInterfaceOntology#"}

webService _"http://example.org/bookTicketWebService"

importsOntology _"http://example.org/tripReservationOntology"

capability BookTicketCapability
interface BookTicketInterface

4.2.1 Web Service Capability

The capability of a Web service defines its functionality in terms of pre and postconditions, assumptions and effects. A Web service defines one and only one capability. A Web service capability is defined by specifying the next elements: non-functional properties, imported ontologies, used mediators, shared variables, precondition, postcondition, assumption, and effect.

Ontologies may be imported either directly using the keyword importsOntology or via ooMediators declared in the usesMediator section.

A capability, therefore a Web service, may be linked to certain goals that are solved by the Web service via special types of mediators, named wgMediators. These links are useful in the Web Service Discovery phase. WGMediators resolve also terminology mismatches between Web services and goals. Such mediators are specified in the usesMediator part of a Web service capability definition.

For declaring the basic blocks of the "Book Ticket Web Service" capability, we will take a closer look at what the Web service offers to a client (postcondition), when some conditions are met in the information space (precondition), and how the execution of the Web service changes the world (effect), given that some conditions over the world state are met before execution (assumption). Preconditions, assumptions, postconditions and effects are expressed through a set of axioms. A set of shared variables can be declared within the capability. These variables are implicitly all-quantified and their scope is the whole Web service capability. Thus, in informal language, the logical interpretation of a Web service capability is: for any values taken by the shared variables, the conjunction of the precondition and of the assumption implies the conjunction of the postcondition and of the effect.

When its execution is successful, the "Book Ticket Web Service" has as result a reservation that includes the reservation holder and a ticket for the desired trip (postcondition) if there is a reservation request for a trip with its starting point in Austria for a certain person (precondition) and if the credit card intended to be used for paying is a valid one and its type is either PlasticBuy or GoldenCard (assumption). As a consequence of the execution of the Web service, the price of the ticket will be deducted from the credit card (effect). The shared variables for the "Book Ticket Web Service" are those that designate the desired trip (the variable ?trip), the reservation holder (the variable ?reservationHolder), the credit card information (the variable ?creditCard), the initial balance of the credit card (the variable ?initialBalance) and the provided ticket (the variable ?ticket). The precondition checks whether the user request is about a trip whose origin is in Austria. This is done by checking the membership of the trip value from the user request to the concept tripFromAustria defined in the "Trip Reservation Ontology". The assumption uses the relation validCreditCard defined in the "Purchase Ontology" to see whether the credit card is valid. The postcondition states that the result of the trip is a reservation that includes a ticket for the desired trip using the special symbol result. The effect updates the value of the credit card balance by subtracting the price of the ticket. The price of the ticket is kept in the Web service instance store as an instance of the function (relation) ticketPrice.

Listing 7. Definition of the "Book Ticket Web Service" capability
capability BookTicketCapability 

  sharedVariables {?creditCard, ?initialBalance, ?trip, ?reservationHolder, ?ticket}

  precondition
      nonFunctionalProperties
           dc#description hasValue "The information of a trip which starts in Austria
            together with the information about the person who wants to have a reservation
            must be given as a part of a reservation request. A credit card is also required."
      endNonFunctionalProperties
      definedBy
          ?reservationRequest[
               reservationItem hasValue ?trip,
               reservationHolder hasValue ?reservationHolder
           ] memberOf tr#reservationRequest
           and
           ?trip memberOf tr#tripFromAustria and
           ?creditCard[
               balance hasValue ?initialBalance
           ] memberOf po#creditCard.

  assumption
      nonFunctionalProperties
          dc#description hasValue "The credit card information provided by the
           requester must designate a valid credit card that should be either
           PlasticBuy or GoldenCard."
      endNonFunctionalProperties
      definedBy
           po#validCreditCard(?creditCard)
           and ( ?creditCard[
                        type hasValue "PlasticBuy"]
                   or
                  ?creditCard[
                        type hasValue "GoldenCard"]
                 ).

  postcondition
      nonFunctionalProperties
          dc#description hasValue "A reservation containing the details of a ticket for
           the desired trip and the reservation holder is the result of the successful
           execution of the Web service."
      endNonFunctionalProperties
      definedBy
         ?reservation memberOf tr#reservation[
            reservationItem hasValue ?ticket,
            reservationHolder hasValue ?reservationHolder
         ]
         and 
         ?ticket[
            trip hasValue ?trip
         ]
         memberOf tr#ticket.

  effect
     nonFunctionalProperties
         dc#description hasValue "The credit card  will be charged with the cost of
          the ticket."
     endNonFunctionalProperties
      definedBy
          ticketPrice(?ticket, "euro", ?ticketPrice) 
          and
         ?finalBalance= (?initialBalance - ?ticketPrice)
          and
          ?creditCard[
               po#balance  hasValue  ?finalBalance
           ] .

4.2.2 Web Service Interface

The interface of a Web service provides further information on how the functionality of the Web service is achieved. It contains:

Thus, a Web service interface is defined by specifying the next elements: non-functional properties, imported ontologies, used mediators, choreography, and orchestration.

Listing 8. Definition of a "Book Ticket Web Service" interface
interface BookTicketInterface
   importsOntology _"http://www.example.org/BookTicketInterfaceOntology"
   choreography BookTicketChoreography
   orchestration BookTicketOrchestration

The interface of the Web service, more specifically its components, the choreography and the orchestration, are depicted in Figure 1. The next subsections will describe in greater detail each of these two components.

The Book Ticket Service Choreography and Orchestration

Figure 1. The "Book Ticket Web Service" interface

4.2.2.1 Choreography

The choreography specifies the behavior interface for Web service consumption. A user of the Web service has to support this for consuming a Web service. A choreography description has two parts: the state and the guarded transitions. A state is represented by an ontology, while guarded transitions are if-then rules that specify transitions between states.

Listing 9. Definition of a Book Ticket Web service Choreography
choreography BookTicketChoreography
   state _"http://example.org/BookTicketInterfaceOntology"
   guardedTransitions BookTicketChoreographyTransitionRules

The ontology that represents the state has a twofold role: first, it provides the vocabulary of the transition rules, and second, it contains the set of instances that change their values from one state to the other. Thus, its content is dynamic. Informally, a state is considered to be the dynamic set of instances at a certain point in time. The concepts, relations and functions of an ontology used for representing a state may have specified one or two additional non-functional properties. These non-functional properties are mode and grounding. The mode of an element gives an indication about who (the Web service and/or the environment) is allowed to modify the extension of the element and in which way (read/write). It can have one of the following values: static (the default value), controlled, in, out, shared. In the case of elements which have the mode in, out or shared, a grounding mechanism should be provided by using the non-functional property grounding. The ontology used for defining the choreography may reuse external ontologies by importing them and redefining the elements for which the specification of the mode is needed, and possibly that of grounding. This is done by declaring similar elements that inherit the definition of the original ones and adding the desired non-functional properties.

In our use case, the ontology used for describing the choreography, named "Book Ticket Interface Ontology" imports the ontologies "Trip Reservation Ontology" and "Purchase Ontology", and redefines the concepts reservationRequest, creditCard and reservation as having the modes in, in, and out respectively. Two new concepts are defined in this ontology, temporaryReservation and negativeAcknowledgement that have the modes controlled and out respectively. An instance of the first concept will be created in the choreography after receiving a reservation request and before receiving the credit card information, and an instance of the second concept will be created as a result of receiving the information of a credit card that is invalid. The name of this ontology is "Book Ticket Interface Ontology" and not "Book Ticket Choreography Ontology", as it would be expected, because both the choreography and the orchestration of this Web service defined in the interface "BookTicketInterface" use this ontology.

Listing 10. Definition of the "Book Ticket Interface Ontology"
namespace {_"http://example.org/BookTicketInterfaceOntology#",
    dc     _"http://purl.org/dc/elements/1.1#",
    tr     _"http://example.org/tripReservationOntology#",
    wsml   _"http://www.wsmo.org/wsml/wsml-syntax#",
    po     _"http:/example.org/purchaseOntology#"
   }

ontology _"http://example.org/BookTicketInterfaceOntology#"
   nonFunctionalProperties
      dc#title hasValue "Book Ticket Interface Ontology"
      dc#creator hasValue "DERI Innsbruck"
      dc#description hasValue "an ontology  that redefines concepts and
         relations from other ontologies in order to reuse them in the
         choreography and orchestration; two additional non-functional
         properties are defined for the targeted concepts and relations:
         mode and grounding"
      dc#publisher hasValue "DERI International"
   endNonFunctionalProperties

   importsOntology { _"http://www.example.org/tripReservationOntology",
       _"http://www.wsmo.org/ontologies/purchaseOntology"
    }

  concept reservationRequest subConceptOf tr#reservationRequest
      nonFunctionalProperties
          wsml#mode hasValue wsml#in
          wsml#grounding hasValue reservationWSDL#reservationRequest
      endNonFunctionalProperties

  concept reservation subConceptOf tr#reservation
      nonFunctionalProperties
          wsml#mode hasValue wsml#out
          wsml#grounding hasValue reservationWSDL#reservation
      endNonFunctionalProperties

  concept temporaryReservation subConceptOf tr#reservation
      nonFunctionalProperties
          wsml#mode hasValue wsml#controlled
      endNonFunctionalProperties

  concept creditCard subConceptOf po#creditCard
      nonFunctionalProperties
          wsml#mode hasValue wsml#in
          wsml#grounding hasValue reservationWSDL#creditCard
      endNonFunctionalProperties

 concept negativeAcknowledgement
     nonFunctionalProperties
         wsml#mode hasValue wsml#out
         wsml#grounding hasValue reservationWSDL#negAck
     endNonFunctionalProperties

The guarded transitions are rules that are triggered when the current state fulfils certain conditions. This is done by checking the values of the attributes of the instances from the state ontology or the existence of certain instances in the state ontology in the current state. When this is the case a transition to a new state is performed, by changing the values of some of the attributes of the instances from the state ontology or by adding new instances to this ontology. The choreography defined in this example has three transition rules.

Listing 11. Definition of the guarded transition rules for the "Book Ticket Web Service" choreography
guardedTransitions BookTicketChoreographyTransitionRules

 if  (reservationRequestInstance [
          reservationItem hasValue ?trip,
          reservationHolder hasValue ?reservationHolder
      ] memberOf bti#reservationRequest
     and
     ?trip memberOf tr#tripFromAustria
     and 
     ticketInstance[
         trip hasValue ?trip,
         recordLocatorNumber hasValue ?rln
     ] memberOf tr#ticket
     then
      temporaryReservationInstance[
          reservationItem hasValue ticketInstance,
          reservationHolder hasValue ?reservationHolder
      ] memberOf bti#temporaryReservation

 if (temporaryReservationInstance[
         reservationItem hasValue ticketInstance,
         reservationHolder hasValue ?reservationHolder
     ] memberOf bti#temporaryReservation
     and
     creditCardInstance memberOf bti#creditCard
     and
     po#validCreditCard(creditCardInstance))
 then
      reservationInstance[
         reservationItem hasValue ticketInstance,
         reservationHolder hasValue ?reservationHolder
      ]memberOf bti#reservation

 if (temporaryReservationInstance [
         reservationItem hasValue ticketInstance,
         reservationHolder hasValue ?reservationHolder
     ] memberOf bti#temporaryReservation
     and
     creditCardInstance memberOf bti#creditCard
     and
     neg (po#validCreditCard(creditCardInstance)))
 then
      negativeAcknowledgementInstance memberOf bti#negativeAcknowledgement

The first rule checks whether a reservation request instance exists (i.e. it has been already received, since the corresponding concept has the mode in) with the request for a trip that starts in Austria and whether there a ticket instance for the desired trip in the Web service instance store. If this is the case, it creates a temporary reservation for that ticket. The next step is to wait for a credit card information, to check whether it points to a valid credit card and if this is the case to create a reservation instance. This is depicted by the second guarded transition rule. In case the received credit card information points to an invalid credit card, a negative acknowledgement instance is created. This is depicted by the third transition rule.

4.2.2.2 Orchestration

The orchestration of a WSMO Web service defines how a Web service makes use of other WSMO Web services or goals in order to achieve its capability. Like for the choreography, an orchestration description has two parts: the state and the guarded transitions. A state is represented by an ontology, while guarded transitions are if-then rules that specify transitions between states.

Listing 12. Definition of the "Book Ticket Web Service" orchestration
orchestration BookTicketOrchestration
   state _"http://example.org/BookTicketInterfaceOntology"
   guardedTransitions BookTicketOrchestrationTransitionRules

In extention to the choreography, in an orchestration can also appear transition rules that have as postcondition the invocation of a mediator. Such a mediator is used for linking the orchestration with the choreography of a required Web service. This is done either directly, when the required Web service is known (the type of the mediator being wwMediator) or indirectly, via a goal, when the required Web service is not known (the type of the mediator being wgMediator).

Listing 13. Definition of the guarded transition rules for the "Book Ticket Web Service" orchestration
guardedTransitions BookTicketOrchestrationTransitionRules

  if (creditCardInstance[
         type hasValue "PlasticBuy"
     ] memberOf bti#creditCard
     and
     po#validCreditCard(creditCardInstance))
 then
      _"http://example.org/BookTicketPlasticBuyMediator"

 if (creditCardInstance[
         type hasValue "GoldenCard"
     ] memberOf bti#creditCard
     and
     po#validCreditCard(creditCardInstance))
 then
      _"http://example.org/BookTicketGoldenCardMediator"

Thus, the orchestration of this Web service is described by two transition rules. These transition rules specify that when a valid credit card is received, depending on its type, the appropriate Web service for payment is invoked. As already described in its capability, this Web service only accepts PlasticBuy or GoldenCard credit cards. The invocation of one of the payment Web services is done using one of the two wwMediators, BookTicketPlasticBuyMediator or BookTicketGoldenCardMediator.

4.3 Goals

A goal specifies objectives that a client might have when consulting a Web service, i.e. functionalities that a Web service should provide from the user perspective. The coexistence of goals and Web services as non-overlapping entities ensures the decoupling between request and Web service. The requester, either human or machine, defines a goal to be resolved and the Web Service Discovery detects suitable Web services for solving the goal automatically. This kind of stating problems, in which the requester formulates objectives independent/ without regard to Web services for resolution is known as the goal-driven approach, derived from the AI rational agent approach.

A goal in WSMO is described by non-functional properties, imported ontologies, used mediators, requested capability and requested interface.

As already described in Section 3, our scenario is that a user wants to buy a ticket from Innsbruck (Austria) to Venice (Italy) on the date of 15 June 2005. A goal is abstracted from this user desire that does not include the desired date for the trip, because this information is not considered relevant in the Web Service Discovery phase. Usually, a Web service will not advertise that it sells tickets only for certain dates and since the goal will have to be matched with one or more Web service capabilities, there is no point in making it more complex than any of these Web services capabilities.

A goal declaration starts with the keyword goal followed by the goal identifier. Optionally a set of non-functional properties follows, those being defined in a similar fashion with the non-functional properties for the components already described.

Furthermore, a goal can import existing ontologies to make use of ontological knowledge defined elsewhere, either directly, or via ontology-to-ontology mediators. The goal described above makes use of three ontologies, no mediation being needed. Another type of resources that can be reused within the definition of a goal via mediators are another goals. The mediation between two goals is realized by a type of mediators named goal-to-goal mediators. The relation between a goal and another goal imported via such a mediator is one of refinement. More generic goals are reused by specifying additional constraints. For example, the goal described above, abstracted from the user's desires, can be based on another goal, more generic, that says only that the intent is to have a reservation for a ticket for any trip. For the moment it is not defined how the goal-to-goal mediator achieves its functionality and how the functionality of the generic goal is refined by the concrete goal. When this will be defined, the generic goal will be included in the example and the concrete goal will only reuse this goal.

Below is the definition of the concrete goal previously described:

Listing 14. Goal declaration
namespace {_"http://example.org/goals#",
   tr        _"http://example.org/tripReservationOntology",
   loc     _"http://www.wsmo.org/ontologies/locationOntology#"}

goal  _"http://example.org/havingATicketReservationInnsbruckVenice"
  importsOntology {_"http://example.org/tripReservationOntology",
            _"http://www.wsmo.org/ontologies/locationOntology"}
  capability
      postcondition
           definedBy
              ?reservation[
                  reservationHolder hasValue ?reservationHolder,
                  item hasValue ?ticket
               ] memberOf tr#reservation 
               and
               ?ticket[
                 trip hasValue ?trip
              ] memberOf tr#ticket
              and
              ?trip [
                 origin hasValue loc#innsbruck,
                 destination hasValue loc#venice
              ] memberOf tr#trip.

The main element that appears in the declaration of a goal is the requested capability, which specifies the functionality required from a Web service. This is declared in the same way as a Web service capability, by using the keyword capability followed by the actual declaration. As described in the scenario above, the user expects to find a Web service, which as a result of its execution offers a reservation for a ticket for the desired trip. Thus, the only element of the capability the user is interested in, is its postcondition.

The user has also the possibility to specify the desired way of interacting with the Web service by declaring the requested interface. Such a declaration is done using the keyword interface followed by a declaration of some interface. It is not the case in this example.

4.4 Mediators

The existence of mediators allows one to link possibly heterogeneous resources. Mediators resolve incompatibilities that arise at different levels:

In the general case WSMO defines mediators by means of non-functional properties, imported ontologies, source component, target component and mediation service, where source and target component can be a mediator, a Web service, an ontology or a goal. As it was anticipated in Section 2.2 the current version of the WSMO specification distinguishes among four types of mediators: ooMediators, ggMediators, wgMediators and wwMediators.

4.4.1 OOMediators

OOMediators allow any WSMO component to import an ontology by solving all the terminological mismatches that can appear during the process. Ontology mediation may be done in more than one step, hence the possibility for an ooMediator to mediate between an ontology and another ooMediator. The listing below contains the declaration of the ooMediator used by the "Trip Reservation Ontology" (target) for importing the "OWL Person Ontology" (source).

Listing 15. OOMediator for importing the "OWL Person Ontology" into the "Trip Reservation Ontology"
namespace{_"http://example.org/mediators#",
  dc     _"http://purl.org/dc/elements/1.1" ,
  wsml   _"http://www.wsmo.org/wsml/wsml-syntax#"
}
ooMediator _"http://example.org/owlPersonMediator"
  nonFunctionalProperties
     dc#title hasValue "OO Mediator importing the OWL Person ontology to WSML"
     dc#creator hasValue _"http://example.org/foaf#deri"
     dc#description hasValue "Mediator to import an OWL person ontology into a WSML
           trip reservation ontology"
     dc#publisher hasValue _"http://example.org/foaf#deri"
     dc#contributor hasValue _"http://example.org/foaf#lausen"
     dc#language hasValue "en-us"
     dc#relation hasValue {_"http://daml.umbc.edu/ontologies/ittalks/person/",
                           _"http://example.org/tripReservationOntology"}
     dc#rights hasValue _"http://www.deri.org/privacy.html"
     wsml#version hasValue "$Revision: 1.7 $"
  endNonFunctionalProperties
  source _"http://daml.umbc.edu/ontologies/ittalks/person/"
  target _"http://example.org/tripReservationOntology"
  usesService  _"http://example.org/OWL2WSML"

4.4.2 GGMediators

GGmediators can link a goal to another goal. Like in the case of ontologies, mediation between goals can be done in more than one step, hence the possibility to have ggMediators that have as source or target other ggMediators. The link represents the refinement of the source goal into the target goal, allowing the definition of sub-goal hierarchies. Assuming that for our use case, besides the concrete goal, a generic goal was also defined, as described in Section 4.3, a ggMediator will be used for linking the two goals. This mediator is described in Listing 16. GGMediators can also use ooMediators for resolving terminology mismatches between the vocabularies used for description of goals, but this is not the case for the VTA example.

Listing 16. GGMediator that allows the concrete goal to reuse the generic goal
namespace { _"http://www.example.org/mediators",
    dc#  _"http://purl.org/dc/elements/1.1#",
       wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}
ggMediator _"http://www.example.org/ggMed"
   nonFunctionalProperties
      dc#title hasValue "GG Mediator that links the generic goal for
           reserving tickets with a concrete goal for reserving a ticket
           for a trip from Innsbruck to Venice"
      dc#creator hasValue _"http://example.org/foaf#deri"
      dc#publisher hasValue _"http://example.org/foaf#deri"
      dc#contributor hasValue _"http://example.org/foaf#stollberg"
      dc#format hasValue "text/html"
      dc#identifier hasValue _"http://example.org/ggmed"
      dc#language hasValue "en-us"
      dc#relation hasValue {
        _"http://example.org/havingATicketReservationInnsbruckVenice",
        _"http://example.org/havingATicketReservation"}
      dc#rights hasValue _"http://deri.at/privacy.html"
      wsml#version hasValue "$Revision: 1.7 $"
   endNonFunctionalProperties
   source _"http://example.org/havingATicketReservationInnsbruckVenice"
   target  _"http://example.org/havingATicketReservation"

4.4.3 WG Mediators

WGMediators are mediators that link Web services to goals. A wgMediator has- depending on which is the source and target of the mediator - one of the following functions: (1) it links a goal to a Web service via its choreography interface meaning that the Web service (totally or partially) fulfills the goal to which it is linked (2) it links a Web service to a goal via its orchestration interface meaning that the Web service needs this goal to be resolved in order to fulfil the functionality described in its capability. A wgMediator can be defined for the VTA use case that links the concrete goal "reserve a ticket for a trip from Innsbruck to Venice" (source) with the Book Ticket Web service (target).

Listing 17. WGMediator that links the "Book Ticket Web Service" with a related goal
namespace{ _"http://example.org/mediators",
    wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}
wgMediator _"http://example.org/wgMed"
  nonFunctionalProperties
    dc#title hasValue "WG Mediator that links the Book Ticket Web
    service with the goal that specifies the requirement of having a
    ticket reservation for a trip from Innsbruck to Venice"
  endNonFunctionalProperties
  source  _"http://example.org/BookTicketWebService"
  target _"http://example.org/havingATicketReservationInnsbruckVenice"

4.4.4 WWMediators

WWMediators link two Web services in order to enable interoperability of heterogeneous Web services. In the orchestration of the "Book Ticket Web Service" two such mediators are used for realizing the connection with the two Web services for payment, belonging to PlasticBuy, respectively GoldenCard. Listing 18 presents the definition of the BookTicketPlasticBuyMediator.

Listing 18. WWMediator that links the orchestration of the
"Book Ticket Web Service" with the choreography of the "PlasticBuy Web Service"
namespace{ _"http://example.org/mediators",
  wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}

wwMediator _"http://example.org/BookTicketPlasticBuyMediator"
  nonFunctionalProperties
    dc#title hasValue "WWMediator that links the orchestration of the
    Book Ticket Web service with the choreography of the PlasticBuy Web service"
  endNonFunctionalProperties
  source  _"http://example.org/BookTicketWebService"
  target _"http://example.org/PlasticBuyWebService"

5. Conclusions

This document presented how the main elements defined by the WSMO specification, ontologies, goals, Web services and mediators, and their subcomponents can be modeled in WSMO by providing examples for each of them. Due to the core design principles that underpin WSMO, decoupling and mediation, describing the various aspects of Semantic Web services can be done in an efficient and simple way.

For some parts of the specification, like the mediators, the work is in progress. In the future versions, the primer will include more detailed examples for modeling these parts.

Acknowledgments

The work is funded by the European Commission under the projects DIP, Knowledge Web, InfraWebs, SEKT, SWWS, ASG and Esperonto; by Science Foundation Ireland under the DERI-Lion project; by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW² and TSC.

The editor would like to thank to all the members of the WSMO, WSML, and WSMX working groups for their advice and input into this document.

References

[Baida et al., 2004] Z. Baida, J. Gordijn, B. Omelayenko and H. Akkermans: A Shared Service Terminology for Online Service Provisioning, ICEC '04: Proceedings of the 6th International Conference on Electronic Commerce, p.1-10, 2004.

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

[FOAF] D. Brickley and L. Miller: FOAF Vocabulary Specification, available at: http://xmlns.com/foaf/0.1/.

[Gruber, 1993] T. Gruber: A translation approach to portable ontology specifications, Knowledge Acquisition, 5:199-220, 1993.

[ISO639] International Organization for Standardization (ISO): ISO 639:1988 (E/F). Code for the Representation of Names of Languages. First edition. Reference number: ISO 639:1988 (E/F). Geneva: International Organization for Standardization, 1988.

[ISO8601] International Organization for Standardization (ISO): ISO 8601:2000. Representation of Dates and Times. Second edition. Geneva: International Organization for Standardization, 2004.

[OWLSemantics] P. F. Patel-Schneider, P. Hayes, and I. Horrocks: OWL web ontology language semantics and abstract syntax. Recommendation 10 February 2004, W3C. Available from http://www.w3.org/TR/owl-semantics/.

[Preist, 2004] Chris Preist. A Conceptual Architecture for Semantic Web Services. In Proceedings of the International Semantic Web Conference 2004 (ISWC 2004), November 2004.

Appendix

Here you can find the WSML definitions for the entities used to describe the use case that guides the primer. While all these definitions have been already presented throughout the document, the definitions of certain entities (e.g. the Trip Reservation Ontology) are spread in different listings or interleaved with the definitions of other entities. Hence, the need for this integrated listing.

/*************************************
The Trip Reservation Ontology
************************************/

namespace {_"http://example.org/tripReservationOntology#",
  dc     _"http://purl.org/dc/elements/1.1#",
  loc    _"http://example.org/locationOntology#",
  po     _"http://example.org/purchaseOntology#",
  foaf   _"http://xmlns.com/foaf/0.1/",
  wsml   _"http://www.wsmo.org/wsml/wsml-syntax#",
  prs    _"http://example.org/owlPersonMediator#"}

ontology  _"http://example.org/tripReservationOntology"
  nonFunctionalProperties
    dc#title hasValue "Trip Reservation Ontology"
    dc#identifier hasValue _"http://example.org/tripReservationOntology"
    dc#creator hasValue _"http://example.org/foaf#deri"
    dc#description hasValue
       "an ontology for describing trip reservations related knowledge"
    dc#publisher hasValue _"http://example.org/foaf#deri"
    dc#contributor hasValue  _"http://example.org/foaf#cristina"
    dc#date hasValue _date(2004,12,16)
    dc#format hasValue "text/x-wsml"
    dc#language hasValue "en-us"
    dc#rights hasValue _"http://deri.at/privacy.html"
    wsml#version hasValue "$Revision 1.17 $"
  endNonFunctionalProperties

  importsOntology{ _"http://example.org/locationOntology",
                   _"http://example.org/purchaseOntology"}

  usesMediator _"http://example.org/owlPersonMediator"

  concept trip
    origin impliesType loc#location
    destination impliesType loc#location
    departure ofType _date
    arrival ofType _date

  concept tripFromAustria subConceptOf trip
    nonFunctionalProperties
       dc#relation hasValue tripFromAustriaDef
    endNonFunctionalProperties

  axiom tripFromAustriaDef
    definedBy
         forall {?x ,?origin}
                (?x memberOf tripFromAustria
                  implies
                  ?x[
                      origin hasValue ?origin] and
                  ?origin[
                      loc#locatedIn hasValue loc#austria]
                ).

  concept ticket
    provider ofType _string
    trip ofType trip
    recordLocatorNumber ofType _integer

  concept reservationRequest
    nonFunctionalProperties
      dc#description hasValue "This concept represents a
      reservation request for some trip for a particular person"
    endNonFunctionalProperties
    reservationItem impliesType wsml#true
    reservationHolder impliesType prs#person

  concept reservation
    nonFunctionalProperties
       dc#description hasValue "concept of a confirmation for some item"
    endNonFunctionalProperties
    reservationItem impliesType wsml#true
    reservationHolder impliesType prs#person

  relation ticketPrice(ofType ticket, ofType po#currency, ofType _integer)
  nonFunctionalProperties
     dc#description hasValue
         "Function that returns the price of a ticket in a given currency"
     dc#relation hasValue {FunctionalDependencyTripPrice}
   endNonFunctionalProperties

  axiom FunctionalDependencyTicketPrice
definedBy
!- ticketPrice(?x,?y,?z1) and ticketPrice(?x,?y,?z2) and ?z1 != ?z2. instance tripInnVen memberOf trip origin hasValue loc#innsbruck destination hasValue loc#venice departure hasValue _date(2005,11,22) arrival hasValue _date(2005,11,22) instance ticketInnVen memberOf ticket provider hasValue "Book Ticket Service" trip hasValue tripInnVen recordLocatorNumber hasValue 27 relationInstance ticketPrice(ticketInnVen, po#euro, 120) /************************************* The Purchase Ontology ************************************/ namespace { _"http://example.org/purchaseOntology#", dc _"http://purl.org/dc/elements/1.1", wsml _"http://www.wsmo.org/wsml/wsml-syntax#", prs _"http://example.org/owlPersonMediator#"} ontology _"http://example.org/purchaseOntology" usesMediator _"http://example.org/owlPersonMediator" concept creditCard owner impliesType prs#person number ofType _integer type ofType _string expiryDate ofType _date balance ofType _integer relation validCreditCard(ofType creditCard) nonFunctionalProperties dc#description hasValue "Relation that holds for a valid credit card" dc#relation hasValue ValidCreditCardDef endNonFunctionalProperties axiom ValidCreditCardDef definedBy forall {?x, ?y} ( validCreditCard(?x) impliedBy ?x[expiryDate hasValue ?y] memberOf creditCard and neg (wsml#dateLessThan(?y, wsml#currentDate()))). relationInstance TicketPrice(ticketInnVen, po#euro, 120) /********************************************** The Book Ticket Interface Ontology **********************************************/ namespace {_"http://example.org/BookTicketInterfaceOntology#", dc _"http://purl.org/dc/elements/1.1#", tr _"http://example.org/tripReservationOntology#", wsml _"http://www.wsmo.org/wsml/wsml-syntax#", po _"http:/example.org/purchaseOntology#" } ontology _"http://example.org/BookTicketInterfaceOntology#" nonFunctionalProperties dc#title hasValue "Book Ticket Interface Ontology" dc#creator hasValue "DERI Innsbruck" dc#description hasValue "an ontology that redefines concepts and relations from other ontologies in order to reuse them in the choreography and orchestration; two additional non-functional properties are defined for the targeted concepts and relations: mode and grounding" dc#publisher hasValue "DERI International" endNonFunctionalProperties importsOntology { _"http://www.example.org/tripReservationOntology", _"http://www.wsmo.org/ontologies/purchaseOntology" } concept reservationRequest subConceptOf tr#reservationRequest nonFunctionalProperties wsml#mode hasValue wsml#in wsml#grounding hasValue reservationWSDL#reservationRequest endNonFunctionalProperties concept reservation subConceptOf tr#reservation nonFunctionalProperties wsml#mode hasValue wsml#out wsml#grounding hasValue reservationWSDL#reservation endNonFunctionalProperties concept temporaryReservation subConceptOf tr#reservation nonFunctionalProperties wsml#mode hasValue wsml#controlled endNonFunctionalProperties concept creditCard subConceptOf po#creditCard nonFunctionalProperties wsml#mode hasValue wsml#in wsml#grounding hasValue reservationWSDL#creditCard endNonFunctionalProperties concept negativeAcknowledgement nonFunctionalProperties wsml#mode hasValue wsml#out wsml#grounding hasValue reservationWSDL#negAck endNonFunctionalProperties /************************************* The Book Ticket Web service ************************************/ namespace {_"http://example.org/bookTicket#", dc _"http://purl.org/dc/elements/1.1#", tr _"http://example.org/tripReservationOntology#", foaf _"http://xmlns.com/foaf/0.1/", wsml _"http://www.wsmo.org/wsml/wsml-syntax#", bti _"http://www.example.org/BookTicketInterfaceOntology#"} webService _"http://example.org/bookTicketWebService" importsOntology _"http://example.org/tripReservationOntology" capability BookTicketCapability sharedVariables {?creditCard, ?initialBalance, ?trip, ?reservationHolder, ?ticket} precondition nonFunctionalProperties dc#description hasValue "The information of a trip which starts in Austria together with the information about the person who wants to have a reservation must be given as a part of a reservation request. A credit card is also required." endNonFunctionalProperties definedBy ?reservationRequest[ reservationItem hasValue ?trip, reservationHolder hasValue ?reservationHolder ] memberOf tr#reservationRequest and ?trip memberOf tr#tripFromAustria and ?creditCard[ balance hasValue ?initialBalance ] memberOf po#creditCard. assumption nonFunctionalProperties dc#description hasValue "The credit information provided by the requester must designate a valid credit card that should be either PlasticBuy or GoldenCard." endNonFunctionalProperties definedBy po#validCreditCard(?creditCard) and ( ?creditCard[ type hasValue "PlasticBuy"] or ?creditCard[ type hasValue "GoldenCard"] ). postcondition nonFunctionalProperties dc#description hasValue "A reservation containing the details of a ticket for the desired trip and the reservation holder is the result of the successful execution of the Web service." endNonFunctionalProperties definedBy ?reservation memberOf tr#reservation[ reservationItem hasValue ?ticket, reservationHolder hasValue ?reservationHolder ] and ?ticket[ trip hasValue ?trip ] memberOf tr#ticket. effect nonFunctionalProperties dc#description hasValue "The credit card will be charged with the cost of the ticket." endNonFunctionalProperties definedBy ticketPrice(?ticket, "euro", ?ticketPrice) and ?finalBalance= (?initialBalance - ?ticketPrice) and ?creditCard[ po#balance hasValue ?finalBalance ] . interface BookTicketInterface choreography BookTicketChoreography state _"http://example.org/BookTicketInterfaceOntology" guardedTransitions BookTicketTransitionRules guardedTransitions BookTicketChoreographyTransitionRules if (reservationRequestInstance [ reservationItem hasValue ?trip, reservationHolder hasValue ?reservationHolder ] memberOf bti#reservationRequest and ?trip memberOf tr#tripFromAustria and ticketInstance[ trip hasValue ?trip, recordLocatorNumber hasValue ?rln ]memberOf tr#ticket then temporaryReservationInstance[ reservationItem hasValue ticketInstance, reservationHolder hasValue ?reservationHolder ] memberOf bti#temporaryReservation if (temporaryReservationInstance[ reservationItem hasValue ticketInstance, reservationHolder hasValue ?reservationHolder ] memberOf bti#temporaryReservation and creditCardInstance memberOf bti#creditCard and po#validCreditCard(creditCardInstance)) then reservationInstance[ reservationItem hasValue ticketInstance, reservationHolder hasValue ?reservationHolder ]memberOf bti#reservation if (temporaryReservationInstance [ reservationItem hasValue ticketInstance, reservationHolder hasValue ?reservationHolder ]memberOf bti#temporaryReservation and creditCardInstance memberOf bti#creditCard and neg (po#validCreditCard(creditCardInstance))) then negativeAcknowledgementInstance memberOf bti#negativeAcknowledgement orchestration BookTicketOrchestration state _"http://example.org/BookTicketInterfaceOntology" guardedTransitions BookTicketOrchestrationTransitionRules if (creditCardInstance[ type hasValue "PlasticBuy" ] memberOf bti#creditCard and po#validCreditCard(creditCardInstance)) then _"http://example.org/BookTicketPlasticBuyMediator" if (creditCardInstance[ type hasValue "GoldenCard" ] memberOf bti#creditCard and po#validCreditCard(creditCardInstance)) then _"http://example.org/BookTicketGoldenCardMediator" /************************************************************** The goal of booking a ticket for a trip from Innsbruck to Venice ***************************************************************/ namespace {_"http://example.org/goals#", tr _"http://example.org/tripReservationOntology", loc _"http://www.wsmo.org/ontologies/locationOntology#"} goal _"http://example.org/havingATicketReservationInnsbruckVenice" importsOntology {_"http://example.org/tripReservationOntology", _"http://www.wsmo.org/ontologies/locationOntology"} capability postcondition definedBy ?reservation[ reservationHolder hasValue ?reservationHolder, item hasValue ?ticket ] memberOf tr#reservation and ?ticket[ trip hasValue ?trip ] memberOf tr#ticket and ?trip [ origin hasValue loc#innsbruck, destination hasValue loc#venice ] memberOf tr#trip. /************************************************************** An example of oomediator ***************************************************************/ namespace{_"http://example.org/mediators#", dc _"http://purl.org/dc/elements/1.1" , wsml _"http://www.wsmo.org/wsml/wsml-syntax#" } ooMediator _"http://example.org/owlPersonMediator" nonFunctionalProperties dc#title hasValue "OO Mediator importing the OWL Person ontology to WSML" dc#creator hasValue _"http://example.org/foaf#deri" dc#description hasValue "Mediator to import an OWL person ontology into a WSML trip reservation ontology" dc#publisher hasValue _"http://example.org/foaf#deri" dc#contributor hasValue _"http://example.org/foaf#lausen" dc#language hasValue "en-us" dc#relation hasValue {_"http://daml.umbc.edu/ontologies/ittalks/person/", _"http://example.org/tripReservationOntology"} dc#rights hasValue _"http://www.deri.org/privacy.html" wsml#version hasValue "$Revision: 1.7 $" endNonFunctionalProperties source _"http://daml.umbc.edu/ontologies/ittalks/person/" target _"http://example.org/tripReservationOntology" usesService _"http://example.org/OWL2WSML" /************************************************************** An example of ggmediator ***************************************************************/ namespace { _"http://www.example.org/mediators", dc _"http://purl.org/dc/elements/1.1#", wsml _"http://www.wsmo.org/wsml/wsml-syntax#" } ggMediator _"http://www.example.org/ggMed" nonFunctionalProperties dc#title hasValue "GG Mediator that links the generic goal for reserving tickets with a concrete goal for reserving a ticket for a trip from Innsbruck to Venice" dc#creator hasValue _"http://example.org/foaf#deri" dc#publisher hasValue _"http://example.org/foaf#deri" dc#contributor hasValue _"http://example.org/foaf#stollberg" dc#format hasValue "text/html" dc#identifier hasValue _"http://example.org/ggmed" dc#language hasValue "en-us" dc#relation hasValue { _"http://example.org/havingATicketReservationInnsbruckVenice", _"http://example.org/havingATicketReservation"} dc#rights hasValue _"http://deri.at/privacy.html" wsml#version hasValue "$Revision: 1.7 $" endNonFunctionalProperties source _"http://example.org/havingATicketReservationInnsbruckVenice" target _"http://example.org/havingATicketReservation" /************************************************************** An example of wgmediator ***************************************************************/ namespace{ _"http://example.org/mediators", wsml _"http://www.wsmo.org/wsml/wsml-syntax#" } wgMediator _"http://example.org/wgMed" nonFunctionalProperties dc#title hasValue "WG Mediator that links the Book Ticket Web service with the goal that specifies the requirement of having a ticket reservation for a trip from Innsbruck to Venice" endNonFunctionalProperties source _"http://example.org/BookTicketWebService" target _"http://example.org/havingATicketReservationInnsbruckVenice" /************************************************************** An example of wwmediator ***************************************************************/ namespace{ _"http://example.org/mediators", wsml _"http://www.wsmo.org/wsml/wsml-syntax#" } wwMediator _"http://example.org/BookTicketPlasticBuyMediator" nonFunctionalProperties dc#title hasValue "WWMediator that links the orchestration of the Book Ticket Web service with the choreography of the PlasticBuy Web service" endNonFunctionalProperties source _"http://example.org/bookTicketWebService" target _"http://example.org/PlasticBuyWebService"