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

WSMO Working Draft 05 November 2004

This version:

http://www.wsmo.org/2004/d3/d3.3/v0.1/200411105/

Latest version:

http://www.wsmo.org/2004/d3/d3.3/

Previous version:

http://www.wsmo.org/2004/d3/d3.3/v0.1/20041008/

 

Editors:

Michael Stollberg

Holger Lausen

Axel Polleres

Rubén Lara

 

Authors:

Michael Stollberg

Holger Lausen

Axel Polleres

Rubén Lara

Uwe Keller

Michal Zaremba

Armin Haller

Dieter Fensel

Michael Kifer

 

Reviewer:

Christoph Bussler

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 puchasing 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.0 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 puchasing such a ticket. We specify the WSMO 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 a goal for an international train connection 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 use case is the first, initial use case specified of testing, elaborating, and recursively specifying the WSMO components. The setting of this use case is kept simple on purpose in order to allow concentration on the main issues of interest; more complex cases to be added at a later stage of this deliverable can build upon this. The main focus of this use case is the test and recursive specfication of the WSMO components specifiaction in [Roman et al., 2004], elaboration of the Web Service Modeling Language WSML [de Bruijn, 2004]], and development and testing of WSMO Web Service Discovery [Keller et. al., 2004].

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 decissions; 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 and. 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. Thus, in the first WSMO use case we will describe a Virtual Travel Agency example that involves automated discovery of Web Services.

2.1 Description

Imagine a “Virtual Traveling Agency”, called VTA for short, which is an end user platform 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, but at this point mostly comprise simple information portals along with some web-based customer services. By applying Semantic Web Services, a VTA will invoke Web Services provided by several eTourism suppliers and aggregate them into new customer services in a (semi-)automatic fashion. Such VTAs providing automated eTourism services to end users thus tremendously enhance the functionality of currently existing VTAs.

Our VTA use case that aggregates Web Services of different tourism service providers in a nutshell shall provide the following functionality. a customer uses the VTA service as the entry point for his requests. These requests must fit to end-user services that the VTA provides. These end-user services are aggregated by the VTA by invoking and combining Web Services offered by several tourism service providers. Therefore, there must be some kind of 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: a 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), has a usage and allowance contract with the VTA
3. VTA: the intermediate between the Customer and the Tourism Service Providers. It provides high-quality 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 an API 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 displays 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
   • several Web Services are aggregated for providing the requestred functionality if it cannot be fulfilled by a single service
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 “instantiated” 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 have to deal properly with heterogeneous resources, thus allowing for appropriate mediation facilities.
• It has to provide interfaces for cooperation with Service Providers.

- Train Connection Ontology - Purchase Ontology - Date and Time Ontology - Location Ontology

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.

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 descisions 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 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, 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 accomodations 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.

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 an concepts for locations, including cities and states, as well as postal addresses. This ontology the DAML ontology for geographical locations, an ontology describing a wide variety of locations and geographical areas. The concept country is extended using the OWL-Factbook ontology. The concept address reuses the DAML address ontology.

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 restricts 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 "connect" ontologies with other ontologies or OO Mediators for refining ontologies, as well as for importing ontologies as the terminology definitions into other WSMO components. As the Goal and the Web Service specified above have homogeneous information spaces, we only have to specify OO Mediators for the existing ontologies used for the domain ontologies defined in this use case. Here, we have to define the following OO Mediators, specified in the Listings below:

1. owlAddressMediator.wsml
2. owlCurrencyMediator.wsml
3. owlFactbookMediator.wsml
4. owlPersonMediator.wsml

Notice that the mediation services are not specified. For importing an OWL ontology into a WSML ontology, it is obvious that such mediation services are required. The terminology to express the capability of mediation services as well as the requester goals is not defined at the moment. This terminology, modeling the ontology mediation domain, has to be included in future versions of the deliverable and the necessary goals and capabilities have to be defined using such terminology.

3.4.2 WG Mediators

A WG Mediator links a Web Service to a Goal, resolves terminological mismatches, and states the functional difference (if any) between both. WG Mediators can be used to pre-link Services to existing Goals, or for handling of partial matches within Web Service discovery. 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), and there is no functional differences between the Goal and the Capability. An WG Mediator would be needed if the Web Service Capability specifies that train tickets as well as plane tickets are sold: Therefore, the mediation service would restrict the valid set of information to train tickets, as requested by the Goal.

3.4.3 GG Mediators

A GG Mediator connects Goals, specifying the possible functionality reduction. For example, a GG Mediator would connect a Goal "buy a ticket" with another Goal "buy a train ticket" by stating the ontological correspondance between the Goals as a reduction. If 'train ticket' is a subclass of 'ticket', than the reduction in the GG Mediator would specify that valid instances for the second Goal have to be 'train ticket subclassof 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. Therefore, the GG Mediator has the following description elements:

• sourcecomponent: this is the generic Goal defined in Listing 6
• targetcomponent: the concrete Goal defined in Listing 7
• usedMeditators: this element is intended to import further terminology definition (Ontologies or OO Mediators) needed for defining the reduction. Here, no additional terminology is needed. Note that the terminology definitions of the source- and target component is inherited into the Mediator - which goes for all types of WSMO Mediators
• mediation Service: a mediation service is not defined, since a framework for GG Mediators in WSMO is not fully elaborated at the time of writing.

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

THIS PART NEEDS TO BE REWORKED, ACCORDING TO WSMO D5.1

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, SEKT, SWWS, Esperonto, and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program.

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: 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 make them usable within WSML, there needs to be a mapping from OWL to WSML, so that existing OWL ontologies can be imported via an OO Mediator. These OO Mediators are provided in Section 3.4.1; but as a formal mapping between OWL and WSML is not existing at this point in time, the mediation service for these OO Mediators can not be defined.

The following listings provide the original ontologies in OWL along with links to the original resource

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

$Date: 2004/10/29 15:53:27 $

webmaster