wsmo logo

Valid XHTML 1.1!

D3.2 v0.1. WSMO Use Case Modeling and Testing

WSMO Working Draft 24 May 2004

This version:
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/
Latest version:
http://www.wsmo.org/2004/d3/d3.2/v0.1/
Previous version:
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/
 
Editors:
Michael Stollberg
Holger Lausen
Axel Polleres
Rubén Lara
 
Authors:
Michael Stollberg
Holger Lausen
Uwe Keller
Rubén Lara
Axel Polleres

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 exemplifies the usage of the Web Service Modeling Ontology WSMO for modeling possible Web Service driven applications. The intent of this document is to exemplify use cases with usage scenarios of Semantic Web Services on the one hand, and on the other to showcase modeling with WSMO as an evaluation with real-world testing as support for recursive development of WSMO. For use case modeling, we stick to the latest final working draft of Web Service Modeling Ontology WSMO, Version 0.2.

 

Related Documents

WSMO Standard: D2 v0.2 Web Service Modeling Ontology (WSMO) , current version at: http://www.wsmo.org/2004/d2/v0.3/

WSMO Primer: D3.1 v01. WSMO Primer

WSMO Reasoning: D5.1 v01. Inferencing Support for Semantic Web Services: Proof Obligations.


Table of contents

1. Introduction
1.1 Semantic Web Services
1.2 The Web Service Modeling Ontology WSMO
2. Use Cases
2.1 B2C - Virtual Travel Agency
   2.1.1 Description
    2.1.2 Scope
    2.1.3 Actors, Roles and Goals
    2..4 Usage Scenarios
    2.1.5 System Architecture
2.2 B2B - Integration with Semantic Web Services
    2.2.1 Description
    2.2.2 Scope
    2.2.3 Actors, Roles and Goals
    2.2.4 Usage Scenarios
    2.2.5 System Architecture
3. WSMO Use Case Modeling
3.1.VTA for International Online Train Ticket
    3.1.1 Requirements Analysis
    3.1.2 WSMO Modeling
      Ontologies
      Goal
      Web Services
      Mediators
    3.1.3 SWS mechanisms based on WSMO models
    3.1.4 Conclusions
3.2 B2B Integration with Semantic Web Services
    3.2.1 Requirements Analysis
    3.2.2 WSMO Modeling
      Ontologies
      Goal
      Web Services
      Mediators
    3.2.3 SWS mechanisms based on WSMO models
    3.2.4 Conclusions
4. Conclusions and Future Work
References
Acknowledgements
 
Appendix A: Flora2-F-logic for the VTA - Use Case
 

1. Introduction

This document exemplifies the usage of the Web Service Modeling Ontology WSMO for describing relevant aspects for Semantic Web Services. Therefore, we describe possible use cases of Semantic Web Services and showcase how these can be modeled with WSMO, especially for support of the Semantic Web Service usage scenarios in particular use cases. We briefly replicate the objectives and the approach of WSMO and outline use cases within possible usage scenarios of Semantic Web Services. Then, we showcase how specific use cases can be modeled in WSMO along with explanations on the modeling decisions. Besides, we provide the WSMO models in a computational format.

This Deliverable is intended to evolve in accordance to the ongoing development of the WSMO project, serving as a testing environment and providing input for a recursive, real world testing development of WSMO. In the longer run, additional use cases will be added in order to widen possible solutions for Semantic Web Service technologies around WSMO.

This document is organized as follows: the remainder of Section 1 replicates the objectives and approach of WSMO; Section 2 discusses possible application areas of Semantic Web Services. Section 3 provides the modeling of the use cases in WSMO, pointing out the WSMO approach for Semantic Web Service technologies. Section 4 concludes the document. The complete WSMO models as computational resources are provided in the Appendices.

The use case modeling in this document relies on the latest final working draft of the Web Service Modeling Ontology WSMO, Version 0.2.

1.1. Semantic Web Services

A Web Service is a piece of software accessible via the Web. Current Web Service technologies allow exchange of messages between Web Services [SOAP], describing the technical interface [WSDL], and advertising a Web Services in a registry [UDDI]. These technologies do not provide any information about the meaning of information used, neither do they explicitly describe the functionality of a services as needed for automated usage of Web Services. Enhanced Web Service technologies aim at more sophisticated techniques to describe Web Services, emphasizing the concept of Semantic Web Services. In our understanding, a Semantic Web Service is defined as a “self-contained, self-describing, semantically marked-up software resources that can be published, discovered, composed and executed across the Web in a task driven automatic way” [Arroyo et al., 2004]. By machine-processable descriptions of the relevant information and by means of automated mechanisms that utilize this information, the following functionalities for Web Services shall be achieved.

1.2 The Web Service Modeling Ontology WSMO

The aim of WSMO and its surrounding efforts is to define a coherent technology for Semantic Web Services (short: SWS). WSMO defines the modeling elements for describing several aspects of Semantic Web Services. The conceptual basis of WSMO is the Web Service Modeling Framework [WSMF], wherein four main components are defined that are needed for a full coverage framework for Semantic Web Services (see Figure 1). The first component is Ontologies which provide the formal semantics of the information used by all other components. The second component is Goals that specify objectives that a client may have when he consults a web service. The third component is Web Services. For supporting automated discovery, composition, and execution of Web Services, descriptions are required on the functionality provided by a Web Service (called “Capability” in WSMO). For supporting automated choreography and execution compensation of Web Services, particular information on the external visible behavior of a Web Service are needed (called “Interface” in WSMO), including information on the technical accessibility and the actual message exchange of Services. The fourth component of WSMO is Mediators, which are used as connectors between particular components and include possibly required mediation facilities needed to make connected components interoperable. WSMO distinguishes different types of Mediators. The components of WSMO along with exhaustive explanations are presented in the WSMO Primer.

WSMO Components
Figure 1. WSMO Components

 

2. Use Cases

Semantic Web Services can be used in manifold application fields. In accordance with the use cases defined in Web Services Architecture Usage Scenarios by the W3C Web Services Architecture Working Group, we discuss two most common use case scenarios to exemplify the usage of SWS technologies:

  1. A "Virtual Traveling Agency" that provides end-user services for e-Tourism by aggregating Web Services of different tourism service providers. This is a “B2C” use case, i.e. wherein a third party provides a service to end users as a Client / Service model as an aggregation of Semantic Web Services.
  2. The second example is concerned with B2B Integration wherein a business entity, e.g. a business document, is exchanged between enterprises. Therein, different aspects of EAI might arise which shall be handled by Semantic Web Services technology.

For describing the use cases, we slightly modify the methodology of the W3C Use Case descriptions and extend by the requirements arising for Semantic Web Services technologies. The following lists the aspects we use for the use case definitions below.

2.1 B2C - Virtual Travel Agency

In Web Services Architecture Usage Scenarios, 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 we restrict the first WSMO use case to a Virtual Travel Agency scenario that supports automated discovery of Web Services.

2.1.1 Description

Imagine a “Virtual Traveling Agency”, called VTA for short, that is an end user platform providing eTourism services to customers. These services can cover all kind 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 as this point of time they mostly are an information portal along with some web-based customer services (e.g. eTourism.at). By applying Semantic Web Services, a VTA will invoke Web Services provided by several eTourism suppliers and aggregate them into new customer services. Such VTAs will provide automated eTourism services to end users, thus tremendously enhancing the functionality of currently existing VTAs.

The overview of the use case for VTAs that aggregate Web Services of different tourism service providers looks like this: a customer uses the VTA as the entry point for his request. This request must fit to an end-user service 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 shows this overview (modified and extended from W3C Travel Agent Use Case overview).

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

2.1.2 Scope

The overview described above can be seen as 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 VTA-services for providing an end-user service for booking complete holiday trips worldwide.

In order to showcase and test the applicability of WSMO and not to get lost in real-world modeling of eTourism use cases, we restrict ourselves to a simple VTA use case from booking international online train tickets. This use case is described in more detail in section 3.1.VTA for International Online Train Ticket

2.1.3 Actors, Roles and Goals

In general use case there are 3 actors. The following defines what they are, why they participate in this use case (goal), and with whom they need to interact in what way (role).

  1. Customer: the end-user that requests a end-user 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 Provider: a commercial company 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 Provider. Provides high-quality tourism services to customers by aggregating the separate services provided by the Service Providers.
      - Goal: provide high-quality end-user tourism services, use existing tourism services and aggregate them 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 human customers or and Interface / 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.1.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 is displayed in 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 suitable Web Services for searching tourism service offers and displays results to Customer
    - Participating Actors: Customer and VTA
    - 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 a "Search" functionality that can be requested by a Customer
       (2) 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 hold 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 and VTA
    - 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 for
       (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 creditcard number for payment)
    - Technological Requirements: contract information is displayed in 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
    - 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.1.5 System Architecture

In this use case, the VTA is the central point of interaction between the Customer and Web Services. Regarding the technological requirements, it gets 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 hold 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 C/S Model. In order to support coherent functionality of the VTA and ensure that the descriptions of Web Services are compatible to this, an overall framework for SWS technologies is needed. This is provided by WSMO. Section 3.1 exemplifies the modeling of the WSMO components for a real world VTA use case in detail.

2.2 B2B - Integration with Semantic Web Services

The second use case is concerned with teh integration of possible heterogeneous resources in B2B settings which is considered as one of the most important application fields of the Web Service technology.

2.2.1 Description

In the B2B use case, two enterprises called E1 and E2 want electronically exchange business documents across the network. It is assumed that partners may not know each other before carrying business transaction and that is why contract negotiation and contract agreement are essential elements of this use case. The contract agreement defines roles of enterprises in the conversation e.g. one of the enterprise E1 becomes the seller and the second enterprise E2 becomes the buyer. Agreement also predefines the order of the message exchange pattern e.g. buyer first sends purchase order (PO) and after that it receives purchase order acknowledgement (POA). Differently than in the previous B2C use case, where the client/server model of interactions has been adopted, the peer-to-peer model is used in this use case - partners are equal and they carry the conversation. Each of the companies has own orchestration and the set of web services, which enables to exchange business documents electronically. Infrastructure provided by SWS takes care for any necessary mediation between web services (links web services), ontologies (resolves possible representation mismatches between ontologies used by these two enterprises), goals (links goals) and web services and goals. SWS infrastructure supports the execution of the contract to fulfill approved agreement.

B2B Integration with Semantic Web Services
Figure 4. B2B Integration with Semantic Web Services

In this use case an ultimate goal of an enterprise E1 is to integrate its own back-end system with the back-end system of an enterprise E2. Once integrated, SWS software enables back-end systems of both companies to interact and to preserve the message, process and protocol semantic. The information systems used by enterprises E1 and E2 are autonomous, heterogonous and distributed. Semantic Web Services address each of these three properties and the software based on SWS enables companies to cooperate.

The back-end systems in E1 and E2 are autonomous since each of them changes its state without informing other system about it. SMS software enables to track state changes of back-end applications to facilitate coordination between systems of E1 and E2.

The back-end systems in E1 and E2 are heterogonous, because each of them has different conceptual model for expressing business semantics. SWS software takes care of appropriate mediation of the representation and meaning of the back-end system to the equivalent representation and meaning of the other system. The SWS software ensures to maintain the same semantics between back-end systems of E1 and E2.

The back-end systems in E1 and E2 are distributed because each of them maintains its own state independently from the other system. Back-end applications in companies E1 and E2 do not share data or state at all. SWS software implemented in both companies takes care of transporting data between the systems.

2.2.2 Scope

The use case assumes peer-to-peer relationships between two business partners carrying conversation about purchasing/selling of goods. The B2B use case focuses on the technical infrastructure based on the SWS technology, which enable any business company to automatically discover web services which are capable to fulfill its goals, compose simple web services into complex web services to achieve a given goal and to automatically execute given services in a particular order. This use case assumes that there may be no prior business relationships between two enterprises before the discovery. Enterprise E1 must find enterprise E2 and they must agree and enforce the contract in their companies. Agreement should define roles of each of them in the agreed business process – e.g. one of them would become a buyer and one of them would become a seller. The agreement can lead to only one time execution of the agreed business process (e.g. request purchase order) or to long time relationships based on the multiply execution of the agreed contract. Payments are sent through financial institutions and at this stage they are out of the scope of this use case. The same situation concerns the shipment of the goods. This use case consider sending documents as for example purchase orders or invoices, but the physical shipment of goods is out of the scope of this use case.

2.2.3 Actors, Roles and Goals

There are two actors in the B2B use case – actors, which represent two business entities. The size and the importance of companies are not predefined in this use case. They might differ in size but from the perspective of this use case it should not matter which one of them is a more dominant partner. Both of the enterprises undertake a predefined role in the use case. These are:

  1. Buyer: the company, which initiates the use case by searching for a partner, which is capable to sell goods.
      - Goal: Finding a business partner, who is capable to provide goods. Signing the contract, discovering capabilities of the seller, composing provided web services and executing them.
      - Role: A business entity, which seeks business partner to achieve given goal by establishing new business relationships. Once the contract is signed it must be executed and as the result of contract execution, the buyer should receive goods. Buyer initiates the process described in this use case.
  2. Seller - seller provides goods. It waits for buyers, responds to their requests, signs the contract and ships goods.
      - Goal: Providing goods. Signing the contract, discovering capabilities of the buyer, composing provided web services and executing them.
      - Role: A business entity, which waits for the partner to establish business relationships. As the result of the execution of the contract, the seller should send goods the seller.

2.2.4 Usage Scenarios

In this use case the following usage scenarios have been identified:

  1. Contract negotiation and implementation of agreement between buyer and seller.
    - Participating actors - buyer and seller
    - Activities - business contract negotiation and implementation
    - Technological Requirements - The technology should enable matching goals of a buyer with capabilities of a seller. But matching goals of capabilities is not sufficient, because once goal is matched with the capability, the interfaces of two businesses should be matched as well.
    - Possible Extensions -contract is negotiated and implemented completely automatically by appropriate infrastructure
  2. Typical business messages exchange (e.g. PO & POA exchange);
    - Participating actors - buyer and seller
    - Activities - buyer sends PO to seller. Buyer can at any time check the status of processed order. Seller sends back POA. Lower level acknowledgments messages for each of the PO and POA can be also exchanged.
    - Technological Requirements - The technology should enable conversation between business partners, which supports different process models to achieve given task e.g. buying a product. For example system of one business partner might require a synchronized confirmation for each business document send out, while the system of the other business partner assumes that once the document is send, it does not have to be confirmed. SWS platform should provide appropriate process mediation mechanism to resolve this issue.
    - Possible Extensions - System of one of the business partner might failed and drop in the middle of conversation (e.g. it receives PO, but never sends a POA). SWS platform, similarly to workflow engines, takes care to recover from deadlock and livelock errors.
  3. SWS infrastructure crashes - once it recovers, it reliable commence its operations
    - Participating actors - buyer and seller
    - Activities - Because of some internal (e.g. lack of power supply for the server) or external (e.g. lack of network connection) failure, the SWS system becomes temporary unavailable. Once it is back online, it commence from the point where the execution has been dropped. None of the messages are lost, none of the processes are executed from the beginning.
    - Technological Requirements - Reliable and event driven architecture.
    - Possible Extensions - SWS infrastructure informs all interested parties that it is back online.
  4. E1 and E2 want to deploy a new integration definition type (described in WSML). The developer responsible for the SWS software writes a new integration type, which is next deployed by SWS infrastructures in both enterprises.
    - Participating actors - buyer and seller
    - Activities - Any new integration type can be compiled and deployed by SWS infrastructure.
    - Technological Requirements - Standard interface which allows carrying conversation between SWS infrastructure and WSML editor. New integration definition types can be saved and retrieved from the system.
    - Possible Extensions - Public interface which enables any external party to provide own definitions.

2.2.5 System Architecture

Web Services Modeling Execution (WSMX) is the infrastructure hosted by each of the enterprises to support services following a peer-to-peer model. WSMX is software implementation of a web service execution environment supporting the development, management and execution of Semantic Web enabled Web Services. WSMX platform does not differentiate between calls coming from the back-end application systems (intra-company information systems) and from the information systems of other enterprises. WSMX can also communicate directly with other WSMX platforms hosted by other enterprises as shown on figure 5.

B2B Integration with Semantic Web Services
Figure 5. B2B Use Case System Architecture

3. WSMO Use Case Modeling

In the following we model the two use cases described above in WSMO in order to explicate the practical usage and the design of WSMO. We apply the following methodology for this:

  1. describing the use case, especially the functionality of the Semantic Web Services handling component of the system
  2. define a list of requirements on what has to be known to the application in order to make SWS applicable
  3. model the use case in WSMO, including all building blocks of WSMO, along with detailed explanations of the modeling and the building blocks of WSMO
  4. all WSMO models as downloadable computational resources for testing of SWS-technologies developed on WSMO.

For step number 3, the models of the respective WSMO components are described in Listings in this document. Therein, the Listings specify the different WSMO components as conceptual models in accordance to the specifications in WSMO Standard, V0.2. These models have to be transformed for usage within a specific technology, with respect to syntax and technological constructs. For step 4, we provide the models as computational resources for download, testing and development in the Appendices. Currently, we support FLORA-2 as a F-Logic reasoner (see FLORA-2 homepage). The models provided for download in the Appendices are runnable as separate FLORA-2-programms.

For modeling of the WSMO components in the Listings in this document we use WSML-U as a human readable syntax, based on the syntax for F-Logic as defined in [Kifer et al., 1995].

3.1 VTA for International Online Train Tickets

According to the general VTA use case described in Section 2.1 B2C - Virtual Travel Agency we define the following use case here:

The course of the use case is the following:
- the customer poses a request for an international train connection from Innsbruck to Frankfurt on 23rd May 2004, at 16.00 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 the online ticket per email to the Customer.

For the aggregated service, the VTA has to determine the itineraries of the international connections, and to split them at the border stations into national itineraries. The VTA has to mediate between the following web services:

The rationale for choosing this use case is that it showcases a possible VTA use case as described above within all the components identified in WSMO. The components are simple, thus this use case allows showing the modeling of WSMO elements without getting lost in complicated definitions of specific elements.

OBB Train Connection Itinerary Service
Figure 6. ÖBB Train Connection Itinerary Service

3.1.1 Functional Requirements

The following lists the requirements analysis for modeling the use case. For each of the components of WSMO, a list of requirements is defined that are needed in order to enable the requested functionality of the VTA for online search and booking of international train tickets, regarding the use case described above.

 

Table 1. Requirements Domain Ontologies
O1

We need ontological information on international train itineraries and on the purchasing process. This information should be kept in separated ontologies, following the design principle of modular ontology design.

O2

An itinerary is described by a Start- and End-Location, date and time of departure and arrival, the station where the border is crossed, and the fare.

O3 There has to be customer that buys a train ticket
O4 An itinerary describes a valid international train connection.
O5 There exists a concept that defines whether a location is located at the border between 2 countries
O6 A ticket is valid for exactly 1 itinerary
O7 A ticket is valid for exactly 1 customer
O8

A location description consists of a Location identifier, a Country identifier, and an indicator that the location has a train station

O9 The purchase ontology has to identify the buyer and seller roles, a product with a price, and valid payment methods
O10 The only valid payment method for online tickets is credit card payment
O11 Information on Date and Time should be defined generally in a separate ontology

 

Table 2. Requirements Goals
G1 Booking a Online Train Ticket
G1.1 From Innsbruck to Frankfurt
G1.2 Start time: 17th May 2004, at 16.00 local time

 

Table 3. Requirements Web Services
W1 Each National Train Operator provides a Web Service that offes an international train connection timetable and national online ticket booking
W2.1 The international train connection timetable takes a start location and an end location and a departure date and returns a set of itineraries
W2.1.1 Exceptions are:
- Service not available
- Start or End Location does not exists
W2.2 The national online ticketing service takes an itinerary with start location and end location in the national country, a credit card number and returns a ticket for this itinerary.
W2.2.1 Exceptions are:
- Service not available
- Credit card not accepted

 

Table 4. Requirements Mediators
M1 There exists a WG Mediator to link Goal G1 to a train connection timetable Web Service.
M2 An OO-Mediator has to integrate the two domain ontologies
M2.2 OO-Mediator: All WSMO components apply the integrated ontology
M3 a WW-Mediator mediates between the national online ticketing services.

 

3.1.2 WSMO Modeling

The following provides the modeling of the use case in WSMO with respect to the requirements determined above. The models are presented in the same structure as in the requirements analysis. As explained above, the Listings below specify conceptual models of the distinct WSMO components which have to be transformed into the technology provided by the tool used for reasoning on the ontologies. The full WSMO models as downloadable computational resources for this use case are provided in Appendix A. The models apply the syntax defined in section 3.

The use case modeling in this document relies on the Web Service Modeling Ontology WSMO, Version 0.3. This version of WSMO does not provide elaborated description elements for all WSMO components, especially for Web Services a sophisticated specification of the WSMO modeling primitives only exists for Web Service Capabilities. As we can only apply such elaborated description structures for use case modeling, we restrict this version of the use case modeling to the WSMO description elements defined.

Ontologies

We define 3 domain ontologies that provide the terminology definitions for the use case. The first ontology "International Train Ticket" describes the domain of train tickets, the second ontology "Date and Time" defines a general model for specifying time and dates and relationships of them, and the third ontology "Purchase" describes generic elements of purchasing a product between a buyer and a seller.

We apply the following conventions in the Listings for ontology specifications (those which are not ontology-specific hold for all other WSMO component specifications as well):

The "International Train Ticket" Ontology defines an itinerary and the surrounding concepts as defined in Listing 1. Additionally, a axiom is defined that checks the validity of the traveling dates (the start date / time has to be in the future and the arrival date / time as to be later than the starting date / time) as well as some instances needed in the further use case modeling. Listing 1 shows the F-Logic specification of the ontology.

Listing 1. Domain Ontology “International Train Ticket”
			
namespace
  default=
    http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/tc.flr#
  dc=http://purl.org/dc/elements/1.1
  wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418/

ontology 
  http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/tc.flr
  non-functional-properties 
    dc:title "International Train Connections Domain Ontology"
    dc:creator "DERI International"
    dc:subject "International, Train Itineraries, Ticket Booking"
    dc:description 
      "International Train Itineraries for Online Ticket Booking"
    dc:publisher "DERI International"
    dc:contributor "Michael Stollberg", "Ruben Lara", "Holger Lausen", "Axel Polleres"
    dc:date "20040419"
    dc:type "domain ontology"
    dc:format "text"
    dc:source tc.flr
    dc:language "English"
    dc:dc-relation 
      http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/dt.flr
    dc:coverage "Europe"
    dc:rights http://www.deri.org/privacy.html
    dc:version "1.3"
	 
comment:: OO Mediator for using the Date and Time Ontology 
use-mediator vta-oom-trainconnection.wsml  

comment: conceptDefinitions

  concept location
    non-functional-properties
      dc:description "General notion of all locations in a country"
      name oftype string
      locatedIn oftype set country
	
  concept station subconceptOf location
	
  concept country subconceptOf location
	
  concept city subconceptOf location
	
  concept village subconceptOf location
		
  comment: "borderToCounty" denotes all adjacent countries 
  concept borderStation subconceptOf station
    non-functional-properties
      dc:description "A train station at the border"
    borderToCounty oftype set country
		
  concept itinerary
    non-functional-properties
      dc:description "An itinerary between two locations"
    startLocation oftype station
    endLocation oftype station
    via oftype set station
    departure oftype dateAndTime
    arrival oftype dateAndTime
	
  concept traveller
    non-functional-properties
      dc:description "A traveller"
    name oftype string
	
  concept ticket subconceptOf product
    non-functional-properties
      dc:description "A ticket that relates an itinerary to a customer"
    itinerary oftype itinerary
    traveller oftype traveller
		
comment: axiomDefinitions
 
  axiom transitivityLocatedIn
    non-functional-properties
      dc:description "locatedIn is a transitive property. This 
        allows to specify only the city for a desired train connection"
    logical-expression
      "X memberOf location[locatedIn hasvalues Z] <-
       X memberOf location[locatedIn hasvalues Y] and 
       Y memberOf location[locatedIn hasvalues Y]."
    end-logical-expression
	
  axiom departureBeforeArrival    
    non-functional-properties
      dc:description "Integrity Constraint: departure has to be before 
        arrival"
    logical-expression
      "<-  forall(I)
       I memberOf itinerary[
       departure hasvalue X2 and  
       arrival hasvalue X3] 
       and after(X2,X3)."
       end-logical-expression
		
comment: instanceDefinitions

  instance germany memberOf country
    name hasvalue "Germany"

  instance austria memberOf country
    name hasvalue "Austria"
	
  instance innsbruck memberOf city
    name hasvalue "Innsbruck"
    locatedIn hasvalues {austria}

  instance boesby memberOf village
    name hasvalue "Boesby"
    locatedIn hasvalues {germany}
	
  instance innsbruckHbf memberOf station
    name hasvalue "Innsbruck Hbf"
    locatedIn hasvalues {innsbruck}

  instance frankfurtHbf memberOf station
    name hasvalue "Frankfurt Hbf"
    locatedIn hasvalues {germany}
	
  instance kufsteinHbf memberOf borderStation
    name hasvalue "Kufstein Hbf"
    locatedIn hasvalues {austria}
    borderToCounty hasvalues {germany}

  instance salzburgHbf memberOf borderStation
    name hasvalue "Salzburg Hbf"
    locatedIn hasvalues {austria}
    borderToCounty hasvalues {germany}

  instance freilassingBf memberOf borderStation
    name hasvalue "Freilassing Bf"
    locatedIn hasvalues {germany}
    borderToCounty hasvalues {austria}

  instance kiefersfeldenBf memberOf borderStation
    name hasvalue "Kiefersfelden Bf"
    locatedIn hasvalues {germany}
    borderToCounty hasvalues {austria}

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. Listing 2 only displays the ontology schema and the algebra for date and time, while the downloadable file contains instances and queries for testing.

The main ontology taken into consideration for developing this representation in F-Logic 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. The ontology defined in Listing 2 uses the Gregorian calendar with the representation based on the definition in http://www.w3.org/TR/xmlschema-2/.

Listing 2. Domain Ontology “Date and Time”
namespace
  default=
   http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/dt.flr#
  dc=http://purl.org/dc/elements/1.1
  wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418/
	
ontology 
  http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/dt.flr
non-functional-properties 
  dc:title "Date and Time Ontology"
  dc:creator "DERI International"
  dc:subject "Date, Time, Date and Time Algebra"
  dc:description "generic representation and alegbra for date 
	  and time"
  dc:publisher "DERI International"
  dc:contributor "Holger Lausen, Axel Polleres, Ruben Lara"
  dc:date "20040524"
  dc:type "domain ontology"
  dc:format "text"
  dc:source 
  http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/dt.flr
  dc:language "English"
  dc:relation 
	  http://www.isi.edu/~pan/damltime/time-entry.owl, 
	  http://daml.umbc.edu/ontologies/cobra/0.4/calendarclock, 
	  http://www.w3.org/TR/xmlschema-2/  
  dc:coverage "general"
  dc:rights http://www.deri.org/privacy.html
  dc:version "1.15"


comment: conceptDefinitions

  concept instant 
    non-functional-properties
      dc:description "An instant represents a particular point 
        in time"

  concept interval
    non-functional-properties
      dc:description "An interval represents a duration between 
        2 points in time"
    start oftype instant
    end oftype instant

  concept date 
    non-functional-properties
      dc:description "class date and its representation according to 
        the Gregorian calendar"
    subconceptOf instant
    dayOfMonth oftype dayOfMonth
    monthOfYear oftype monthOfYear
    year oftype year

  concept dayOfMonth 
    non-functional-properties
      dc:description "day of a month is represented by an integer"
    subconceptOf integer

  concept year 
    non-functional-properties
      dc:description "year is represented by an integer"
    subconceptOf integer

  concept monthOfYear 
    non-functional-properties
      dc:description "monthOfYear is represented by an integer 
        and has additional properties"
    subconceptOf integer
    name oftype string
    daysAfterBeginOfYear oftype integer

  concept time
    hourOfDay oftype hourOfDay
    minuteOfHour oftype minuteOfHour
    secondOfMinute oftype secondOfMinute
	
  concept secondOfMinute 
    non-functional-properties
      dc:description "a secondOfMinute is represented by an integer"
    subconceptOf integer

  concept minuteOfHour 
    non-functional-properties
      dc:description "a minuteOfHour is represented by an integer"
    subconceptOf integer

  concept hourOfDay 
    non-functional-properties
      dc:description "a hourOfDay is represented by an integer"
    subconceptOf integer

  concept dateAndTime 
    non-functional-properties
      dc:description "class date and time and representing together 
        a specific point of time (instant)"
    subconceptOf instant
    date oftype date
    time oftype time

comment: axiom-defintions

  axiom validMonthOfYear
    non-functional-properties
      dc:description "integrity constraint for valid monthOfYear:"
    logical-expression
      "forall (X)
       X memberOf monthOfYear and 
       not (X < 0 or X > 12)."

  axiom validDayOfMonth
    non-functional-properties
      dc:description "integrity constraint for valid dayOfMonths:"
    logical-expression
      "forall(X)
       X memberOf dayOfMonth and 
       not (X < 0 or X > 31)."

  axiom validDate
    non-functional-properties
      dc:description "Integrity Constraints for date"
    logical-expression
      "forall(X)
       X memberOf date and 
       not (invalid(X.dayOfMonth) or 
       invalid(X.monthOfYear) or invalid(X.year))."

  axiom validHourOfDay
    non-functional-properties
      dc:description "integrity constraint for valid time:"
    logical-expression
      "forall(X)
       X memberOf time and 
       not (invalid(X.hourOfDay) or invalid(X.minuteOfHour) or 
       invalid(X.secondOfMinute))."

  axiom validSecondOfMinute
    non-functional-properties
      dc:description "integrity constraint for valid secondOfMinute:"
    logical-expression
      "forall(X)
       X memberOf secondOfMinute and 
       not (X < 0 or X > 59)."

  axiom validMinuteOfHour
    non-functional-properties
      dc:description "integrity constraint for valid minuteOfHour:"
    logical-expression
      "forall(X)
       X memberOf minuteOfHour and 
       not (X < 0 or X > 59)."

  axiom validHourOfDay
    non-functional-properties
      dc:description "integrity constraint for valid hourOfDay:"
    logical-expression
      "forall(X)
       X memberOf hourOfDay and 
       not (X < 0 or X > 23)."

  axiom validDateAndTime
    non-functional-properties
      dc:description "integrity constraint for valid dateAndTimes:"
    logical-expression
      "forall(X)
       X memberOf dateAndTime and 
       not (invalid(X.date) or invalid(X.time))."

  axiom equalityDate
    non-functional-properties
      dc:description "computes equality of a date"
    logical-expression
      "equal(X, Y) <-
       Y memberOf date and X memberOf date and
       X.dayOfMonth = Y.dayOfMonth and
       X.monthOfYear = Y.monthOfYear and
       X.year = Y.year."

  axiom beforeDate
    non-functional-properties
      dc:description "computes if a given date X is before another 
        date Y"
    logical-expression
      "before(X, Y) <-
       Y memberOf date and X memberOf date and
       ((X.dayOfMonth = Y.dayOfMonth and 
       X.monthOfYear = Y.monthOfYear and 
       X.year = Y.year) or
      (X.monthOfYear < Y.monthOfYear and X.year = Y.year) or
      (X.year < Y.year))."

  axiom afterDate
    non-functional-properties
      dc:description "computes if a given date X is after another 
        date Y"
    logical-expression
      "after(X, Y) <-
       Y memberOf date and X memberOf date and
       ((X.dayOfMonth > Y.dayOfMonth and 
       X.monthOfYear = Y.monthOfYear and 
       X.year = Y.year) or
       (X.monthOfYear > Y.monthOfYear and X.year = Y.year) or
       (X.year > Y.year))."

  axiom daysAfterChrist
    non-functional-properties
      dc:description "a simplified helper predicate for 
        calculating the differences between dates"
    logical-expression
      "daysAfterChrist(D, X) <-
       D memberOf date and Z is D.monthOfYear and
       X is (D.dayOfMonth + Z.daysAfterBeginOfYear + (D.year*365))."

  axiom daysBetweenDates
    non-functional-properties
      dc:description "the difference in days between 2 dates"
    logical-expression
      "daysBetween(D1, D2, X) <-
       D1 memberOf date and D2 memberOf date and
       daysAfterChrist(D1, DAC_D1) and
       daysAfterChrist(D2, DAC_D2) and
       X is DAC_D1 - DAC_D2."

  axiom equalityTime
    non-functional-properties
      dc:description "computes if two given times are the same"
    logical-expression
      "equal(X, Y) <-
      X memberOf time and Y memberOf time and
      X.secondOfMinute = Y.secondOfMinute and
      X.minuteOfHour = Y.minuteOfHour and 
      X.hourOfDay = Y.hourOfDay."

  axiom beforeTime
    non-functional-properties
      dc:description "computes if a given time X is before another 
        time Y"
    logical-expression
      "before(X, Y) <-
       X memberOf time and Y memberOf time and
       ((X.secondOfMinute < Y.secondOfMinute and 
       X.minuteOfHour = Y.minuteOfHour and 
       X.hourOfDay = Y.hourOfDay) or
       (X.minuteOfHour < Y.minuteOfHour and 
       X.hourOfDay = Y.hourOfDay) or
       (X.hourOfDay < Y.hourOfDay))."

  axiom afterTime
    non-functional-properties
      dc:description "computes if a given time X is after another 
        time Y"
    logical-expression
      "after(X, Y) <-
       X memberOf time and Y memberOf time and
       ((X.secondOfMinute > Y.secondOfMinute and 
       X.minuteOfhour = Y.minuteOfhour and 
       X.hourOfDay = Y.hourOfDay) or
       (X.minuteOfhour > Y.minuteOfhour and 
       X.hourOfDay = Y.hourOfDay) or
       (X.hourOfDay > Y.hourOfDay))."

  axiom secondsFromMidnight
    non-functional-properties
      dc:description "computes the amount of seconds from midnight 
	(helper predicate for calculating difference)"
    logical-expression
      "secondsFromMidnight(T, X) <-
       T memberOf time and
       X is T.secondOfMinute + (T.minuteOfHour*60) + 
       (T.hourOfDay*60*60)."

  axiom secondsBetweenTimes
    non-functional-properties
      dc:description "the difference in seconds between 2 times"
    logical-expression
      "secondsBetween(T1, T2, X) <-
       T1 memberOf time and T2 memberOf time and
       secondsFromMidnight(T1, SFM_T1) and
       secondsFromMidnight(T2, SFM_T2) and
       X is SFM_T1 - SFM_T2."

  axiom equalityDateAndTime
    non-functional-properties
      dc:description "computes if Date and Time are equal"
    logical-expression
      "equal(X, Y) <-
       X memberOf dateAndTime and Y memberOf dateAndTime and
       equal(X.date, Y.date) and
       equal(X.time, Y.time)."

  axiom beforeDateAndTime
    non-functional-properties
      dc:description "computes if a given date and time X is before 
        another date and time Y"
    logical-expression
      "before(X, Y) <-
       X memberOf dateAndTime and Y memberOf dateAndTime and
       ((equal(X.date, Y.date) and before(X.time, Y.time)) or
       before(X.date, Y.date))."

  axiom afterDateAndTime
    non-functional-properties
      dc:description "computes if a given date and time X is after 
        another date and time Y"
    logical-expression
      "after(X, Y) <-
       X memberOf dateAndTime and Y memberOf dateAndTime and
       ((equal(X.date, Y.date) and after(X.time, Y.time)) or
       after(X.date, Y.date))."

  axiom secondsBetweenDateAndTime
    non-functional-properties
      dc:description "computes the difference in seconds between 
        two different DateAndTime"
    logical-expression
      "secondsBetween(D1, D2, X) <-
       D1 memberOf dateAndTime and D2 memberOf dateAndTime and
       daysAfterChrist(D1.date, DAC_D1) and
       daysAfterChrist(D2.date, DAC_D2) and
       secondsFromMidnight(D1.time, SFM_T1) and
       secondsFromMidnight(D2.time, SFM_T2) and
       X is SFM_T1 + DAC_D1 * 24 * 60 * 60 -
       (SFM_T2 + DAC_D2 * 24 * 60 * 60)."

  axiom daysBetweenDateAndTime
    non-functional-properties
      dc:description "the difference in (decimal) days between 
        two different DateAndTime"
    logical-expression
      "daysBetween(D1, D2, X) <-
       D1 memberOf dateAndTime and D2 memberOf dateAndTime and
       secondsBetween(D1, D2, Z) and
       X is Z/60/60/24."

  axiom intervalContainment
    non-functional-properties
      dc:description "computes if a interval X contains a 
        second interval Y"
    logical-expression
      "contains(X, Y) <-
       X memberOf interval and Y memberOf interval and
       (before(X.start, Y.start) or equal(X.start, Y.start)) and
       (after(X.end, Y.end) or equal(X.end, Y.end))."

  axiom instantContainment
    non-functional-properties
      dc:description "computes if a interval X contains a instant Y"
    logical-expression
      "contains(X, Y) <-
       X memberOf interval and Y memberOf instant and
       (before(X.start, Y) or equal(X.start, Y)) and
       (after(X.end, Y) or equal(X.end, Y))."

comment: instance-definitions

  comment: concrete month are defined as instances 
	   will be changed to axioms (3 valued predicates)!
  instance 1 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 31
    name hasValue "January"

  instance 2 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 59
    name hasValue "February"

  instance 3 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 90
    name hasValue "March"

  instance 4 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 120
    name hasValue "April"

  instance 5 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 151
    name hasValue "May"

  instance 6 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 181
    name hasValue "June"

  instance 7 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 212
    name hasValue "July"

  instance 8 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 243
    name hasValue "August"

  instance 9 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 273
    name hasValue "September"

  instance 10 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 304
    name hasValue "October"

  instance 11 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 334
    name hasValue "November"

  instance 12 
    memberOf monthOfYear
    daysAfterBeginOfYear hasValue 365
    name hasValue "December"


The "Purchase" ontology defines general concepts for purchasing a product (there is a buyer, a seller, a product with a price, a payment method, and delivery).

Listing 3. Domain Ontology “Purchase”
namespace
  default=
   http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/po.flr#
  dc=http://purl.org/dc/elements/1.1
  wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418/

ontology 
  http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/po.flr
  non-functional-properties 
    dc:title "Purchase Domain Ontology"
    dc:creator "DERI International"
    dc:subject "Buyer, Seller, Product, Price, Payment method, 
      Delivery"
    dc:description "General purchase ontology"
    dc:publisher "DERI International"
    dc:contributor "Michael Stollberg, Axel Polleres, Rubén Lara, 
      Holger Lausen"
    dc:date "20040524"
    dc:type "domain ontology"
    dc:format "text"
    dc:source 
      http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/po.flr
    dc:language "English"
    dc:dc-relation 
      http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/dt.flr
    dc:coverage "General"
    dc:rights http://www.deri.org/privacy.html
    dc:version "1.7"

comment: OO Mediator for using the Date and Time Ontology 
use-mediator vta-oom-purchaseorder.wsml  

comment: conceptDefinitions

  concept address
    non-functional-properties
      dc:description "Generic address"
    name oftype string
    street oftype string
    number oftype integer
    zipcode oftype string
    city oftype city
    state oftype state
    country oftype country
		
  concept country
    non-functional-properties
      dc:description "Generic country"
    name oftype string
		
  concept location
    non-functional-properties
      dc:description "A location in a country"
    name oftype string
    country oftype country
		
  concept state
    non-functional-properties
      dc:description "A state of a country"
    name oftype string
    partOfCountry oftype country
		
  concept buyer
    non-functional-properties
      dc:description "Buyer of some items"
    shipTo oftype address
    billTo oftype address
    purchaseIntention oftype set tradeItem
    hasPayment oftype set paymentMethod  
		
  concept seller
    non-functional-properties
      dc:description "Seller of some items"
    address oftype address
    saleIntention oftype set tradeItem
		
  comment: Note that the item price given by the 
    buyer denotes a price limit
  concept tradeItem
    non-functional-properties
      dc:description "A trade item"
    product oftype product
    price oftype price
	
  concept product
    non-functional-properties
      dc:description "Generic product"
    name oftype string
		
  concept price
    non-functional-properties
      dc:description "Generic price"
    amount oftype real
    currency oftype string

  concept paymentMethod
    non-functional-properties
      dc:description "Payment method for a trade"
    name oftype string

  concept trade
    non-functional-properties
      dc:description "A trade is an actual agreement on 
        trading items between two trading partners"
    items oftype set tradeItem
    buyer oftype buyer
    seller oftype seller
    payment oftype paymentMethod
		
  concept delivery
    non-functional-properties
      dc:description "Delivery of a good as an effect of a purchase"
    products oftype set product
    receiver oftype buyer
    sender oftype seller
	
  concept creditCard
    non-functional-properties
      dc:description "A credit card"
    name oftype string
    member oftype string
    expMonth oftype month
    expYear oftype year
    type oftype string
    subconceptOf paymentMethod

  concept cash
    non-functional-properties
      dc:description "Cash payment method"
    currency oftype currency
    subconceptOf paymentMethod
		
  concept currency
		
comment: axiomDefinitions

  axiom itemsOffered
    non-functional-properties
      dc:description "Integrity Constraint: a trade is only valid 
        if the items of the trade are offered by the seller"
    logical-expression
      "<- forall(T)
       T memberOf trade[
       items hasvalues I and
       seller hasvalue S]
       and S[
       saleIntention hasvalues I]."
    end-logical-expression

  axiom priceInLimit
    non-functional-properties
      dc:description "Integrity Constraint: The price of the items in 
        the trade has to be lower or equal to the price limit given 
        by the buyer"
    logical-expression
      "<- forall(T)
       T memberOf trade[
       items hasvalues I and
       buyer hasvalue B]
       and B[
       purchaseIntention hasvalues PI]
       and I[
       product hasvalue P1 and
       price hasvalue Price1]
       and PI[
       product hasvalue P2 and
       price hasvalue Price2]
       and P1=P2
       and P1[
       currency hasvalue C1 and
       amount hasvalue A1]
       and P2[
       currency hasvalue C2 and
       amount hasvalue A2]
       and C1=C2
       and A1 <= A2."
     end-logical-expression
		
  axiom deliveryPossibleReceiver
    non-functional-properties
      dc:description "Integrity Constraint: Products can be 
        delivered if the receiver requires them"
    logical-expression
      "<- forall (D)
       D memberOf delivery[
       products hasvalues P and
       receiver hasvalue R]
       and R[
       purchaseIntention hasvalues P]
    end-logical-expression

  axiom deliveryPossible
    non-functional-properties
      dc:description "Integrity Constraint: Products can be 
        delivered if the provider provides them"
    logical-expression
      "<- forall (D)
       D memberOf delivery[
       products hasvalues P and
       sender hasvalue S]
       and S[
       saleIntention hasvalues P]
     end-logical-expression
		
comment: instanceDefinitions

  comment:some sample instances for currencies

  instance euro memberOf curency
  
  instance usd memberOf curency
  
  instance gbp memberOf curency

Goals

Goals denote what a user wants to receive when using a Web Service. More precisely, a Goal describes constraints of an object that the user desires. A Goal is modeled as a fact, i.e. it specifies the ontological structure of the object of desire without variables. Goals in WSMO are understood as "instantiated Goals", i.e. a concrete desire to be resolved. For WSMO-based applications, separation of Goal Schemas and Goal Instances seems to be an appropriate solution for handling of Goals. The former shall describe the general structure of a Goal, while a Goal Instances instantiate a Goal Schema by specifying certain attributes for the which is instantiated by a user for expressing a certain desire. Goal Schemas can also be thought of as pre-defined Goals, while Goal Instances are concrete requests for Web Services during runtime.

In the use case, we have one Goal: a user wants to buy a ticket online for a train connection from Innsbruck to Frankfurt on a certain date. The Goal Template states that the desire is to get a train ticket for an itinerary and for a customer, according to the knowledge defined in the ontologies. The Goal Instance specifies concrete values for the template structure. Listing 4 shows this Goal with the following elements:

Listing 4: Goal - buying a train ticket online
Goal 
	 buying online train ticket

non-functional Properties 
	title 
		buying online train ticket
	creator
		DERI International
	subject
		Train Tickets, Online Ticket Booking
	description
		a desire for booking an international train ticket online
	publisher
		DERI International
	contributor
		Michael Stollberg, Rubén Lara, Holger Lausen, Axel Polleres
	date
		20040517
	type
		WSMO Goal
	format
		 text
	identifier
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/resources/goal.flr
	source
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/resources/goal.flr
	language
		English
	relation
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/resources/tc.flr
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040419/resources/dt.flr
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040419/resources/po.flr
	coverage
		Europe
	rights
		DERI
	version
	 1.14

	 
usedMediators
	// OO Mediator for using the ontologies 
	VTA-OOM-Goal1.wsml
 

// define an instance of Goal

mygoal ofclass goal.

// Goal Postcondition: 
// a ticket for an itinerary from Innsbruck to Frankfurt

mygoal[postcondition  ofvalue 
	myTicket ofclass ticket[
		itinerary  ofvalue  someItinerary ofclass itinerary[
			startLocation  ofvalue  innsbruckHbf
			endLocation  ofvalue  frankfurtHbf
			departure  ofvalue  someDateandtime ofclass dateAndTime[
				date  ofvalue  exists date ofclass date[
					dayOfMonth  ofvalue  17
					monthOfYear  ofvalue  5
					year  ofvalue  2004
				],
				time ofvalue someTime ofclass time[
			hourOfDay ofvalue 18]
			]
		],
		traveller  ofvalue someTraveller ofclass traveller[
		name  ofvalue  'Dieter Fensel'
	]
	]
].

// Goal Effect: a trade for the ticket, payed by creditcard

mygoal[effect  ofvalue 
	mytrade ofclass trade[
		items  ofvalues  myTicket,
		buyer  ofvalue  exists buyer ofclass buyer[
			shipTo  ofvalue  myAddress
			billTo  ofvalue  myAddress
		],
		payment  ofvalue  myCreditCard ofclass creditCard[
			name  ofvalue  'Dieter Fensel'
			number  ofvalue  1234567890
			expMonth  ofvalue  9
			expYear  ofvalue  2006
			type  ofvalue  'MasterCard'
		]
	], 
	myAddress ofclass address[
		name  ofvalue  'Dieter Fensel'
		street  ofvalue  'Technikerstrasse'
		number  ofvalue  13
		zipcode  ofvalue  6020
		city  ofvalue  innsbruck
		state  ofvalue  tirol
		country  ofvalue  austria
	]
].

 

Web Services

For our use case we define one Web Service: an (imaginary) online train ticket booking services for international train itineraries, offered by the Austrian national train operator ÖBB. Of course, this Web Service can be split up into several Web Services wherefore technologies for composition and Orchestration would be needed. But as a our intention within the current version of this use case modeling is to test and showcase the basic modeling of Web Services, we restrict ourselves to only one Web Services at this point in time.

As the referenced version of WSMO does only provide specifications for the description elements for Web Service Capability modeling, we restrict the Web Services models to the Capabilities at this point in time. A Web Service Capability in WSMO is described by pre- and postconditions, assumptions and effects. The primary information for suitability of a Web Service for satisfying a given Goal is the postcondition (the Web Service postcondition has to logically satisfy the Goal postcondition, which is the core of the discovery mechanisms). The other description elements are secondary information for determining suitability, i.e. filtering the set of Web Services that potentially match the Goal. More detailed discussion of the Discovery mechanism of WSMO Goals and Capabilities is provided in section 3.1.3.

Listing 5 shows the Capability specification for the Web Service, including the following WSMO description elements for Web Service Capabilities. Each notion is modeled as a rule that says when there is an instance that fulfills its body than the specific notion is satisfied:

Listing 5: Capability of ÖBB Web Service for Booking Online Train Tickets for Austria and Germany
Web Service Capability
	 selling online train tickets for Austria and Germany

non-functional Properties 
	title 
	 selling online train tickets for Austria and Germany
	creator
		DERI International
	subject
		Train Tickets, Online Ticket Booking
	description
		a Web Service Capability for selling international train tickets online
	publisher
		DERI International
	contributor
		Michael Stollberg, Rubén Lara, Holger Lausen, Axel Polleres 
	date
		20040517
	type
		WSMO Web Service Capability
	format
		text
	identifier
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/resources/capability.flr
	source
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/resources/capability.flr
	language
	 English
	relation
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/resources/tc.flr
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040419/resources/dt.flr
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040419/resources/po.flr
	coverage
		Europe
	rights
		DERI
	version
	 1.3

	 
usedMediators
	// OO Mediator for using the Date and Time Ontology 
	VTA-OOM-WS1Cap.wsml 


// define an instance of Web Service Capability 

oebbCap ofclass capability.

Precondition
// the input has to be an itinerary wherefore 
// the start- and endlocation have to be in Austria or in Germany and 
// the departure date has to be later than the current Date   

oebbCap[precondition] :-
	X ofclass itinerary[
		startLocation ofvalue StartLoc
		endLocation ofvalue EndLoc
		departure ofvalue Departure
	] and
	(StartLoc.locatedIn = austria or StartLoc.locatedIn = germany) and
	(EndLoc.locatedIn = austria or EndLoc.locatedIn = germany) and
	after(Departure,currentDate).

Assumption
// there needs to be a buyer that accepts payment by cerditcard 
// and this creditcard has to be valid (not expired). 

oebbCap[assumption] :-
	X ofclass buyer[
			acceptsPayment =>> Payment
	 ] and
	 Payment ofclass creditCard and
	 (currentDate.date.year < Payment.expYear) or 
	 ((currentDate.date.year = Payment.expYear) and 
	 ((currentDate.date.monthOfyear < Payment.expMonth) or (currentDate.date.monthOfyear = Payment.expMonth))). 

Postcondition
// the output of the service is a ticket (train ticket)for an itinerary wherefore 
// the start- and endlocation have to be in Austria or in Germany and 
// the departure date has to be later than the current Date    

oebbCap[postcondition] :-
	X ofclass ticket[
		itinerary ofvalue_Itinerary ofclass itinerary[
			startLocation ofvalue StartLoc
			endLocation ofvalue EndLoc
			departure ofvalue Departure
		]
	] and
	(StartLoc.locatedIn = austria or StartLoc.locatedIn = germany) and
	(EndLoc.locatedIn = austria or EndLoc.locatedIn = germany) and
	after(Departure,currentDate).
 
Effect
// there shall be a trade for the train ticket of the postcondition    

oebbCap[effect] :-
	Y ofclass trade[
			 items ofvalues Ticket ofclass ticket[
				 itinerary ofvalue_Itinerary ofclass itinerary[
				 startLocation ofvalue StartLoc
				 endLocation ofvalue EndLoc
				]
			] and
			payment ofvalue Payment
	 ] and
	 Payment ofclass creditCard and
	 (StartLoc.locatedIn = austria or StartLoc.locatedIn = germany) and
	 (EndLoc.locatedIn = austria or EndLoc.locatedIn = germany). 
	

 

Mediators

Regarding the requirement analysis for our use case, we have identified the need the following types of Mediators:

In the following we model the concrete mediators needed for the use case. These Mediators are applied by the different components described before using the “usedMediators” modeling element.

OO-Mediators

OO Mediators "connect" the ontology/ies with the component that is using it. According to the WSMF/O-principle of strong de-coupling, all issues related to integrate and mediate (meaning to resolve heterogeneities) the ontologies to be used are located in the OO Mediator. The user who uses a OO Mediator with the "usedMeditaors"-tag should therefore not care about which ontology he refers to - he just gets his "Information Space" by the OO Mediator and uses it.

In order to import the ontologies into all our components, we need three OO Mediators:

  1. importing the Date and Time Ontology into the Train Connection Ontology
  2. importing all ontologies in to the Goal
  3. importing all ontologies in to the Web Service Description, here the Capability

Listings 6-8 specify these three OO Mediators. The general structure of an OO Mediator is that the sourceComponent is the imported ontologies (can also be other OO Mediators), and the targetComponent is the user of the imported ontologies. The internal structure and functionality of a OO Mediator is not stable specified yet, thus we only specify the connection facility in the Listings.

Listing 6: OO-Mediator 1
OO Mediator 
	 Train Connection Ontology uses Date and Time Ontology 

non-functional Properties 
	title 
	 Train Connection Ontology uses Date and Time Ontology 
	creator
		DERI International
	subject 
	description
		importing the Date and Time Ontology into the Train Connection Ontology
	publisher
		DERI International
	contributor
		Michael Stollberg
	date
		20040430
	type
		WSMO OO Mediator
	format
		 text
	identifier
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/VTA-OOM-trainConnection.wsml
	source
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/VTA-OOM-trainConnection.wsml
	language
		English
	relation
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/resources/tc.flr
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040419/resources/dt.flr
	coverage
	rights
		DERI
	version
	 1.1

sourceComponent
		// identifier of "Date an Time Ontology" 
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/dt.flr 
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/po.flr 

targetComponent 
		// identifier of the "Train Connection Ontology" 
		 http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/tc.flr 

mediationService
		// not needed here    

 

Listing 7: OO-Mediator 2
OO Mediator 
	 OO Mediator for Goal 

non-functional Properties 
	title 
	 OO Mediator for Goal
	creator
		DERI International
	subject 
	description
		importing all ontologies in to the Goal
	publisher
		DERI International
	contributor
		Michael Stollberg
	date
		20040430
	type
		WSMO OO Mediator
	format
		 text
	identifier
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/VTA-OOM-Goal1.wsml
	source
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/VTA-OOM-Goal1.wsml
	language
		English
	relation
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/resources/tc.flr
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040419/resources/po.flr
	coverage
	rights
		DERI
	version
	 1.1

sourceComponent
		// identifiers of "Train Connection Ontology" and "Purchase Ontology" 
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/tc.flr 
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/po.flr 

targetComponent 
		// identifier of the Goal
		 http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/goal.flr 

mediationService
		// not needed here

 

Listing 8: OO-Mediator 3
OO Mediator 
	 OO Mediator for Web Service Capability 

non-functional Properties 
	title 
	 OO Mediator for Web Service Capability 
	creator
		DERI International
	subject 
	description
		importing all ontologies in to the Web Service Capability 
	publisher
		DERI International
	contributor
		Michael Stollberg
	date
		20040430
	type
		WSMO OO Mediator
	format
		 text
	identifier
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/VTA-OOM-WS1Cap.wsml
	source
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/VTA-OOM-WS1Cap.wsml
	language
		English
	relation
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/resources/tc.flr
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040419/resources/po.flr
	coverage
	rights
		DERI
	version
	 1.1

sourceComponent
		comment: identifiers of "Train Connection Ontology" and "Purchase Ontology" 
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/tc.flr 
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/po.flr 

targetComponent 
		comment: identifier of the Web Service Capability 
		 http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/capability.flr 

mediationService
		comment: not needed here

WG-Mediators
A WG Mediator denotes the differences between a Goal and a Web Service Capability in order to make them matching by restricting the range of valid information to be exchanged between the Goal Owner and the Web Service. The difference is stated in a reduction. In fact, the reduction defines the intersection between the information space of the Goal and the information space of Capability. Thereby, only such information will be interchanged between the Goal and the Web Service that are valid, meaning that with all outputs, postconditions, and effects of the Web Service the Goal is satisfiable.

In our use case, we only need 1 WG Mediator for connecting the Goal and the Web Service, specified in Listing 9. The WG Mediator, as all other WSMO components, has to be aware of the ontologies used in the components to be connected. As the source component is the Goal, and the target component is the Web Service with the Capability, the the OO Mediators defined for the Goal and for the Web Service inplicitely. The "usedMediators" tag specifies usage of additional ontologies that are needed for specifying the reduction. The Reduction in the WG Mediator restricts the set of values for the Goal and the Web Service to those for which the usage of the Web Service is valid for satisfying the Goal. More precisely, the Reduction is the intersection of valid knowledge items of the Goal and of valid items of the Web Service.

Listing 9: WG-Mediator between Goal and Web Service
WG Mediator 
	 WG Mediator 

non-functional Properties 
	title 
	 Web Service - Goal connection Capability uses all ontologies
	creator
		DERI International
	subject 
	description
	 connecting the Goal and the Web Service Capability 
	publisher
		DERI International
	contributor
		Michael Stollberg
	date
		20040430
	type
		WSMO OO Mediator
	format
		 text
	identifier
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/VTA-WGM1.wsml
	source
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/VTA-WGM1.wsml
	language
		English
	relation
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040517/resources/capability.flr
		http://www.wsmo.org/2004/d3/d3.2/v0.1/20040419/resources/goal.flr
	coverage
	rights
		DERI
	version
	 1.1

usedMediators
		// no additional Mediators needed

sourceComponent
		// identifier of the Goal 
		http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/goal.flr 

targetComponent 
		// identifier of the Web Service
		 http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/ws.flr 

reduction
		comment: to be specified

GG-Mediators
A GG Mediator connects Goals by specifying a reduction between them. 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'.

There is no GG Mediator needed in the use case.

WW-Mediators
A WW Mediator connects Web Services used by another Web Service in ther Orchestration, resolving heterogeneities at all levels (data, process, protocol). There is no WW Mediator in this use case, since the Web Service does not apply other Web Services in order to realize its functionality (at least this is not modelled at the moment). .

3.1.3 SWS Mechanisms based on WSMO component models

On basis of the models for the WSMO components specified above, we can define the following automated mechanisms: Web Service Discovery, Web Service Composition, and Web Service Execution. In the following we explain how these mechanisms work and which parts of the WSMO models they use.

Web Service Discovery

Web Service Discovery is concerned with inference-based mechanisms that detect suitable Web Service for a given Goal. This means that the discovery mechanism searches available Web Service descriptions and determines whether these can be used to fulfill a certain Goal. The overall structure of WSMO supports Web Service discovery explicitly by introducing the notions of Goals and Web Services as top level building blocks. The requirements and the approach for Web Service Discovery in WSMO is exhaustively discussed in [Keller et al., 2004]. Here, we shortly summarize the most important aspects and explain how the discovery mechanism works in the use case models as specified above.

The functionality of the discovery mechanism can be separated into three major aspects:

  1. The Core: Goal-Capability-Matching
    Goal-Capability matching determines whether the Capability of a Web Service Description can satisfy the given Goal, i.e. if the Web Service can be used for solving the Goal. Therefore, it basically has to be proven that the Capability logically entails the Goal with the premise that the conditions for successful usage of the Web Service are fulfilled at invocation time.
    Goal-Capability-Matching is considered as the heart of Web Service Discovery, as it determines whether some Web Service can satisfy the Goal at all. Upon this, different "Discoverers" can be build that modify the discovery results with regard to specific requirements for the application. We discuss this in more detail below.
  2. Heuristics for establishing Goal-Capability Matching
    Goal-Capability matching is only successful, i.e. it returns a set of suitable Web Services to solve a given Goal, if the Goal and the Web Service Capability match perfectly. This means that for all states where the postconditions and effects of the Web Service are fulfilled the Goal is satisfied. This might not hold for many cases, as there might be semantic differences between the Goal and the Capability; but a Web Service might be usable for solving Goal when the valid set of outputs (as well as the set of halting states) of the Web Service is restricted – also vice versa, i.e. the Web Service can be used to solve a Goal within certain restrictions on the Goal.
    In WSMO, these differences are explicitly stated in a WG Mediator. This restricts the valid values between a Goal and a Web Service Capability, thereby ensures Goal-Capability-Matching between Goals and Capabilities that only match partly, and thus broadens the set of possible usable Web Services for solving a Goal. For determining the required reduction in a WG-Mediator, specific heuristics can be applied.
  3. Filter mechanisms for improving discovery results
    The Discovery mechanism in general returns a set of suitable Web Services for solving a Goal. In order to improve the quality of the results set, additional filter mechanism can be applied. These can be based on the non-functional properties of Web Services, or can take some preferences of the customer into account.

With regard to the WSMO models of the use case defined above, we can now show how the heart of Web Service Discovery in WSMO, i.e. the Goal-Capability-Matching works. Therefore, we have to show that the Proof Obligation for Goal-Capability-Matching holds for the models of the Goal and the Capability defined in the use case.

The Proof Obligation for Goal-Capability-Matching is defined as follows

B2B Integration with Semantic Web Services

This Proof Obligation states that under consideration of all Ontologies and Mediators used in the Goal and the Capability description (2nd line), if the user is able to provide concrete values for the input parameters of a service such that the Preconditions and Assumptions defined in the Capability (3rd line) are satisfied, and if the Capability postconditions imply the Goal postconditions and the Capability effects imply the Goal effects, that the Capability matches the Goal. In the use case, we have defined 1 Goal and 1 Capability (see Listing 5). Obviously, the Proof Obligation is fulfilled in this case because the Goal and Capability are homogenenous.

The realization of the Goal-Capability-Matching works as follows - all compuational resources for this are provided in Appendix A:

The idea for general Goal-Capability-Matching, based on the construction of Goals and Capabilities, is that there is a query that asks whether the Capability is fulfilled. This means there has to be fact that satisfies the body of the distinct description elements of the Capability. In the use case, this fact is the Goal. Considering the Goal as specfied in Listing 4, the Goal postcondition is fact that satisfies the body of the Capability postcondition in Listing 5: the Goal Postcondition is a ticket for a specific itinerary (from Innsbruck to Frankfurt with a certain departure), and the body of the Capability postcondition requires a ticket for an itinerary with start- and endlocation in Austria or Germany, respectively, and with a departure that has to be later than the current date (which is explicitely modeled in the Date and Time Ontology). The same holds for the Goal Effect in correlation to the Capability Effect. Therein, the domain knowledge specified in the ontologies is applied by the reasoner in order to determine the matching; for instance, the Goal specifies "innsbruckHbf" as the start location - and instance defined in the Train Connection Ontology, and the Capability postcondition states that the start location of the itinerary has to be located in Austria or Germany. The instance "innsbruckHbF" is located in "innsbruck", and "innsbruck" is located in Austria - so "innsbruckHbf" satisfies the condition of the Capability postcondition. Thus, the following query returns "oebbCap" as a Capability that can satisfy the Goal:

?- X:capability[postcondition] and X:capability[effect].

This structure of Goal and Capability description also supports detection of "overspecified" Capabilities for resolving a Goal. Imagine a Capability with a postcondition that contains a planeticket from A to B, and a train ticket within Austria and Germany. Here, also the Goal would satisfy the Capability postcondition; in order to ensure that only train tickets are booked, the reduction in the WG Mediator that connects this "overspecified" Web Service to the Goal restricts the set of valid information to train tickets only (see an example for this in Appendix A as well).

Observant readers will notice that the realization for Goal-Capability-Matching depicted here does only consider the Capability Postcondition and the Capability Effect with respect to all used Ontologies and Mediators for Goal-Capability-Matching - in contrast to the general Proof Obligation introduced above. The reason for this is both on a conceptual level and on the modeling realization. The underlying understanding of a Goal is that it describes a desire "I want this" without any respect to how this desire could be solved. This desire is modeled as a specific ontology structure - the Goal model it says that the desire is a "ticket for a specifc itinerary", and that there also should be a trade for this ticket. The Goal does not state anyting about the input that will be provided to a suiatble Web Service, neither the Goal does specify any functional capabilities that might be needed for interacting with a Web Service. On the other Hand, the underlying understanding of the Web Service Capability is that this is a functional description of the Web Service, i.e. it describes what the Web Service does. In general, the information provided in the Web Service Capability are "If an input is provided for which certain conditions hold, then the Web Service will return some result in relation to the input wherefore also some conditions hold". With regard to this, the Capability description elements are conceptualy separated into two groups: elements that define conditions that have to hold before the Web Service is executed, and elements that describe conditions that hold after the Service is executed. The former group consists of the precondition (describes the requested input along with conditions on it) and the assumptions (arbitrary state of the world that has to hold before the Web Service can be executed), and the latter group is the postcondition (describes the output of the service after execution along with conditions on it) and the effect (arbitrary state of the world that holds after the execution of the Web Service, i.e. changes in the world).
With respect to this underlying understanding of the WSMO description elements it is obvious that for Goal-Capability-Matching only the 2nd group of Capability description elements has to be considered , i.e. Capability postcondition and Capability effect.The reason is that these information state what the Web Service can provide in the end, and this is what we want to know within Goal-Capability-Matching. This means by Goal-Capability-Matching we get the information that certain Web Services (or a set of Web Services) can be used to solve the Goal; in the next step we have to check whether we really can use the Web Serivce (can we provide the required input? Do we support other technical features? etc.). Besides, from a modeling perspective, you always need a counterpart for a description notion that shall be taken into account for Goal-Capability-Matching. Within the understanding of Goals outlined above and the description elements existing for Goals in WSMO, there is not such a counterpart for Capability preconditons and assumptions. The conceptual reason for this we explained above.

The solution for Goal-Capability-Matching outlined and implemented here seems to be a proper approach towards a generic Goal-Capability-Matching in WSMO. Nevertheless, it is not finished by now, and we briefly explain the background and the arising challenges for further elaboration of this approach.
In the solution outlined above, the Goal is a fact. Such facts are needed as they have to satisfy the body of the respective Capabilty notions. But the restriction of modeling Goals as facts obviously limits the expressiveness of Goals - in the end, we should be able to define an arbitrary object as Goal that might contain variables and axioms. Also, from an application perspective, the facts that will be applied to check satisfaction of the Capability postcondition and effects would be generated by the internal functionality of the Web Service (or at least by the Web Service owner), and not be stated by the Goal.
Such an approach wherein Goals and Capabilities are modeled as arbitrary logical expressions requires a different, more compley and advanced mechanism for Goal-Capability-Matching. More precisely, we would have to test whether a Capability logically entails a Goal (as stated in the general Proof Obligation above). The result of Goal-Capbility-Matching would be the same as in the solution outlined here: When there are facts that satisfy the Capability postcondition and effect, and if the Capability logically entails the Goal, than those facts will also satisfy the Goal, so the Capability matches the Goal. This approach seems to be the most reasonable solution for Goal-Capability-Matching within WSMO
Unfortunaltely, there are some problems for such a solution. Logical entailment can be realized in different ways - by implication (the Capability postcondition implies the Goal), or by query containment when the Goal and the Capability are modeled as queries. But, logical entailment is not decidable, nor satisfiable for First Order Logic in general. For a proper solution, the logical language to be used for modeling Goals and Capabilities needs to be restricted to a decidable subset of FOL - such as Horn Logic or Description Logic, or a combination of these. Furthermore, there does not exists a proper implementation for determining logical entailment (at least for the existing reasoners that we have considered so far).

In conclusion, the approach for Goal-Capability-Matching presented here seems to be a promising solution because it is heading towards the right direction. For further development of the Goal-Capability-Matching technology within WSMO as the heart of Web Service Discovery, very complex and challenging efforts have to faced: definition of a decidable subset for the specification language of WSMO as well as implementation of logical entailment for the reasoner to be supported within WSMO.

3.1.4 Conclusions

We have described 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. The set up of this use case and the system architecture of the VTA here is conform to the general structure of the VTA use case described in Section 2.1.

Within the WSMO models defined in this use case we have shown how to model the different components of WSMO, with regard to the stable WSMO modeling elements avaliable at this point of time:

Furthermore, we have outlined the general workflow of the WSMO Discovery mechanism that works on the WSMO models for Goals and Capabilities.

The outcome of the first use case modeling are manifold. First of all, it shows how the different WSMO componts are modeled concretely. This gives answers to many questions that have been arising within WMSO: a more concrete understanding of Goals in WSMO and what they actually express, what is defined in a Web Service Capability with special regards to the difference between preconditions and assumptions, postconditions and effects respectively, and the concept of Mediators in WSMO. Further major outcomes of the use case and testing efforts so far is a concrete specification of how to model the different types of axiom definitions in WSMO, as well as further insights on Goal-Capability Matching as the heart of Web Service Discovery mechanism that work on the WSMO models for Goals and Web Service Capabilities. The scope of the use case is restricted to the most essential building blocks of WSMO at this point of time, and it will be updated and extended in the future for testing and showcasesing further WSMO constructs.

3.2 B2B Integration with Semantic Web Services

[not in this version]

3.2.1 Functional Requirements

similar to 3.1.1

3.2.2 WSMO Modeling

similar to 3.1.2

Ontologies

 

Goals

 

Web Services

 

Mediators

 

3.2.3 SWS Mechanisms based on WSMO component models

similar to 3.1.3

3.2.4 Conclusions

similar to 3.1.4

 

4. Conclusions and Further Work

Appart from discussing possible usage scenarios of Semantic Web Services, the major interest in this deliverable is to test and verify WSMO modeling for recursive development of WSMO, and to serve as a testbed for development of WSMO-based technologies. The deliverable is intended to exemplify and showcase the usage of WSMO for modeling different aspects related to Semantic Web Services, and it will continuously be updated according to further development of WSMO.

According to the current status of WSMO, the most interesting aspects are:

The major outcome of the Use Case modeling provided in this deliverable are:

The directions for future work in this deliverable are:

 

References

[Arroyo et al., 2004] Arroyo, S.; Lara, R.; Gómez, J.; Berka, D.; Ding, Y.; Fensel, D. (2004): Semantic Aspects of Web Services. In Munindar. P. Singh (Ed.), Practical Handbook of Internet Computing. Baton Rouge: Chapman Hall and CRC Press, Baton Rouge. 2004.

[Arroyo and Stollberg, 2004] Arroyo, S.; Stollberg, M.: WSMO Primer. WSMO Deliverable D3.1, available at: http://www.wsmo.org/2004/d3/d3.1/v0.1/

[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.; Lausen, H.; Stollberg, M.: Inferencing Support for Semantic Web Services: Proof Obligations. WSML Deliverable D5.1 v0.1, WSML Working Draft 05 Arpil 2004. available at http://www.wsmo.org/2004/d5/d5.1/v0.1/20040405//d5.1v0.1_20040405.pdf

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

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

[Oren et al, 2004] Oren, E. (Ed.): BNF grammar for WSML user language., WSMO Deliverable D16.1, Working Draft 18 April 2004 avaliable at: http://www.wsmo.org/2004/d16/d16.1/v0.2.

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

[SOAP] Mitra, N.: SOAP Version 1.2 Part 0: Primer. W3C Recommendation 24 June 2003. available at: http://www.w3.org/TR/soap12-part0/

[UDDI] Bellwood, T.; Clément, L.; von Riegen, C. (Ed.): UDDI Version 3.0.1. UDDI Spec Technical Committee Specification, Dated 20031014. available at: http://uddi.org/pubs/uddi_v3.htm

[WSDL] Chinnici, R.; Gudgin, M.; Moreaum, J.-J.; Weerawarana, S. (2003): Web Services Description Language (WSDL) Version 1.2. W3C Working Draft 3 March 2003. available at http://www.w3.org/TR/wsdl20/.

 

Acknowledgements

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

The editors would like to thank to all the members of the WSMO working group for their advises and inputs to this document. Very special thanks go to Michael Kifer who supported the development of the models for Goals and Capabilities and especially on elboration of generic solutions for the Goal-Capability-Matching.


Appendix A: Flora2-F-Logic for the VTA - Use Case

Here, the complete WSMO models for the VTA Use Case described in Section can be download as computational resources for testing and development of WSMO with FLORA-2, an F-Logic reasoner. The files below contain the WMSO models of the use case in Flora2-compatible syntax. For testing and development, the files can be loaded into different Flora modules.

Information and download of Flora2 is provided here.

NOTE: the WSMO models for Flora2 are under ongoing development . The most recent resources can be accessed via CVS web-interface at: http://cvs.deri.at/cgi-bin/viewcvs.cgi/*checkout*/wsmo/d3/d32/resources/.

Ontology 1: "International Train Connections Domain Ontology"
Ontology 2: "General Date and Time Ontology"
Ontology 3: "Purchase Ontology"

Goal: "buying a train ticket from Innsbruck to Frankfurt on May 17th, 2004, starting at 6 p.m."

Web Service Capability: "selling international train tickets online for Austria and Germany"

For testing the Goal-Capability-Matching for this use case within FLORA-2, you have to download all the files above into a directory. Then, you have to set up the right environment for running the example; therefore we povide the following additional resources (please note that Flora is sometimes "buggy", and you should make sure that all the resources are compiled with their latest status before you run the Goal-Capability-Matching program. It also sometimes happen that you do not receive the correct answer for some arbitrary runtime reasons)::

We do not provide the Mediators as FLORA-2 resources for download because the connection facility has to be adopted to the Flora-module technology. The files below are simple text files that contain the listings defined in this document. A transformation script will be added in the future.

OO Mediator 1: "Train Connection Ontology uses Date and Time Ontology"
OO Mediator 2: "Goal uses all ontologies"
OO Mediator 3: "Web Service Capability uses all ontologies"
WG Mediator: "connecting Goal and Capability"

Screenshot of the matching result in FLORA-2


webmaster