wsmo logo

D3.3 v0.1 WSMO Use Case "Virtual Travel Agency"

WSMO Working Draft 19 November 2004

This version:
http://www.wsmo.org/2004/d3/d3.3/v0.1/20041119/
Latest version:
http://www.wsmo.org/2004/d3/d3.3/v0.1/
Previous version:
http://www.wsmo.org/2004/d3/d3.3/v0.1/200411105/
 
Editors:
Michael Stollberg
Rubén Lara
 
Authors:
Michael Stollberg
Holger Lausen
Rubén Lara
Uwe Keller
Michal Zaremba
Armin Haller
Dieter Fensel
Michael Kifer
 
Reviewer:
Jos de Bruijn

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.


Abstract

This document specifies a concrete use case for modeling Semantic Web Services with the Web Service Modeling Ontology WSMO in the domain of e-tourism. A Virtual Travel Agency sells tickets for international train tickets, and a customer defines a Goal for purchasing such a ticket. This use case has been the initial WSMO Use Case defined in previous versions of the WSMO D3.2 Deliverable - WSMO Use Case and Testing. The main focus of this document is the concrete modeling of the top WSMO components, resulting in the specification of WSML, and to test and elaborate the approach and technologies for Web Service Discovery in WSMO.

For use case modeling, we stick to the final working draft of Web Service Modeling Ontology WSMO, Version 1.0, 20 September 2004 [Roman et al., 2004].

Related Documents

WSMO Standard: D2 v1.0 Web Service Modeling Ontology (WSMO), last version at: http://www.wsmo.org/2004/d2/

WSMO Primer: D3.1 v0.1 WSMO Primer

Web Service Modeling Language WSML: D16 v0.2 WSMO The WSML Family of Representation Languages

WSMO Discovery: D5.1 v0.1 WSMO Discovery


Table of Contents

1. Introduction
2. Use Case Overview
2.1 Description
2.2 Scope
2.3 Actors, Roles and Goals
2.4 Usage Scenarios
2.5 System Architecture
3. WSMO Use Case Modeling
3.1 Ontologies
   3.1.1 International Train Ticket Ontology
   3.1.2 Date and Time Ontology
   3.1.3 Purchase Ontology
   3.1.4 Location Ontology
   3.1.5 VTA Use Case Knowledge Base
3.2 Goals
3.3 Web Services
3.4 Mediators
   3.4.1 OO Mediators
    3.4.2 WG Mediators
    3.4.3 GG Mediators
    3.4.4 WW Mediators
4. Web Service Discovery within WSMO
5. Conclusions and Future Work
References
Acknowledgements
 
Appendix A: Change Tracking
Appendix B: Related Resources
B.1 Used Ontologies in OWL
B.2 Related Ontologies

1. Introduction

This use case is defined in the domain of e-tourism: a Virtual Travel Agency sells tickets for international train tickets, and a customer defines a Goal for purchasing such a ticket. Using the conceptual framework of WSMO we specify the top-level notions of Ontologies, Goals, Web Services and Mediators for this use case.

A Web Service of a Virtual Travel Agency, short: VTA, offers end-user services for searching and buying train tickets for itineraries in Austria and in Germany. This Web Service is composed out of other Web Services, namely one for searching existing train connections, and one for purchasing train tickets online. As a user request we assume that the user wants to purchase an international train ticket. The course of the use case shall be the following:

This document is structured as follows: Section 2 gives and overview of the use case, describing the overall setting for of the use case and identifying the technical challenges arising for Semantic Web Service technologies; Section 3 defines the needed WSMO components and provides the WSML models for the distinct WSMO components of the use case along with explanations of the design and modeling decisions; Section 4 explains the WSMO Discovery as realized within this use case; finally, Section 5 concludes the use case. Appendix A provides a change tracking to previous version of the document; Appendix B provides related resources for this use case.

 

2. Use Case Overview

According to the general framework for defining use cases for WSMO defined in WSMO Use Case Overview document, section 2, this section provides a description of the setting of this use case. In [He et al., 2004], the travel agency use case is separated into two use cases - one with static discovery and one with automated discovery. With Semantic Web Services we clearly want to support automated discovery.

2.1 Description

Imagine a “Virtual Traveling Agency”, called VTA for short, which is an end user service providing eTourism services to customers. These services can cover all kinds of information services concerned with tourism information - from information about events and sights in an area to services that support booking of flights, hotels, rental cars, etc. online. Such VTAs are already existent, currently those portals are accessible via html sites. The partners of the VTA are integrated via conventional B2B integration. By applying Semantic Web Services, a VTA will be more easily be able to configure an invoke Web Services provided by several eTourism suppliers and aggregate them into new customer services. Such VTAs providing automated eTourism services to end users via different interfaces and can be more easily reconfigured according to the actual needs..

Our VTA use case that aggregates Web Services of different tourism service providers. In a nutshell shall it provides the following functionality: A customer uses the VTA service as the entry point for his requests. These end-user services are aggregated by the VTA by invoking and combining Web Services offered by several tourism service providers. To facilitate this, there can be a so called "umbrella" contract between the service providers and the VTA for regulating usage and allowance of the Web Services. Figure 2 gives an overview (modified and extended from W3C Travel Agent Use Case overview, as defined in [He et al., 2004]).

VTA Architecture
Figure 2. Use Case Overview: Virtual Travel Agency based on Semantic Web Services

2.2 Scope

The scenario outlines a general structure for VTAs that can be extended to more complex scenarios wherein the customer can be a Web Service itself, thus creating a network of composed services that offer complex tourism services. For example, one VTA can provide flight booking services for an airline union, another VTA aggregates booking service for a worldwide hotel chain, and a third VTA provides booking services for rental cars by combining the services of several worldwide operating car rental agencies. Then, another VTA uses these services for providing an end-user service for booking complete holiday trips worldwide.

2.3 Actors, Roles and Goals

In the general use case there are 3 actors. The following defines why they participate in this use case (goal) and the particular interactions they are involved in (roles).

  1. Customer: the end-user that requests a service provided by the VTA
      - Goal: automated resolution of the request by a user-friendly tourism service
      - Role: end-user, interacts with VTA for service usage, payment, and non-computational assets (e.g. receiving the actual ticket when booking a trip)
  2. Tourism Service Providers: commercial companies that provides specific tourism services
      - Goal: sell service to end customers, maximize profit as a commercial company
      - Role: provides tourism service as a Web Service (also provides the necessary semantic descriptions of the Web Services), may have a usage and allowance contract with the VTA
  3. VTA: the intermediate between the Customer and the Tourism Service Providers. It provides tourism services to customers by aggregating the separate services provided by the single Service Providers.
      - Goal: provide high-quality end-user tourism services, uses existing tourism services and aggregates these into new services, maximize profit as a commercial company / represent union of service providers (depending on the owners of the VTA).
      - Role: interacting with customer via user interface (can be web-based for direct human customers interaction or via Web Services for machine-users), usage and allowance contract for Web Services offered by Service Providers, centrally holding all functionalities for handling Semantic Web Services (mechanisms for discovery, composition, execution, etc.)

2.4 Usage Scenarios

We identify the following usage scenarios

  1. VTA interacts with Service Providers on contract and Web Service usage and allowance
    - Participating Actors: VTA and Service Providers
    - Activities: business contract negotiation
    - Technological Requirements: contract information requirements are modeled in the system, i.e. Web Service usage is implemented via Policies
    - Possible Extensions: contract negotiation can be supported by automated mechanisms
  2. Customer requests VTA for searching tourism service offers, VTA detects and queries suitable Web Services and forwards results to Customer
    - Participating Actors: Customer, VTA, Tourism Service Providers
    - Activities:
       (1) Customer selects "Search" services as provided by the VTA
       (2) VTA discovers, invokes and executes corresponding Web Services
    - Technological Requirements:
       (1) VTA has to pre-define the "Search" functionality that can be requested by a Customer
       (2) the Tourism Service Providers' Web Services must be semantically described in order to support dynamic discovery (assuming that single Web Services can perform the search functionality)
       (3) VTA has to provide mechanisms for automated Service Discovery
    - Possible Extensions:
  3. Customer selects a concrete offer and requests booking for this offer (interacting with the VTA),VTA detects and aggregates Web Services for booking (incl. booking, payment, etc.), displays result to Customer and handles complete execution of customer-interaction (computational part)
    - Participating Actors: Customer, VTA, Tourism Service Providers
    - Activities:
       (1) Customer selects one concrete offer out of the Search results of usage scenario 2
       (2) VTA discovers and composes available Web Services from Service Providers and composes them into the functionality to satisfy the user request
       (3) VTA executes the Web Services in the sequence determined, controls the execution (handles errors and detects alternative paths if a Web Service fails)
       (4) VTA interacts with Customer during execution when further information is needed (e.g. a credit card number for payment)
    - Technological Requirements: contract information information requirements are modeled in the system, i.e. Web Service usage is implemented via Policies
       (1) Web Services must be semantically described in order to support dynamic discovery, composition, and execution
       (2) VTA has to hold mechanisms for automated Service Discovery, Composition, and Execution
       (3) VTA has to provide and interaction interface for contingent Customer-interaction during Service execution
    - Possible Extensions: advanced mechanisms for automated execution of aggregated Web Services
  4. VTA interacts with Customer and Service Provider for non-computational parts (e.g. delivery of actual tickets)
    - Participating Actors: Customer, VTA, Tourism Service Providers
    - Activities: customer notification, accounting, good delivery (out of computational system), etc.
    - Technological Requirements: mechanisms for notification and accounting
    - Possible Extensions: Web Services can be used for:

2.5 System Architecture

In this use case, the VTA is the central point of interaction between the Customer and other Web Services. Regarding the technological requirements, it is obvious from the usage scenario descriptions that (1) the Web Services offered by the Service Providers have to carry sufficient descriptive information to support automated Web Service usage, and (2) that the VTA has to provide all mechanisms to handle Semantic Web Services. The basic architecture of such a VTA as a central entity for Semantic Web Services handling is shown in Figure 3. The essential functionalities of Semantic Web Service enabled VTAs – with special regard to the requirements for Semantic Web Service technologies – are:

VTA Architecture
Figure 3. General Architecture of a SWS-enabled VTA

Summarizing, the VTA is a SWS-enabled B2C application that provides an end-user service following a client/server model. In order to support coherent functionality of the VTA and to ensure that the descriptions of Web Services are compatible to this, an overall framework for SWS technologies is needed. This is provided by WSMO.

Semantic Web Service technology can be applied to ease the described use case (a) for the customer (to find the VTA and resolve his goal) and (b) for the VTA that benefits from semantic description of its business partners. These ease the combination and rearrangement of existing services for the VTA and allows him to flexibly offer new services. In case composition and discovery have reached a higher level of maturity it can even be thought that the technologies (in this case discovery and composition) can be used directly by the end user. So that he himself combines the travel services offered, thus not using the extra intermediate party (the VTA).

3. WSMO Use Case Modeling

This section exemplifies the specification of this use case within the Web Service Modeling Ontology WSMO. The provided listings use the conceptual model and syntax presented in WSMO, final version 1.0 [Roman et al., 2004]. The listings provide have been validated with the WSML Online Validation Service.

The subsequent sections provide the modeling of the resources along with detailed explanations on modeling decisions and related issues. The following tables provide an overview of the resources specified in this use case.

Table 1. "International Train Ticket Ontology"
WSMO component type ontology
name International Train Ticket Ontology
description defines ontology constructs for the domain of international train connections
imported ontologies /
used mediators
- Date and Time Ontology
- Location Ontology
- OWL Person Mediator
- OWL Fact Book Mediator
main constructs main concepts:
station, itinerary, ticket, trip, traintrip
 
axioms:
stationCountry, departureBeforeArrival, startNotEqualEnd
WSML model Listing 1

 

Table 2. "Date and Time Ontology"
WSMO component type ontology
name Date and Time Ontology
description defines notions of date and time, and general interdependencies between them
imported ontologies /
used mediators
none
main constructs main concepts:
instant, interval, date, time, dateandtime
 
functions:
julianDayNumber, daysBetween, secondsBetween, secondsFromMidnight
 
relations:
contains (for intervals)
 
axioms:
equality / before / after / between for date and time notions, integrity contraints
WSML model Listing 2

 

Table 3. "Purchase Ontology"
WSMO component type ontology
name Purchase Ontology
description defines notions of purchasing, incl. buyer, seller, purchase oder, purchase partners, payment notions, etc.; based on RosettaNet , but adopted for B2C setting
imported ontologies /
used mediators
- Date an Time Ontology
- OWL Currency Mediator
main constructs main concepts:
purchase, buyer, seller, contactInformation, purchaseOrder, product, paymentMethod, paymentTerms, delivery
WSML model Listing 3

 

Table 4. "Location Ontology"
WSMO component type ontology
name Location Ontology
description defines geographical notions and postal address;
extends / combines existing domain ontologies
imported ontologies /
used mediators
- OWL Fact Book Mediator
- OWL Address Mediator
- OWL Geo Mediator
main constructs main concepts:
country, address, city, state, border, distance;
incl. concepts / attributes imported via mediators
 
functions:
distanceInKilometers, distanceInMiles,
 
relations:
equalDistance, lessThanDistance, moreThanDistance
 
axioms:
integrity contraints
WSML model Listing 4

 

Table 5. "VTA Use Case Knowledge Base"
WSMO component type ontology
name VTA Use Case Knowledge Base
description holds all pre-defined instance data needed within the use case
imported ontologies /
used mediators
- Train Connection Ontology
- Purchase Ontology
- Date and Time Ontology
- Location Ontology
main constructs instances for :
stations, currentDate, credit card types, locations (continents, countries, states, cities), drop ship carriers, transportations means
WSML model Listing 45

 

Table 6. "General Goal for buying a ticket online "
WSMO component type goal
name Buying a train ticket online
description defines the general ontological structure of goal notions for buying tickets online according to the ontologies; this goal serves as a template for concrete goals (see table 6).
imported ontologies /
used mediators
- Train Connection Ontology
- Purchase Ontology
- Location Ontology
main constructs postcondition:
purchase a ticket for an itinerary (a trip and a passenger)
 
effect:
get the purchased ticket delivered to the buyer
WSML model Listing 6

 

Table 7. "Concrete Goal for buying a ticket online "
WSMO component type goal
name Buying a train ticket from Innsbruck to Frankfurt
description Buying a train ticket online for an itinerary from Innsbruck to Frankfurt for a specific passenger with payment by credit card
This goal is derived by specializing og the general goal (table 5) via an GG Mediator (table 12)
imported ontologies /
used mediators
- Date and Time
- GG Mediator 1
main constructs postcondition:
purchase a ticket for an itinerary for a trip from Innsbruck to Frankfurt on 17th July 2004 for Tim Berners Lee, departure between 6 and 7 p.m.
 
effect:
get the purchased ticket delivered to the buyer
WSML model Listing 7

 

Table 8. "ÖBB Web Service for selling international train tickets online "
WSMO component type web service
name OEBB Online Ticket Booking Web Service
description web service for booking online train tickets for Austria and Germany, offered by the ÖBB (Austrian national train operator)
imported ontologies /
used mediators
- Train Connection Ontology
- Purchase Ontology
- Date and Time Ontology
- Location Ontology
main constructs precondition:
a buyer, and information on the trip that a ticket is searched and sold for and the passenger for whom the ticket shall be valid
 
assumption:
if the payment method is credit card, then the credit card has to be valid (i.e. not expired)
 
postcondition:
a purchase for a ticket by ÖBB as provider, for itineraries valid for a train trip with start- and endloction in Austria or Germany and for a passenger, incl. price, and payment only via credit card
 
effect:
delivery of sold ticket by drop ship carrier or by online delivery
WSML model Listing 8

 

Table 9. "OWL Address Mediator"
WSMO component type oo mediator
name importing the OWL Factbook ontology to WSML
description Mediator to import an OWL address ontology into a WSML locations ontology
imported ontologies /
used mediators
 
main constructs source component: an Address Ontology in OWL
target component: Location Ontology (Table 4)
mediation service: not specified
WSML model Listing 9

 

Table 10. "OWL Currency Mediator"
WSMO component type oo mediator
name importing the OWL Currency ontology to WSML
description Mediator to import an OWL currency ontology into a WSML purchase order ontology
imported ontologies /
used mediators
 
main constructs source component: an Currency Ontology in OWL
target component: Purchase Ontology (Table 3)
mediation service: not specified
WSML model Listing 10

 

Table 11. "OWL Factbook Mediator"
WSMO component type oo mediator
name importing the OWL Factbook ontology to WSML
description Mediator to import an OWL factbook ontology into a WSML ontology
imported ontologies /
used mediators
 
main constructs source component: the OWL Factbook (in OWL)
target component: Location Ontology (Table 4)
mediation service: not specified
WSML model Listing 11

 

Table 12. "OWL Person Mediator"
WSMO component type oo mediator
name importing the OWL Person ontology to WSML
description Mediator to import an OWL person ontology into a WSML ontology
imported ontologies /
used mediators
 
main contructs source component: a Person ontology (in OWL)
target component: Internaction Train Connection Ontology (Table 1)
mediation service: not specified
WSML model Listing 12

 

Table 13. "GG Mediator"
WSMO component type gg mediator
name GG Mediator that that links the general Goal for buying tickets with the concrete Goal for buying a train ticket from Innsbruck to Frankfurt
description Restricts the trip to train trips within Austria and Germany
imported ontologies /
used mediators
all ontologies and mediators are inherited from the source component; no additional ontologies or OO Mediators are needed
main constructs source component: general goal for buying tickets (Table 5)
target component: concrete Goal for buying a train ticket (Table 6)
mediation service: not specified
WSML model Listing 13

 

3.1 Ontologies

With regard to modularized ontologies as a basic design principle of WSMO, we define four separate domain ontologies as the the terminology definitions for the use case:

  1. "International Train Ticket" describes the domain of train tickets
  2. "Date and Time" defines a general model for specifying time and dates and relationships of them
  3. "Purchase" describes generic elements of purchasing a product between a buyer and a seller.
  4. "Locations" describes locations (such as continents, countries and cities and their interrelation).

The ontologies specified in the following are intended to be "real ontologies" in the sense that they describe the specific domain as a shared conceptualization in a sufficient manner. This allows to reuse this ontologies in different settings and use cases - for example, notions or date and time or a general purchase ontology are needed in a lot of other possible scenarios. However, we do not claim the defined below to be such generic ontologies, but they will be enhanced and completed within cooperations with other use cases, projects, and initiatives. Appendix B provides the original ontologies that are used within the domain ontologies specified in this section.

At this point in time, WSMO does not provide a technique to link to large set of instances. Therefore, in this version of the ontology we only include some example instances, which holds for the other ontologies defined in this use case as well. For reader's convenience, the relevant instances for this use case are gathererd in the VTA Use Case Knowlege Base, a separate ontology. The inclusion of links to large set of instances will be considered in future versions of WSMO.

3.1.1 International Train Ticket Ontology

The "International Train Ticket" Ontology defines a train trip and the surrounding concepts as defined the WSML definition of the ontology shown in Listing 1.

The definition of the ontology is based on the travel itinerary ontology from the DAML ontology library, which is also available in Appendix B6 in OWL abstract syntax. The ontology defines travel itineraries for trips by plane. Our ontology reuses the itinerary and flight concepts and adapt them to define train trips, also introducing new concepts such as train station. The international train ticket ontology also makes use of the person ontology defined at http://daml.umbc.edu/ontologies/ittalks/person (Appendix B1), which defines a subset of vCard. The person concept is used to define the passenger information for an itinerary. We did not find any other available ontologies that model the domain of train tickets or itineraries. The first version of the harmonize ontology for the tourism domain focuses on the events and accommodations subdomains. We will take into account future versions of the harmonise ontology, as they are likely to include the travelling subdomain.

Listing 1. Domain Ontology “International Train Ticket”

3.1.2 Date and Time Ontology

The "Date and Time Ontology" in Listing 2 defines models for dates (i.e. certain days) and time (i.e. definition of certain points in time). Further, it defines axioms that represent conventional aspects of date and time, like ´before´ and ´after´, etc. In the use case, this is needed to determine validity of train connections, e.g for ensuring that a ticket is not for an itinerary that is in the past. It also can be used generally for expressing dates and time and relationships between them.

The main ontology taken into consideration for developing this conceptual model of Date and Time is an entry sub-ontology of time, available at http://www.isi.edu/~pan/damltime/time-entry.owl. This ontology uses abstract temporal concepts like instant, interval and event and uses the Gregorian calendar as representation (partly using own encoding and partly using XSD encoding). Axioms are defined in first order logic in the accompanying paper [Pan and Hobbs]; there also is a LISP version of these axioms available at http://www.cs.rochester.edu/~ferguson/daml/daml-time-20030728.lisp. Other ontologies like COBRA calenderclock ontology (http://daml.umbc.edu/ontologies/cobra/0.4/calendarclock) are only a straight forward representation of the Gregorian calendar, without any abstraction of concepts and description of axioms. Widely used concrete representations for date and time are defined in ISO 8601 (Numeric representation of Dates and Time) and in the XML Schema Definition (http://www.w3.org/TR/xmlschema-2/), which is based on ISO 8601. In a later stage when it is clear which build in predicates can be used we will add a syntactical mapping to xsd:dateTime.

Listing 2. Domain Ontology “Date and Time”

3.1.3 Purchase Ontology

The Purchase Ontology describes the domain of purchasing within a B2C scenario. In order to base this ontology on existing, commonly accepted conceptual models for purchasing, RosettaNet's PIP3A4 "PurchaseOrderRequest" [RosettaNet] has been transformed into a WSMO ontology. However, RosettaNet as well as the other existing conceptual models for purchasing like ebXML [ebXML] and EDIFACT [EDIFACT] are designed for B2B purchase scenarios and thus not applicable for B2C settings as the one of this use case. Because of this, the Purchase Ontology defined in the folloing listing describes ontological notions relevant for purchasing within a B2C setting. We refer to the WSML representation of RosettaNet's PIP3A4 "PurchaseOrderRequest" which is provided in listing B5, Appendix B, denoting the realted concepts within the realtion attribute of the non functional properties.

The main constructs of the Purchase Ontology are :

Listing 3. Domain Ontology “Purchase”

3.1.4 Location Ontology

The "Location Ontology" defines concepts for locations, including cities and states, as well as postal addresses. This ontology is based on the DAML ontology for geographical locations (Appendix B5), an ontology describing a wide variety of locations and geographical areas. The concept country is extended using the OWL-Factbook ontology (Appendix B2). The concept address reuses the DAML address ontology (Appendix B3).

Listing 4. Domain Ontology “Locations”

3.1.5 VTA Use Case Knowledge Base

The VTA Use Case Knowledge Base holds all instance data that are needed within the use case descriptions. The knowledge base is defined as an WSMO ontology that holds instances of all four domain ontologies defined above. Within this knowlegde base, only a selection of instances is defined that is used within the subsequent WSMO component models.

Listing 5. VTA Use Case Knowledge Base

3.2. Goals

Goals denote what a user wants as the result of the Web Service. For modeling the goal, WSMO describes the information elements that the user wants to get from the service (the postcondition) together with the state of the world desired after the service execution (the effect).

In WSMO, Goals can be defined a different levels of granularity. By so-called GG Mediators, new, more specific Goals can be created out of generic existing Goals. You can also think of generic Goals as being pre-defined in a specific application context, wherefrom concrete Goals can be generated from. In order to showcase this, we define a generic Goal for buying a ticket for any kind of trip (Listing 6), a concrete Goal wherein a user wants to buy a train itinerary from Innsbruck to Frankfurt on a certain date (Listing 7), and a GG Mediator that connects the generic Goal to tickets for traintrips within Austria and Germany (see Section 3.4.3. for the GG Mediator that connects this two Goals).

Listing 6 shows the generic Goal with the following description elements:

Listing 6: Goal - buying a ticket online

The concrete Goal expresses the desire to buy a train ticket by refining the notions of the general Goal. Listing 7 shows this Goal with the following elements:

Listing 7: Goal - buying a train ticket from Innsbruck to Frankfurt online

 

3.3 Web Services

We define one (imaginary) Web Service in this use case: an end-user service (means that the user interacts with this service) for purchasing international train tickets offered by the Austrian national train operator ÖBB; this Web Service can be composed of other Web Services, each for the search and buying facility of international train tickets. This setting allows modeling all notions of a WSMO Web Service description: a Capability of the end-user service and its Choreography for user-service interaction, as well as the orchestration which incorporates the aggregated Web Services. The current version of WSMO Standard does only provide a stable specification for describing Capabilities, the model below is restricted to the overall Web Service description and the Capability definition. The modeling for the WSMO Web Service Interface will be added in a later version.

A Web Service Capability in WSMO is described by pre- and postconditions, assumptions and effects, as defined in [Roman et al., 2004]. Listing 8 shows the ÖBB Web Service description, currently the Capability only. More detailed discussion of the Discovery mechanism of WSMO Goals and Capabilities is provided in section 3.1.3. The Capability description elements are defined as follows:

Listing 8: ÖBB Web Service for Booking Online Train Tickets for Austria and Germany

 

3.4 Mediators

3.4.1 OO Mediators

OO Mediators import other ontologies or OO Mediators into WSMO entities and resolve possible terminology mismatches. If no mistach has to be resolved the syntactical simplification "importOntologies" can be used. In the following we specify the mediators used:

  1. owlAddressMediator.wsml
  2. owlCurrencyMediator.wsml
  3. owlFactbookMediator.wsml
  4. owlPersonMediator.wsml
Listing 9: OO-Mediator " importing the OWL Address Ontology to the Location Ontology"

 

Listing 10: OO-Mediator "importing the OWL Currency Ontology into the Purchase Ontology"

 

Listing 11: OO-Mediator "importing the OWL Factbook into the Location Ontology"

 

Listing 12: OO-Mediator "importing the OWL Person Ontology into the Train Connection Ontology"

Notice that the mediation service is not implemented yet. Furthermore we do not specify the capability of the mediator, since it is outside of the scope of this deliverable to define the required terminology such as an ontology about ontology languages and mediation patterns.

3.4.2 WG Mediators

A WG Mediator links a Web Service to a Goal, resolves terminological mismatches, and may state the functional difference (if any) between both. WG Mediators can be used to pre-link Services to existing Goals. For resolving terminological mismatches, OO Mediators are applied, similar to the ones specified above.

In our use case, we do not need an WG Mediator, because the Goal and the Web Service Description use the same domain ontologies (i.e. there are not terminology mismatches).

3.4.3 GG Mediators

A GG Mediator connects Goals and possible specifying the functional reduction. For example, a GG Mediator can connect a Goal "buy a ticket" with another Goal "buy a train ticket". Assuming 'train ticket' is a subclass of 'ticket', the GG Mediator would specify that the set described by the goal "buy a train ticket" is more specific then "buy a ticket".

In our use case, we have defined a generic Goal for buying a ticket for any kind of trip (Listing 6), a concrete Goal wherein a user wants to buy a train ticket from Innsbruck to Frankfurt on a certain date (Listing 7). The GG Mediator is used within the concrete Goal, so defining a connection between the general Goal as a 'template' which is 'instantiated' in the concrete Goal.

Listing 13: GG Mediator that restricts the generic Goal

3.4.4 WW Mediators

A WW Mediator allows establishing interoperability of Web Services that are not interoperable a priori by used by connecting Web Services and resolving mismtaches. The mediation facility needed for WW Mediators is to mediate between the Choreographies of Web Services that are ought to interact. This requires mediation on the data, protocol, and process level, i.e. all levels of mediation relevant for Semantic Web Services [Fensel & Bussler, 2002], in order to establish valid global interaction models of Web Services.

There is no WW Mediator in this use case as the corresponding notions of Choreography and Orchestration are still under development at this point in time. Future versions might include the definition of the composition of the search and buying service, wherein a WW Mediator might be applied.

 

4. Web Service Discovery within WSMO

Web Service Discovery is a core technology for Semantic Web Services: the aim is to detect web services that can resolve a given Goal, working on the descriptions of the goal and of web services. WSMO supports Web Service discovery by defining Goals and Web Services as top level components. Web Service discovery is a complex topic of its own, and is addressed within related documents in WSMO. Thus, we do not specify and explain realization of Web Service discovery here, but link to the related documents.

This use case has been serving as a test bed for developing the WSMO Discovery Framework that is elaborated in WSMO Deliverable 5.1 (see: http://www.wsmo.org/2004/d5/d5.1/); and it serves as the testing environment for the implementation of a WSMO discovery engine that is presented in WSMO Deliverable 5.2 (see: http://www.wsmo.org/2004/d5/d5.2/). Please refer to these documents for a complete overview of discovery within WSMO.

 

5. Conclusions

This document provides a real-world setting of using Semantic Web Services for a Virtual Travel Agency (VTA) that provides an end-user service for booking international train tickets, thereby aggregating Web Services of different e-Tourism Service Providers. We have modeled ontologies, goals, a Web Service, and OO Mediators according to their current specification status in WSMO [Roman et al., 2004].

This use case is the first, initial use case defined for testing and recursively developing WSMO. The major outcomes of this use case are:

Other use cases address different aspects of Semantic Web Services around the Web Service Modeling Ontology WSMO; WSMO Use Case are gathered in the WSMO Use Case Overview document.

 

References

[de Bruijn, 2004]de Bruijn, J. (ed): D16.0 v0.2 WSMO The WSML Family of Representation Languages ebXML, WMSL Working Draft 26 September 2004, avaliable at: http://www.wsmo.org/2004/d16/v0.2/20040926/.

[ebXML] ebXML, avaliable at: http://www.ebxml.org.

[EDIFACT] UN/EDIFACT, avaliable at: http://www.unece.org/trade/untdid/welcome.htm.

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

[Keller et al., 2004] Keller, U.; Lara;, R.; Polleres, A. (eds.): WSMO Discovery, D5.1 v0.1, WSML Working Draft 13 September 2004. available at http://www.wsmo.org/2004/d5/d5.1/v0.1/20040913/

[Pan and Hobbs] F. Pan and R. Hobbs: Time in OWL-S, avaliable at: http://www.isi.edu/~pan/damltime/AAAIsymp2004.pdf.

[Roman et al., 2004] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology (WSMO), WSMO Working Draft D2, final version 1.0, 20 September 2004, available at http://www.wsmo.org/2004/d2/v1.0/20040920/.

[RosettaNet] RosettaNet, avaliable at: http://www.rosettanet.org.

 

Acknowledgements

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 Vienna city government under the CoOperate programme and by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW˛ and TSC.

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


Appendix A: Change Tracking

To facilitate retracing of changes between different version of this deliverable, the following lists the essentail changes done in comparison to the preceding version.

The change tracking starts with the version of 28 June 2004.

Version: 19 November 2004 http://www.wsmo.org/2004/d3/d3.3/v0.1/20041119/

- changed owl listings to abstract syntax
- corrected references and relations to other WSMO deliverables
Version: 08 October 2004 http://www.wsmo.org/2004/d3/d3.3/v0.1/20041119/
- incorporated requested updates on use case description
- corrected listings to actual WSML synatx
- updated section 4, on discovery
Version: 05 November 2004 http://www.wsmo.org/2004/d3/d3.3/v0.1/20041105/
- re-added the general use case overview in section 2
- reworked the use case overview: tabular overview of the resources modeled in this use case
- corrected the models of all resources:
Version: 08 October 2004 http://www.wsmo.org/2004/d3/d3.3/v0.1/20041008/
- separated VTA Use Case document into seperated documents
Version: 04 October 2004 http://www.wsmo.org/2004/d3/d3.2/b2c/20041004/
- separated documents; this document only includes the concrete B2C - Virtual Travel Agency Use Case
- models / listings updated to valid WSML in accordance to WSMO D2, final version 1-0, 20 September 2004
- updated Web Service discovery part to new WSMO Web Service Discovery as defined in D5.1, 13 September 2004
 
Version: 19 July 2004 http://www.wsmo.org/2004/d3/d3.2/v0.1/20040719/
- ontologies: rationales and updates, PO Ontology currently under development
- added general Goal and GG Mediator; the concrete Goal is derived from these
- updated WS Capability (assumption is now that the cerdit card is valid)
 
Version: 28 June 2004 http://www.wsmo.org/2004/d3/d3.2/v0.1/20040628/
- complete read-thru with corrections of deliverable text (regarding comments from Jos de Bruijn)
- corrections of domain ontologies
   * changed section 3.1.1 to "Use Case Overview", describes the properties of the WSMO components modeled below
   * the web service described now is understood as an aggregated / composed web service that offers the overall
      functionality for purchasing train tickets online. In later versions, the Choreography description as well as the
      Orchestration with specfic Web Services for searching and buying train tickets can be adopted.
   * correected / clarified descriptions for modeling descriptions.
- correction of WSML-models for Goals, Web Services, Mediators
- revised the Web Service Discovery description (section 3.1.3)
- updated the FLORA2 resources to the WSML models (as in Listings)
- namespace handling refined

Appendix B: Related Resources

To ease understanding of the resources modeled within this use case, the section gathers all ontologies (re)used within this use case as well as other related resources.

B.1 Used Ontologies in OWL

The ontologies specified in Section 3.1 use existing ontologies. Most of these ontologies are modelled in OWL. To use them within WSML, the syntax has to be converted to WSML (using an OO Mediator). A mediation Service has not yet been implemented, however a partial mapping is defined in [de Bruijn, 2004].

The following listings provide the ontologies in OWL abstract syntax, since this syntax is more human readable then the RDF/XML syntax. The conversion was done using the OWL API developed by the University of Manchestor. Specific Notes to the conversion can be found below each ontology (if applicable). The Listings are given to illustrate the expressive power used in this OWL ontologies and to allow the reader the comparison of between the wsml and owl ontologies.

Listing B1: Person Ontology

The original ontology in OWL/RDF format is available at: http://daml.umbc.edu/ontologies/ittalks/person

Listing B2: OWL Factbook Ontology

The original ontology in OWL/RDF format is available at: http://www.daml.org/2003/09/factbook/factbook-ont
Note that the original ontology contains several Individual assertions which seemed to be mend as annotation for range fillers, e.g.:

<owl:Restriction>
  <owl:onProperty rdf:resource="#totalArea" />
  <owl:allValuesFrom rdf:resource="http://www.w3.org/2001/XMLSchema#decimal" />
  <factbook:units>sq km</factbook:units>
</owl:Restriction>

However those individuals have semantically no connection to the properties they occur next to within the XML representation. As shown in the abstract syntax they are just individual assertions.

Listing B3: Address Ontology

The original ontology in OWL/RDF format is available at: http://daml.umbc.edu/ontologies/ittalks/address

Listing B4: Currency Ontology, original (in DAML) at: http://www.daml.ecs.soton.ac.uk/ont/currency.daml

 

Listing B5: Geo Ontology

The original ontology in OWL/RDF format is available at: http://www.daml.org/2001/02/geofile/geofile-ont
Note that this ontology is in OWL Full, in order to show it in the more concise abstract syntax and to be able to reason with it using Description Logic Reasoners we converted it to OWL DL by applying the following fixes:

The rdf/xml version of the ontology with those fixes is available at: http://www.wsmo.org/2004/d3/d3.3/v0.1/20041119/resources/owl-ontologies/geofile.owl

Listing B6: OWL - Travel Itinerary Ontology

The original ontology in OWL/RDF format is available at: http://www.daml.org/2001/06/itinerary/itinerary-ont

B.2 Related Ontologies

Within the elaboration of the use case, the RosettaNet's PIP3A4 "PurchaseOrderRequest" has been transformed into a WSMO ontology. As the RosettaNet model is designed for B2B purchase orders, it is not applicable for the B2C setting of the use case demonstrated in this document. However, the Purchase Ontology of this use case as defined in Listing 3, Section 3.1, is based and heavily related to the RosettaNet Purchase Model. The listing below therefore provides the RosettaNet Purchase Model modeled in WSML.

The ontology is an WSML representation of the RosettaNet's PIP3A4 "PurchaseOrderRequest" [RosettaNet]. RosettaNet is a consortium of major Information Technology, Electronic Components, Semiconductor Manufacturing, Telecommunications and Logistics companies working to create and implement industry-wide, open e-business process standards. These standards form a common e-business language, aligning processes between supply chain partners on a global basis.

Every standard business transaction within the RosettaNet trading network is defined in a so called PIP (Partner Interface Process) which defines the XML code, activities, decisions and Partner Role interactions between two partners in the supply chain. Each partner participating in the "Partner Interface Process" must fulfill the obligations specified in a PIP. These PIPs are organized into seven clusters, or groups of core business processes, that represent the backbone of the trading network. Each cluster is broken down into segments which are cross-enterprise processes involving more than one type of trading partner. Within each segment are individual PIPs, whereas the above mentioned PIP3A4 is part of Segment 3A "Quote and Order Entry". This segment allows partners to exchange price and availability information, quotes, purchase orders and order status, and enables partners to send requested orders, or shopping carts, to other partners.

At the current state this domain ontology is preliminary and will be further enhanced in future versions. As far as RosettaNet's PIPs are only intended for the use in the above mentioned industry sectors we also consider and partly work on the ontologizing of other conceptualizations, inter alia ebXML [ebXML] and EDIFACT [EDIFACT].

Listing B5: RosettaNet's PIP3A4 "PurchaseOrderRequest" in WSML


Valid XHTML 1.1!

webmaster