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:

• the customer creates specifies his high level goal of purchasing international train tickets.
• the VTA is one of the Service Providers that is identified as suitable fulfilling his request
• the customer refines his request to an international train ticket valid from Innsbruck to Frankfurt on 17th July 2004, between 6 and 7 p.m. local time
• the VTA returns a set of possible connections
• the user selects one of these connections and poses a request for booking the ticket online
• the VTA combines the online train ticket booking services from ÖBB and DB, executes the booking and payment process, and sends an online ticket per email to the Customer.

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]).

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:
   • the Customer specifies its request in natural language and the request is translated into machine readable form and processed by the VTA service automatically
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:
   • customer notification
   • VTA-Service Provider interaction on accounting and good delivery mandate

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:

• It has to provide a user interface for customer interaction (for both human and machine users)
• It has to discover suitable Web Services for an user request
• It has to invoke and combine external Semantic Web Services
• It has to provide a Web Service Execution Environment with control functions, error handling, and support for optional user interaction
• It has to deal properly with heterogeneous resources, thus allowing for appropriate mediation facilities.
• It has to provide interfaces for cooperation with Service Providers.

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.

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.

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.

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 :

• Purchase: the overall construct that holds all aspects for a purchase where a buyer buys a product from a seller
• Purchase Order: specifies the product, payment, and delivery terms of a purchase
• Purchase Partners: the parties involved in a purchase, i.e. buyer and seller
• Product: information about a product provided by a seller
• Payment: specifies notions of payment within B2C purchasing
• Delivery: specifies delivery methods for delivering a purchased product from the seller to the buyer

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).

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.

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:

• postcondition: A purchase for a buyer with a ticket as the product
• effect: the purchased ticket is delivered to the buyer

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:

• postcondition: A purchase for a train ticket for a train trip from Innsbruck to Frankfurt on July, 17th 2004, departure between 6 and 7 p.m.; Tim Berners-Lee is the buyer as well as the passenger for whom the ticket is valid.
• effect: the ticket shall be delivered to Tim Berners-Lee's shipping address by online delivery via email.

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:

• precondition: the input has to be the information about the buyer, a train trip that a ticket is to be purchased for, and information on the passenger for whom the ticket shall be valid. To be valid input, the following restrictions are defined for the trip: the start and end locations are restricted to stations in Austria or Germany; the departure date for the trip has to be after the current date; and the payment method of the buyer has to be a credit card.
• assumption: the credit card submitted as input has to be valid (not expired).
• postcondition: the service returns a purchase for train tickets valid in Austria and Germany by the ÖBB as the provider, with payment by credit card only.
• effect: the sold ticket is delivered to the buyer shipping address, either by a drop ship carrieror via online delivery.

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

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.

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:

• insights and test case for final specification of the WSMO top level components as defined in WSMO, D2, final version 1.0 [Roman et al., 2004]
• specification and elboration of WSML (syntax, general structure, and logical expressions)
• test case for Web Service Discovery within WSMO.

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:

• International Train Connection Ontology: added concept ticket
• Purchase Ontology: complete revision, made it 'B2C'-adequate
• added related / used ontologies in Appendix B
• updated models of Goals and Web Services to corrected ontologies

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.

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

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.

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

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:

• rdfs:class statements have been transformed to owl:class statements
• rdf:property has been transformed to owl:DatatypeProperty respectively owl:ObjectProperty
• unknown data types have been explicitly declared

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

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].

webmaster