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.
This document exemplifies the usage of the Web Service Modeling Ontology WSMO for modeling possible Web Service driven applications. We first outline general usage of Semantic Web Service in different application fields, identifying the usage scenarios and the arising technical requirements. Then, we provide the WSMO modeling of specific use cases, in order to demonstrate WSMO modeling and for supporting 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 [Roman et al., 2004].
WSMO Standard: D2 v0.2 Web Service Modeling Ontology (WSMO), last version at: http://www.wsmo.org/2004/d2/
WSMO Primer: D3.1 v01. WSMO Primer
WSMO Reasoning: D5.1 v01. Inferencing Support for Semantic Web Services: Proof Obligations.
This document exemplifies the usage of the Web Service Modeling Ontology WSMO for describing Semantic Web Services and related constructs. To this end, we describe two possible use cases of Semantic Web Services in B2C and B2B scenarios and showcase how these can be modeled in WSMO. We briefly replicate the objectives and the approach of WSMO and outline how specific use cases can be modeled in WSMO along with explanations on the modeling decisions. The modeling is exemplified in a human readable syntax for WSMO descriptions. Besides, resources in pure F-Logic generated from these descriptions which aim at solving Web service discovery based on WSMO using an engine such as FLORA-2 are provided in the appendix.
This Deliverable is intended to evolve in accordance to the ongoing development of WSMO itself, serving as input and providing valuable insight for testing and adapting the modeling constructs provided in WSMO in real world scenarios for Web Services. So, besides demonstrating how to model Web Services in WSMO, the use cases also allow us to demonstrate the adequacy of our approach in terms of providing an exhaustive framework for covering all relevant aspects of semantic description of Web Services. In the long 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 summarizes the objectives and approach of WSMO; Section 2 discusses possible application areas of Semantic Web Services. Section 3 provides the modeling of real world use cases in WSMO. Section 4 concludes the document. The complete WSMO models as computational resources are provided in the Appendices. Besides, we provide facilities for readers to keep track of improvements and discussion related to this document: a Change Tracker in Appendix B explicitly list the major changes between different versions of this document in order to facilitate readers following the improvements.
A Web Service is a piece of software accessible via the Internet. 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 and interoperability 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 resource that can be published, discovered, composed and executed across the Web in a task driven automatic way” [Arroyo et al., 2004]. In the end, by machine-processable descriptions of the relevant information of Web Services, the following tasks shall be addressed:
The aim of the WSMO project 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 needed for a full coverage framework for Semantic Web Services are defined (see Figure 1):
Ontologies provide the formal semantics of the information used by all other components.
Goals specify objectives that a client may have when it consults a web service.
Web Services exposed descriptions of the functionality of a Web Service for supporting automated discovery, composition, and execution (called “Capabilities” in WSMO). For supporting automated usage, composition, and execution of Web Services, particular information on the external visible behavior of a Web Service are specified (called “Interface” in WSMO), including information on the technical accessibility and the actual message exchange of Services.
Mediators 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.
Further details on the components of WSMO along with exhaustive explanations are presented in the WSMO Primer [Arroyo and Stollberg, 2004].
|Figure 1. WSMO Components|
Semantic Web Services can be used in manifold application fields. In accordance to the use cases defined in Web Services Architecture Usage Scenarios by the W3C Web Services Architecture Working Group (see [He et al., 2004]), we discuss two of the most commonly used scenarios to exemplify the usage of SWS technologies in this document:
For describing the use cases, we slightly modify the methodology of the W3C Use Case descriptions and extend them by the requirements arising for Semantic Web Services technologies. The aspects considered for our use case definitions are as follows:
In [He et al., 2004], the travel agency use case is separated into two use cases - one with static discovery and one with automated discovery. With Semantic Web Services we clearly want to support automated discovery. Thus, in the first WSMO use case we will describe a Virtual Travel Agency example that involves automated discovery of Web Services.
Imagine a “Virtual Traveling Agency”, called VTA for short, which is an end user platform providing eTourism services to customers. These services can cover all kinds of information services concerned with tourism information - from information about events and sights in an area to services that support booking of flights, hotels, rental cars, etc. online. Such VTAs are already existent, but at this point mostly comprise simple information portals along with some web-based customer services (see for example an eTourism service provider in Austria at: http://www.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 in a (semi-)automatic fashion. Such VTAs providing automated eTourism services to end users thus tremendously enhance the functionality of currently existing VTAs.
Our VTA use case that aggregates Web Services of different tourism service providers in a nutshell shall provide the following functionality: A customer uses the VTA service as the entry point for his requests. These requests must fit to end-user services that the VTA provides. These end-user services are aggregated by the VTA by invoking and combining Web Services offered by several tourism service providers. Therefore, there must be some kind of contract between the service providers and the VTA for regulating usage and allowance of the Web Services. Figure 2 gives an overview (modified and extended from W3C Travel Agent Use Case overview, as defined in [He et al., 2004]).
|Figure 2. Use Case Overview: Virtual Travel Agency based on Semantic Web Services|
The scenario outlines a general structure for VTAs that can be extended to more complex scenarios wherein the customer can be a Web Service itself, thus creating a network of composed services that offer complex tourism services. For example, one VTA can provide flight booking services for an airline union, another VTA aggregates booking service for a worldwide hotel chain, and a third VTA provides booking services for rental cars by combining the services of several worldwide operating car rental agencies. Then, another VTA uses these services for providing an end-user service for booking complete holiday trips worldwide.
We provide the modeling of one such VTA use case in Section 3.1.VTA for International Online Train Ticket.
In the general use case there are 3 actors. The following defines why they participate in this use case (goal) and the particular interactions they are involved in (roles).
We identify the following usage scenarios
In this use case, the VTA is the central point of interaction between the Customer and other Web Services. Regarding the technological requirements, it is obvious from the usage scenario descriptions that (1) the Web Services offered by the Service Providers have to carry sufficient descriptive information to support automated Web Service usage, and (2) that the VTA has to provide all mechanisms to handle Semantic Web Services. The basic architecture of such a VTA as a central entity for Semantic Web Services handling is shown in Figure 3. The essential functionalities of Semantic Web Service enabled VTAs – with special regard to the requirements for Semantic Web Service technologies – are:
|Figure 3. General Architecture of a SWS-enabled VTA|
Summarizing, the VTA is a SWS-enabled B2C application that provides an end-user service following a client/server model. In order to support coherent functionality of the VTA and to ensure that the descriptions of Web Services are compatible to this, an overall framework for SWS technologies is needed. This is provided by WSMO.
The second use case is concerned with the integration of possible heterogeneous resources in B2B settings which is considered as one of the most important application fields of the Web Service technology.
In the B2B use case, two enterprises called E1 and E2 want
electronically exchange business documents across the network. Assuming
that partners may not know each other before, contract negotiation and
contract agreement are essential aspects of this use case. The contract
agreement defines roles of enterprises in the conversation, for
instance, one of the enterprise E1 becomes the seller and the second
enterprise E2 becomes the buyer. An agreement also predefines the order
of the messages interchanged between the parties, e.g.the buyer first
sends purchase order (PO) and after that it receives purchase order
acknowledgement (POA). In constrats to the previous B2C use case, where
the client/server model of interactions has been adopted, here partners
are equal in the interaction, i.e. a peer-to-peer model is assumed in
this use case. Each of the companies has an own set of web services for
exchanging business documents electronically. The 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), as well as linking web services and
goals. The infrastructure also supports the execution of the contract
to fulfill approved agreement.
|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 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.
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:
In this use case the following usage scenarios have been identified:
The Web Services Modeling Execution (WSMX) is the infrastructure is a WSMO-reference implementation that addresses this use case, see WSMX hompage at: http://www.wsmo.org/wsmx/. Therein, a WSMX-platform is 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.
|Figure 5. B2B Use Case System Architecture|
The following exemplifies the usage of WSMO for describing Semantic Web Services for some specific aspects of the use cases decribed above. In the following we will:
The provided listings use the conceptual model presented in WSMO Standard, V0.2 as the latest stable version of WSMO. During the elaboration of this use, several conceptual refinements have been undertaken which we explicitly describe in the text. For modeling, we apply the syntax defined in in D16.1 v02 BNF Grammar for WSML language. Currently, we support FLORA-2 as an F-Logic reasoner (see documentation and download of the latest distributions at the FLORA-2 homepage http://flora.sourceforge.net/). We provide the models as executable resources for FLORA-2 in Appendix A of this document.
According to the general VTA use case described in Section 2.1 B2C - Virtual Travel Agency we define a specific use case for booking international train tickets online. We describe a hypothetical Web Service, combining the functionality provided by the Austrian national train operator (ÖBB) and the German Railways (DB), which offer end-user services for searching and buying train tickets for itineraries in Austria and in Germany. This Web Service is composed out of other Web Services, namely one for searching existing train connections, and one for purchasing train tickets online. The services of ÖBB and DB are currently not provided in a machine-processable manner but only via simple end-user web interfaces - Figure 6 shows the currently available portal for ÖBB where the user has to manually select the desired train connection and is lead through the purchase process.
As a user request we assume that the user wants to purchase an
international train ticket. The course of the use case shall be the
- the customer creates a goal for an international train connection from Innsbruck to Frankfurt on 17th 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 an online ticket per email to the Customer.
|Figure 6. ÖBB Train Connection Itinerary Service|
The rationale for choosing this first use case is that it allows to showcase and test describing all WSMO components identified in WSMO Standard. The setting is kept simple on purpose. More complex cases to be added at a later stage of this deliverable can build upon this, providing models of more involved scenarios.
The following properties have to be covered in our use case modeling. For each of the WSMO top-level components, a separate table describes informally which parts of the use case are concerned.
Ontological information are needed on international train itineraries, on notions of date and time, on the purchasing process, as well as on persons, locations, and addresses. This information should be kept in separate re-usable ontologies, following the modularity principle of ontology design.
|O2||An itinerary is described by its start and end locations, date and time of departure and arrival, stations which the train passes (particularly, the station where the border is crossed) and is done by some passenger.|
|O3||An itinerary describes a valid international train connection.|
|O4||There has to be traveller / customer that does the itinerar/buys a train ticket|
|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 and has a price|
|O7||A ticket is valid for exactly 1 customer|
|O9||The purchase ontology has to identify the buyer and seller roles, a product with a price, and valid payment methods|
|O10||We need to be able to express valid payment methods. The only valid payment method for online tickets is credit card payment|
|O11||Information on Date and Time should allow axiomatic expressions on dependencies of specific dates and times , i.e. expression that define relationships like 'after' or 'before '|
|G1||Booking an Online Train Ticket|
|G1.1||From Innsbruck to Frankfurt|
|G1.2||Start time: 17th July 2004, at 18.00 local time.|
|W1||A National Train Operator, here the Austrian ÖBB, provides an end-user Web Service that offers a search facility for international train connections and a facility for buying international train tickets online.|
|W2||The search facility takes a start location, an end location, and a departure date as input and returns a set of itineraries.|
|W3||The facility for buying train tickets online takes a specfic itinerary with start location and end location in countries of its coverage, the information of the customer and the number of his (not expired) credit card number as input, and it returns a ticket for this itinerary as the result.|
|W4||The user interacts with the end-user Web Service which aggregates the search and purchasing Web Services from possibly different providers like ÖBB, DB, etc.|
|M1||There need to be OO Mediators that integrate the distinct ontologies used as terminology definitions.|
|M2||If there are terminological mismatches between the ontologies used in the Goal or the Web Service description, OO Mediators have to be defined to resolve these.|
|M3||If there are differences between the Goal and the ÖBB-Web Service, a WG Mediator is needed to resolve these.|
|M4||if there are mismatches between the search facility Web Service and purchase Web Service (which are composed into the end-user Web Service), then a WW Mediator has to be defined which resolves the mismatches.|
The following provides the modeling of the use case in WSMO with respect to the requirements determined above. The modeling in this document relies on the Web Service Modeling Ontology WSMO, Version 0.2 [Roman et al., 2004]. Some elements of WSMO at not completely specified at the current version of the ontology. This version of the use case modeling is restricted to the WSMO components wherefore a stable specification is existing at this point in time.
With regard to modularized ontologies as a basic design principle of WSMO, we define four separate domain ontologies as the the terminology definitions for the use case:
The ontologies specified in the following are intended to be "real ontologies" in the sense that they describe the specific domain as a shared conceptualization in a sufficient manner. This allows to reuse this ontologies in different settings and use cases - for example, notions or date and time or a general purchase ontology are needed in a lot of other possible scenarios. However, we do not claim the defined below to be such generic ontologies, but they will be enhanced and completed within cooperations with other use cases, projects, and initiatives.
The "International Train Ticket" Ontology defines a train trip and the surrounding concepts as defined the WSML definition of the ontology shown in Listing 1.
The definition of the ontology is based on the travel itinerary ontology from the DAML ontology library, which defines travel itineraries for trips by plane. Our ontology reuses the itinerary and flight concepts and adapt them to define train trips, also introducing new concepts such as train station. The international train ticket ontology also makes use of the person ontology defined at http://daml.umbc.edu/ontologies/ittalks/person, which defines a subset of vCard. The person concept is used to define the passenger information for an itinerary. We did not find any other available ontologies that model the domain of train tickets or itineraries. The first version of the harmonize ontology for the tourism domain focuses on the events and accomodations subdomains. We will take into account future versions of the harmonise ontology, as they are likely to include the travelling subdomain.
Please notice that the link to large set of instances is missing in WSMO. Therefore, in this version of the ontology we only include some example instances, which holds for the other ontologies defined in this use case as well. The inclusion of links to large set of instances will be considered in future versions of WSMO.
The "Date and Time Ontology" in Listing 2 defines models for dates (i.e. certain days) and time (i.e. definition of certain points in time). Further, it defines axioms that represent conventional aspects of date and time, like ´before´ and ´after´, etc. In the use case, this is needed to determine validity of train connections, e.g for ensuring that a ticket is not for an itinerary that is in the past. It also can be used generally for expressing dates and time and relationships between them.
The main ontology taken into consideration for developing this conceptual model of Date and Time is an entry sub-ontology of time, available at http://www.isi.edu/~pan/damltime/time-entry.owl. This ontology uses abstract temporal concepts like instant, interval and event and uses the Gregorian calendar as representation (partly using own encoding and partly using XSD encoding). Axioms are defined in first order logic in the accompanying paper [Pan and Hobbs]; there also is a LISP version of these axioms available at http://www.cs.rochester.edu/~ferguson/daml/daml-time-20030728.lisp. Other ontologies like COBRA calenderclock ontology (http://daml.umbc.edu/ontologies/cobra/0.4/calendarclock) are only a straight forward representation of the Gregorian calendar, without any abstraction of concepts and description of axioms. Widely used concrete representations for date and time are defined in ISO 8601 (Numeric representation of Dates and Time) and in the XML Schema Definition (http://www.w3.org/TR/xmlschema-2/), which is based on ISO 8601.
The "Purchase" ontology defines general concepts to make a purchase order request. The ontology is an WSML representation of the RosettaNet's PIP3A4 "PurchaseOrderRequest" [RosettaNet]. RosettaNet is a consortium of major Information Technology, Electronic Components, Semiconductor Manufacturing, Telecommunications and Logistics companies working to create and implement industry-wide, open e-business process standards. These standards form a common e-business language, aligning processes between supply chain partners on a global basis.
Every standard business transaction within the RosettaNet trading network is defined in a so called PIP (Partner Interface Process) which defines the XML code, activities, decisions and Partner Role interactions between two partners in the supply chain. Each partner participating in the "Partner Interface Process" must fulfill the obligations specified in a PIP. These PIPs are organized into seven clusters, or groups of core business processes, that represent the backbone of the trading network. Each cluster is broken down into segments which are cross-enterprise processes involving more than one type of trading partner. Within each segment are individual PIPs, whereas the above mentioned PIP3A4 is part of Segment 3A "Quote and Order Entry". This segment allows partners to exchange price and availability information, quotes, purchase orders and order status, and enables partners to send requested orders, or shopping carts, to other partners.
At the current state this domain ontology is preliminary and will be further enhanced in future versions. As far as RosettaNet's PIPs are only intended for the use in the above mentioned industry sectors we also consider and partly work on the ontologizing of other conceptualizations, inter alia ebXML [ebXML] and EDIFACT [EDIFACT].
The "Locations Ontology" defines an concepts for locations, including cities and states, as well as postal addresses. This ontology the DAML ontology for geographical locations, an ontology describing a wide variety of locations and geographical areas. The concept country is extended using the OWL-Factbook ontology. The concept address reuses the DAML address ontology.
Goals denote what a user wants as the result of the Web Service. For modeling the goal, we describe the information elements that the user wants to get from the service (the postcondition) together with the state of the world desired after the service execution (the effect).
In WSMO, Goals can be defined a different levels of granularity. By so-called GG Mediators, new, more specific Goals can be created out of generic existing Goals. You can also think of generic Goals as being pre-defined in a specific application context, wherefrom concrete Goals can be generated from. In order to showcase this, we define a generic Goal for buying a ticket for any kind of trip (Listing 5), a concrete Goal wherein a user wants to buy a train itinerary from Innsbruck to Frankfurt on a certain date (Listing 6), and a GG Mediator that restricts the generic Goal to tickets for traintrips within Austria and Germany (in the section of Mediators defined for this Use Case.
Listing 5 shows the generic Goal with the following description elements:
The concerte Goal states that the desire is to get the description of the itinerary bought, and that the effect of the Web Service has to be a trade between the train company and the requester for the desired itinerary. Listing 6 shows this Goal with the following elements:
Notice that an instance of the concept 'Itinerary' is used as the value of the property 'Items' of the concept 'Trade'. In the ontologies defined above, Itinerary is not defined in tc.wsml as a subconcept of po:product. This subclassing should be done by an OO-mediator that imports the terminology required for the goal and takes care of this operation. Such a mediator will be included in the next version of this deliverable.
As explained above, we define one (imaginary) Web Service in this use case: an end-user service (means that the user interacts with this service) for purchasing international train tickets offered by the Austrian national train operator ÖBB, which is composed of other Web Services, each for the search and buying facility of international train tickets. This setting allows modeling all notions of a WSMO Web Service description: A Capability of the end-user service and its Choreography for user-service interaction, as well as the orchestration which incorporates the aggregated Web Services. The current version of WSMO Standard does only provide a stable specification for describing Capabilities, the model below is restricted to the overall Web Service description and the Capability definition. The modeling for the WSMO Web Service Interface will be added in a later version.
A Web Service Capability in WSMO is described by pre- and postconditions, assumptions and effects, as defined in [Roman et al., 2004]. Listing 7 shows the ÖBB Web Service description, currently the Capability only. More detailed discussion of the Discovery mechanism of WSMO Goals and Capabilities is provided in section 3.1.3. The Capability description elements are defined as follows:
As in the modeling in the Goal, here an instance of the concept 'Itinerary' is used as the value of the property 'Items' of the concept 'Trade', while Itinerary is not defined in tc.wsml as a subconcept of po:product. The OO-mediator that imports the terminology required for the capability and performs this operation willbe included in the next version of this deliverable.
OO Mediators "connect" ontologies with other ontologies or OO Mediators for refining ontologies, as well as for importing ontologies as the terminology definitions into other WSMO components. As the Goal and the Web Service specified above have homogeneous information spaces, we only have to specify OO Mediators for the existing ontologies used for the domain ontologies defined in this use case. Here, we have to define the following OO Mediators, specified in the Listings below:
Notice that the mediation services are not specified. For importing an OWL ontology into a WSML ontology, it is obvious that such mediation services are required. The terminology to express the capability of mediation services as well as the requester goals is not defined at the moment. This terminology, modeling the ontology mediation domain, has to be included in future versions of the deliverable and the necessary goals and capabilities have to be defined using such terminology.
A WG Mediator links a Web Service to a Goal, resolves terminological mismatches, and states the functional difference (if any) between both. The main application of WG Mediators is handling of partial matches within Web Service discovery. For resolving terminological mismatches, OO Mediators are applied, similar to the ones specified above. The functional difference is stated in the reduction which restricts the set of valid ontology objects to be passed between the Web Service and the Goal.
In our use case, we do not need an WG Mediator, because the Goal and the Web Service Description use the same domain ontologies (i.e. there are not terminology mismatches), and there is no functional differences between the Goal and the Capability. An WG Mediator with a reduction would be needed if the Web Service Capability specifies that train tickets as well as plane tickets are sold: Therefore, the reduction would restrict the valid set of information to train tickets, as requested by the Goal.
A GG Mediator connects Goals, specifying the possible functionality reduction. For example, a GG Mediator would connect a Goal "buy a ticket" with another Goal "buy a train ticket" by stating the ontological correspondance between the Goals as a reduction. If 'train ticket' is a subclass of 'ticket', than the reduction in the GG Mediator would specify that valid instances for the second Goal have to be 'train ticket subclassof ticket'.
In our use case, we have defined a generic Goal for buying a ticket for any kind of trip (Listing 5), a concrete Goal wherein a user wants to buy a train itinerary from Innsbruck to Frankfurt on a certain date (Listing 6). The GG Mediator restricts the generic Goal to buying train tickets for itineraries in Austria and Germany; this GG Meditaor is used within the concrete Goal, wherein only specific values are defined for the ontological notions provided by the GG Mediator. Therefore, the GG Mediator has the following description elements:
A WW Mediator connects Web Services used by another Web Service in ther Orchestration, resolving heterogeneities at all levels (data, process, protocol). Also, WW Mediators are applied to resolve heterogeneities on the data, process, and protocol level between the Choreographies of Web Services that are ought to interact in a global interaction model.
There is no WW Mediator in this use case at this point in time, since the Orchechstration of the ÖBB end-user Web Service is not specified in this version. Future versions might include the definition of the composition of the search and buying service, wherein a WW Mediator might be applied.
On basis of the models for the WSMO components specified above, we can define automated mechanisms for 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 us, restricted to Web Service Discovery at this point in time.
Web Service Discovery is concerned with inference-based mechanisms that detect suitable Web Service for a given Goal. This means that the discovery mechanism inspects 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 the realization of Web Service Discovery within FLORA-2 on basis of the use case models as specified above.
In general, Web Service Discovery is separated into three major aspects:
The theory of Web Service Discovery is exhaustively discussed in [Keller et al., 2004]. Therein, the general proof obligation is defined, and different approaches by means of logic programming are presented as discussed in detail. For Web Service Discovery in this use case, we implemented the approach "Goal as ground facts", see section 4.2.1 in [Keller et al., 2004]. Summarizing, the matchmaking works as follows:
The approach for matchmaking is to check whether the ground facts specidied in the Goal satisfy the rules of the Capability. Obviously, this is facilitated by the contruction of Goals and Capabilities. Considering the Goal as specfied in Listing 5, the Goal postcondition is fact that satisfies the body of the Capability postcondition in Listing 6: the Goal Postcondition is a specific itinerary (from Innsbruck to Frankfurt with a certain departure), and the body of the Capability postcondition requires an itinerary with start- and endlocation in Austria or Germany, respectively, and with a departure that has to be later than the current date (the current date is modeled as an instance of dateandtime from the Date and Time Ontology as there is no built-in function yet). The same matching holds for the Goal Effect in correlation to the Capability Effect. Thus, the following discovery query returns the identifier of the ÖBB end-user service, as a service that can satisfy the Goal. The result of successful discovery in Flora is shown in the screenshot in Figure 7.
Figure 7. Successful Web Service Discovery in FLORA-2
The transformation of the WSMO models as specified in the Listings to FLORA-2 compilable F-Logic is trivial, as WSML relies on F-Logic. The complete models for the use case as FLORA-compilable resources is provided in Appendix A. However, there are some aspects that have to be considered for the transformation of WSML definitions to FLORA-2 syntax:
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, e.g. definition of a decidable subset for the specifications of logical expression in WSML as well as implementation of logical entailment for the reasoner to be supported within WSMO.
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 top-level 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, inparticluar
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 the specification and realization of Goal-Capability Matching as the heart of WSMO-enabled Web Service Discovery mechanisms. 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.
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:
[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/
[Biron & Malhotra, 2001] P. V. Biron and A. Malhotra: XML Schema Part 2: Datatypes, W3C Recommendation 02, 2001, avaliable at: http://www.w3.org/TR/xmlschema-2/.
[Bray et al. (Eds.), 1999] Bray, T.; Hollander, D. and Layman, A.:Namespaces in XML, W3C Recommendation, 14 January 1999, avaliable at: http://www.w3.org/TR/REC-xml-names/.
[ebXML] ebXML, avaliable at: http://www.ebxml.org.
[EDIFACT] UN/EDIFACT, avaliable at: http://www.unece.org/trade/untdid/welcome.htm.
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[He et al., 2004] he, H.; Haas, H.; Orchard, D.: Web Services Architecture Usage Scenarios, W3C Working Group Note 11 February 2004. available at: http://www.w3.org/TR/ws-arch-scenarios/.
[Hayes (Ed.), 2004] P. Hayes: RDF Semantics, W3C Recommendation 10 February 2004, 2004.
[Keller et al., 2004] Keller, U.; Lara;, R.; Polleres, A.; Lausen, H.; Stollberg, M., Kifer, M..: Inferencing Support for Semantic Web Services: Proof Obligations. WSML Deliverable D5.1 v0.1, WSML Working Draft 21 June 2004. available at http://www.wsmo.org/2004/d5/d5.1/v0.1/20040621/
[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 language., WSMO Deliverable D16.1 v0.2, Working Draft 12 June 2004 avaliable at: http://www.wsmo.org/2004/d16/d16.1/v0.2/20040612/.
[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/.
[RosettaNet] RosettaNet, avaliable at: http://www.rosettanet.org.
[SOAP] Mitra, N.: SOAP Version 1.2 Part 0: Primer. W3C Recommendation 24 June 2003. available at: http://www.w3.org/TR/soap12-part0/
[Thompson et al. (Eds.), 2001] H. S. Thompson, D. Beech, M. Maloney and N.Mendelsohn: XML Schema Part 1: Structures, W3C Recommendation, May 2001, avaliable at: http://www.w3.org/TR/xmlschema-1/.
[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/.
[Yang and Kifer, 2003] G. Yang, M. Kifer: Reasoning about Anonymous Resources and Meta Statements on the Semantic Web J. Data Semantics I 2003: 69-97.
The work is funded by the European Commission under the projects DIP, Knowledge Web, SEKT, SWWS, Esperonto, and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program.
The editors would like to thank to all the members of the WSMO working group for their advice and input into this document.
Here, the complete WSMO models for the VTA Use Case described in Section 3.1 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/.
"International Train Connections Domain Ontology"
Ontology 2: "General Date and Time Ontology"
Ontology 3: "Purchase Ontology"
Ontology 4: "Locations Ontology"
Goal: "buying a train ticket from Innsbruck to Frankfurt on May 17th, 2004, starting at 6 p.m."
Web Service : "selling international train tickets online for Austria and Germany"
We do not provide the Mediators here, as they would have to be translated to Flora-specific technology.
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, which facilitate the representation of WSMO models in Flora2, as described in Section 3.1.3. 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:
To facilitate retracing of changes inbetween different version of this deliverable, the following lists the essentail changes done in comparison to the preceding version.
The change tracking starts with the version of 28 June 2004.