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 technical requirements arising. Then we provide the WSMO modeling of specific use cases, aiming at demonstrating WSMO modeling and 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.
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.
This document exemplifies the usage of the Web Service Modeling Ontology WSMO for describing relevant aspects for Semantic Web Services. 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.
The modeling examples provided in this document rely on the latest final working draft of the Web Service Modeling Ontology WSMO, Version 0.2.
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 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 expose descriptions of their functionality for supporting automated discovery, composition, and execution (called “Capabilities” 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.
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.
 |
| Figure 1. WSMO Components |
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 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 most important aspects considered for our use case definitions are as follows:
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.
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 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).
 |
| Figure 2. Use Case Overview: Virtual Travel Agency based on Semantic Web Services |
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
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).
We identify the following usage scenarios
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:
 |
| 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.
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. 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.
 |
| 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.
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:
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.
 |
| Figure 5. B2B Use Case System Architecture |
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:
The provided listings use the conceptual model presented in WSMO Standard, V0.2, whereas differences and extensions are marked explicitly by a yellow background color. The concrete Syntax proposed will be described in D16.1 (BNF Grammar for WSML). (Please note the current (18 April 2004) draft is not yet in line with the listings in this document.) The Flora listings are provided for download, testing and development in the Appendices. Currently, we support FLORA-2 as a F-Logic reasoner (see FLORA-2 homepage).
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 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 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.
 |
| Figure 6. ÖBB Train Connection Itinerary Service |
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.
| O1 | We need ontological information on international train itineraries, on notions of date and time, on the purchasing process, and on persons, locations, and addresses. 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 |
| 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 allow axiomatic expressions on dependencies of specific dates and times , i.e. expression that define relationships like 'after' or 'before ' |
| G1 | Booking a Online Train Ticket |
| G1.1 | From Innsbruck to Frankfurt |
| G1.2 | Start time: 17th July 2004, at 18.00 local time |
| W1 | Each National Train Operator provides a Web Service that offers 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 online ticketing service takes as input an itinerary with start location and end location in countries of its coverage, a credit card number, and it returns a ticket for this itinerary as the result. |
| W2.2.1 | Exceptions are: - Service not available - Credit card not accepted |
| M1 | There exists a WG Mediator to link the Goal G1 to a train online ticket booking Web Service, resolving possible mismatches. |
| M2 | OO-Mediators: All WSMO components apply those domain ontologies needed for the component's specification. |
| M3 | OO-Mediators with mediation facilities to integrate the distinct ontologies are needed. |
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.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.
We define 4 domain ontologies that provide the terminology definitions for the use case:
We apply the following conventions in the Listings (the differences / extensions with respect to [Roman et al., 2004]):
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.
ontology http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/tc.wsml
namespace
default=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/tc.wsml#,
dc=http://purl.org/dc/elements/1.1#,
wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418#,
dt=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/dt.wsml#,
prs=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/owlPersonMediator.wsml,
loc=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml#,
xsd=http://www.w3.org/2001/XMLSchema#
non-functional-properties
dc:title "International Train Connections Ontology"
dc:creator "DERI International"
dc:subject "Train", "Itinerary", "Train Connection", "Ticket"
dc:description "International Train Itineraries"
dc:publisher "DERI International"
dc:contributor "Michael Stollberg", "Ruben Lara", "Holger Lausen",
"Axel Polleres"
dc:date "2004-05-31"
dc:type http://www.wsmo.org/2004/d2/v0.3/20040329/#ontos
dc:format "text/plain"
dc:language "en-US"
dc:relation
http://www.daml.org/2001/06/itinerary/itinerary-ont,
http://daml.umbc.edu/ontologies/ittalks/person,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/dt.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml
dc:coverage "ID:7029392 Name:World"
dc:rights http://www.deri.org/privacy.html
version "$Revision: 1.4 $"
usedMediators
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/owlPersonMediator.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/owlFactBookMediator.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/dt.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml
conceptDefinitions
concept station subconceptOf loc:location
non-functional-properties
dc:description "Train station"
code oftype xsd:string
non-functional-properties
dc:description "Code of the station"
locatedIn oftype set loc:location
borderToCountry oftype set loc:country
non-functional-properties
dc:description "For stations located at the border"
concept itinerary
non-functional-properties
dc:description "An itinerary between two locations"
passenger oftype prs:person
non-functional-properties
dc:description "prs:person is a subset of vCard (http://www.ietf.org/rfc/rfc2425.txt)"
recordLocatorNumber oftype xsd:string
trip oftype trip
concept trip
start oftype loc:location
end oftype loc:location
via oftype set loc:location
departure oftype dt:dateAndTime
arrival oftype dt:dateAndTime
duration oftype dt:interval
distance oftype distance
concept trainTrip subconceptOf trip
start oftype station
end oftype station
via oftype set station
seat oftype xsd:string
train oftype set xsd:string
class oftype class
concept distance
non-functional-properties
dc:description "Distance between two points"
amount oftype xsd:float
units oftype xsd:string
method kilometers
non-functional-properties
dc:description "Method that returns the distance (amount) in kilometers"
range DistanceKm oftype xsd:float
method miles
range DistanceMiles oftype xsd:float
non-functional-properties
dc:description "Method that returns the distance (amount) in miles"
concept class
non-functional-properties
dc:description "Class of the seat for the itinerary"
name oftype xsd:string
service oftype set service
concept service
non-functional-properties
dc:description "Services included in a trip"
name oftype xsd:string
description oftype xsd:string
concept meal subconceptOf service
axiomDefinitions
axiom stationCountry
non-functional-properties
dc:description "Integrity constraint: if a station is located in a place
which is located in a given country, the country of the station is the
same"
logical-expression
"<-
S memberOf station[
locatedIn hasvalue L,
country hasvalue C]
and L[
country hasvalue C2]
and C=C2."
axiom depatureBeforeArrival
non-functional-properties
dc:description "Integrity Constraint: departure has to be before arrival"
logical-expression
"<-
T memberOf trip[
departure hasvalue D,
arrival hasvalue A]
and dt:afterDateAndTime(A, D)."
axiom validDistance
non-functional-properties
dc:description "The amount in a distance cannot be less than 0.
We only accept kilometers and miles."
logical-expression
"<-
D memberOf distance[
amount hasvalue A,
units hasvalue U]
and A >= 0
and (U="Kilometers" or U="Miles")."
axiom kilometers
non-functional-properties
dc:description "Converts miles to kilometers"
logical-expression
"DistanceKm <-
Self memberOf distance[
amount hasvalue A,
units hasvalue U] and
(U="Miles"
and DistanceKm=A*1.609344) or
(U="Kilometers"
and DistanceKm=A)."
axiom miles
non-functional-properties
dc:description "Converts kilometers to miles"
logical-expression
"DistanceMiles <-
Self memberOf distance[
amount hasvalue A,
units hasvalue U] and
(U="Miles"
and DistanceMiles/1.609344=A) or
(U="Kilometers"
and DistanceKm=A)."
axiom equalityDistance
non-functional-properties
dc:description "Computes equality of a distance"
logical-expression
"X = Y <-
X memberOf distance and Y memberOf distance and
X.kilometers = Y.kilometers."
axiom lessThanDistance
non-functional-properties
dc:description "Computes -less than- for a distance"
logical-expression
"X = Y <-
X memberOf distance and Y memberOf distance and
X.kilometers < Y.kilometers."
axiom moreThanDistance
non-functional-properties
dc:description "Computes -more than- for a distance"
logical-expression
"X = Y <-
X memberOf distance and Y memberOf distance and
X.kilometers > Y.kilometers."
instanceDefinitions
comment: A link to large set of instances is missing in WSMO.
Therefore, in this version of the ontology we only include
some example instances. The inclusion of links to large
set of instances will be considered in future versions of
WSMO
instance innsbruckHbf memberOf station
name hasvalue "Innsbruck Hbf"
code hasvalue "INN"
locatedIn hasvalues {loc:innsbruck}
instance frankfurtHbf memberOf station
name hasvalue "Frankfurt Hbf"
code hasvalue "FKF"
locatedIn hasvalues {loc:frankfurt}
|
Please notice that the link to large set of instances is missing in WSMO. Therefore, in this version of the ontology (as well as for the other ontologies defined for the use case) we only include some example instances. The inclusion of links to large set of instances will be considered in future versions of WSMO.
Also Notice that we model two methods, Kilometers and Miles, that return the amount of kilometers and miles, respectively, of an instance of the concept Distance. As we always want to obtain the values in kilometers or miles of a given instance of the Distance concept, this is more naturally modelled as a method and not as a function. However, in F-Logic nothing prevents a user from overwriting these methods when using the ontology. If this is done, problems may arise.
Method definitions in WSMO do not explicitly represent the instance to which the method is applied. As we have to refer to such instance when modelling the axioms that define the range of the methods in Listing 1, we have introduced a special constante "self" to refer to it.
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.
ontology http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/dt.wsml
namespace
default=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/dt.wsml#,
dc=http://purl.org/dc/elements/1.1#,
wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418#
non-functional-properties
dc:title "Date and Time Ontology ontology"
dc:creator "DERI International"
dc:subject "Date", "Time", "Date and Time Algebra"
dc:description "generic representation of data and time including basic algebra"
dc:publisher "DERI International"
dc:contributor "Holger Lausen", "Axel Polleres", "Ruben Lara"
dc:date "2004-07-06"
dc:type http://www.wsmo.org/2004/d2/v0.3/20040329/#ontos
dc:format "text/plain"
dc:language "en-US"
dc:relation http://www.isi.edu/~pan/damltime/time-entry.owl,
http://www.w3.org/TR/xmlschema-2/
dc:coverage "World"
dc:rights http://www.deri.org/privacy.html
version "$Revision: 1.8 $"
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 "concept 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"
subconceptOf 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 "concept date and time and representing together a specific point of time (instant)"
subconceptOf instant
date oftype date
time oftype time
comment: variableDefintions
variable X, Y, Z, D1, D2 oftype topConcept
variable A, B, C, D, E, F, JDN, JDN_D1, JDN_D2, SFM_T1, SFM_T2 oftype xsd:integer
variable T, T1, T2 oftype time
variable JulianDayNumber, Difference, SecondsFromMidnight oftype xsd:integer
variable Instant, Instant1, Instant2 oftype instant
comment: relationDefinitions
relation invalid
non-functional-properties
dc:description "the invalid relation is one way to encode an integrity constraints,
if the extension of this relation is non empty the ontology is inconsistent, i.e.
the extension contains all invalid resources.
Axioms can be used to define the extension e.g. validMonthOfYear"
parameter anyObject oftype topConcept
comment: functionDefintions
function julianDayNumber
non-functional-properties
dc:description "The Julian Day Count is a uniform count of days from a remote epoch
in the past (about 4712 BC). At this instant, the Julian Day Number is 0. Once
you have the Julian Day Number of a particular date in history, it is easy to
calculate time elapsed between it and any other Julian Day Number"
dc:source http://quasar.as.utexas.edu/BillInfo/JulianDatesG.html
parameter Instant oftype instant
non-functional-properties
dc:descripion "For each instant there should exist a corresponding Julian Day
Number, however it may not be always defined only by this binary predicate,
e.g. if the instant is represented as Gregorian Date and it is a date between
1582 and 1924 a country must be given as third parameter (since e.g. Greece
changed no earlier then 9th of March 1924 from the Julian to the Gregorian Calendar)"
comment: The following dc:source indicates which country changed in which year
comment: from the Julian to the Gregorian Calendar
dc:source http://members.brabant.chello.nl/~h.reints/cal/whenjul2greg.htm
range JulianDayNumber oftype xsd:integer
function daysBetween
non-functional-properties
dc:description "(Instant1, Instant2, Difference) is a triple of the ternary relation
corresponding to this function iff Instant1 and Instant2 are members of the concept
'instant' (particular point in time) and Instant2 is 'Difference' days after Instant1."
parameter instant1 oftype instant
parameter instant2 oftype instant
range oftype integer
function secondsBetween
non-functional-properties
dc:description "(Instant1, Instant2, Difference) is a triple of the ternary relation
corresponding to this function iff Instant1 and Instant2 are members of the concept
'instant' (particular point in time) and Instant2 is 'Differnce' seconds after Instant1."
parameter instant1 oftype instant
parameter instant2 oftype instant
range oftype integer
function secondsFromMidnight
non-functional-properties
dc:description "(Time, SecondsFromMidnight) is a tuple of the binary relation
corresponding to this function iff SecondsFromMidnight are the seconds elapsed from
00:00:00 of the same day.
This simplifies the axiomatization of the difference between two given times"
parameter time oftype time
range oftype integer
function contains
non-functional-properties
dc:description "(Interval, X) is a tuple of the binary relation
corresponding to this function iff Interval contains X and X is an instant or an
interval"
parameter interval1 oftype interval
range oftype (instant or interval)
comment: axiomDefintions
axiom validMonthOfYear
non-functional-properties
dc:description "integrity constraint for valid monthOfYear"
logical-expression
"invalid (X) <-
X memberOf monthOfYear and
(X < 1 or X > 12)."
axiom validDayOfMonth
non-functional-properties
dc:description "integrity constraint for valid dayOfMonths"
logical-expression
"invalid (X) <-
X memberOf dayOfMonth and
(X < 1 or X > 31)."
axiom validDate
non-functional-properties
dc:description "Integrity Constraints for date.
The dayOfMonth is valid in dependency of the actual monthOfYear, in a leap
year the month 2 of the Year has 29 days otherwise 28. For leap years holds
the following: Every year divisible by 4 is a leap year. However, every
year divisible by 100 is not a leap year. However, every year divisible by
400 is a leap year after all.
Note: This axiomatization is still imprecise, since the country plays a role
when defining a valid day of the month: E.g. 1712 was a double leap year
in Sweden, i.e. February 1712 had 30 days in Sweden.
The mathematical function symbol modulo is assumed to be defined elsewhere
as that it returns the remainder after an integer division of its
first argument by its second"
dc:source http://www.tondering.dk/claus/cal/node3.html
logical-expression
"invalid (X) <-
X memberOf date and
(invalid(X.monthOfYear) or invalid(X.year)
or (X.dayOfMonth > 31 and X.monthOfYear = 1)
or (X.dayOfMonth > 28 and X.monthOfYear = 2
and not (modulo(X.year,4) = 0 and (modulo(X.year,100) != 0 or modulo(X.year,400) = 0)))
or (X.dayOfMonth > 29 and X.monthOfYear = 2)
or (X.dayOfMonth > 31 and X.monthOfYear = 3)
or (X.dayOfMonth > 30 and X.monthOfYear = 4)
or (X.dayOfMonth > 31 and X.monthOfYear = 5)
or (X.dayOfMonth > 30 and X.monthOfYear = 6)
or (X.dayOfMonth > 31 and X.monthOfYear = 7)
or (X.dayOfMonth > 31 and X.monthOfYear = 8)
or (X.dayOfMonth > 30 and X.monthOfYear = 9)
or (X.dayOfMonth > 31 and X.monthOfYear = 10)
or (X.dayOfMonth > 30 and X.monthOfYear = 11)
or (X.dayOfMonth > 31 and X.monthOfYear = 12)
)."
axiom validHourOfDay
non-functional-properties
dc:description "integrity constraint for valid hourOfDay:"
logical-expression
"invalid (X) <-
X memberOf hourOfDay and
(X < 0 or X > 23)."
axiom validMinuteOfHour
non-functional-properties
dc:description "integrity constraint for valid minuteOfHour:"
logical-expression
"invalid (X) <-
X memberOf minuteOfHour and
(X < 0 or X > 59)."
axiom validSecondOfMinute
non-functional-properties
dc:description "integrity constraint for valid secondOfMinute:"
logical-expression
"invalid (X) <-
X memberOf secondOfMinute and
(X < 0 or X > 59)."
axiom validTime
non-functional-properties
dc:description "integrity constraint for valid time:"
logical-expression
"invalid (X) <-
X memberOf time and
(invalid(X.hourOfDay) or invalid(X.minuteOfHour) or invalid(X.secondOfMinute))."
axiom validDateAndTime
non-functional-properties
dc:description "integrity constraint for valid dateAndTimes:"
logical-expression
"invalid (X) <-
X memberOf dateAndTime and
(invalid(X.date) or invalid(X.time))."
axiom validInterval
non-functional-properties
dc:description "computes if a interval X contains a second interval Y"
logical-expression
"invalid(X) <-
X memberOf interval and X.start < X.end."
axiom equalityDate
non-functional-properties
dc:description "computes equality of a date"
logical-expression
"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
"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 "defined as inverse of beforeDate"
logical-expression
"X > Y <- Y < X"
axiom julianDayNumber
non-functional-properties
dc:description "This Axiom describes how the correct Julian Day Number
can be computed for a given Gregorian Calendar Date. Note
that the Gregorian Calendar was introduced in 15.October 1582.
however until 1919 this axiomatization is not unambiguous since the country
should be taken into to account as 3rd parameter (e.g. Greece
changed at the 9 Mar 1924 from the Julian to the Gregorian calendar).
Details to the axiomatization
If the month is January or February we subtract 1 from the year to get a new Year
and add 12 to the month to get a new Month. (Thus, we are thinking of January and
February as being the 13th and 14th month of the previous year and March is the
start of the year, this simplifies the calculation considering the leap year)
Within the calculation the fractional part of all results has to be dropped,
here we use the function symbol floor() [it can be rewritten as predicate,
however it gets less readable]
A more lengthy description of this axiomatization can be found at
http://quasar.as.utexas.edu/BillInfo/JulianDatesG.html"
dc:source http://quasar.as.utexas.edu/BillInfo/JulianDatesG.html,
http://members.brabant.chello.nl/~h.reints/cal/whenjul2greg.htm
logical-expression
"julianDayNumber(X) = JDN <-
X memberOf date and
((
X.monthOfYear < 3 and
Y = X.year -1 and
M = X.monthOfYear + 12
)
or
(
X.monthOfYear > 2 and
Y = X.year and
M = X.monthOfYear
))
and
D = X.dayOfMonth and
A = floor(Y / 100) and
B = floor(A / 4) and
C = 2 - A + B and
E = floor(365.25 * (Y + 4716)) and
F = floor(30.6001 * (M + 1)) and
JDN = C + D + E + F - 1524."
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
julianDayNumber(D1, JDN_D1) and
julianDayNumber(D2, JDN_D2) and
X = JDN_D1 - JDN_D2."
axiom equalityTime
non-functional-properties
dc:description "computes if two given times are the same"
logical-expression
"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
"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 "defined as inverse of beforeTime"
logical-expression
"X > Y <- Y < X."
axiom secondsFromMidnight
non-functional-properties
dc:description "computes the amount of seconds from midnight"
logical-expression
"secondsFromMidnight(T, X) <-
T memberOf time and
X = 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 = SFM_T1 - SFM_T2."
axiom equalityDateAndTime
non-functional-properties
dc:description "computes if Date and Time are equal"
logical-expression
"X = Y <-
X memberOf dateAndTime and Y memberOf dateAndTime and
X.date = Y.date and
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
"X < Y <-
X memberOf dateAndTime and Y memberOf dateAndTime and
((X.date = Y.date and X.time < Y.time) or
X.date < Y.date)."
axiom afterDateAndTime
non-functional-properties
dc:description "defined as inverse of beforeDateAndTime"
logical-expression
"X > Y <- Y < X."
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
julianDayNumber(D1.date, JDN_D1) and
julianDayNumber(D2.date, JDN_D2) and
secondsFromMidnight(D1.time, SFM_T1) and
secondsFromMidnight(D2.time, SFM_T2) and
X = SFM_T1 + JDN_D1 * 24 * 60 * 60 -
(SFM_T2 + JDN_D2 * 24 * 60 * 60)."
axiom daysBetweenDateAndTime
non-functional-properties
dc:description "the difference in days between two different DateAndTime"
logical-expression
"daysBetween(D1, D2, X) <-
D1 memberOf dateAndTime and D2 memberOf dateAndTime and
daysBetween(D1.date, D2.date, X)."
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
(X.start < Y.start or X.start = Y.start) and
(X.end > Y.end or 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
(X.start < Y or X.start = Y) and
(X.end > Y or X.end = Y)."
|
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). At the current state this is an artificial ontology for modeling
purchases products and payment methods. This should be aligned with existing
ontologies in a later step:
The current Purchase Ontology specified below is a preliminary domain ontology. Redesign will be taken into account for further versions.
ontology http://www.wsmo.org/2004/d3/d3.2/v0.1/20040531/resources/po.wsml
non-functional-properties
dc:title "Purchase ontology"
dc:creator "DERI International"
dc:subject "Buyer", "Seller", "Product", "Price",
"Payment method", "Delivery"
dc:description "General purchose ontology"
dc:publisher "DERI International"
dc:contributor "Michael Stollberg", "Axel Polleres", "Ruben lara",
"Holger Lausen"
dc:date "2004-05-31"
dc:type http://www.wsmo.org/2004/d2/v0.3/20040329/#ontos
dc:format "text/plain"
dc:language "en-US"
dc:relation
http://daml.umbc.edu/ontologies/ittalks/address
http://www.daml.ecs.soton.ac.uk/ont/currency.daml
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040531/resources/dt.wsml
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040531/resources/tc.wsml
dc:coverage "general"
dc:rights http://www.deri.org/privacy.html
version "$Revision: 1.5 $"
namespace
default=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040531/resources/po.wsml#
dc=http://purl.org/dc/elements/1.1
wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418
dt=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040531/resources/dt.wsml
tc=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040531/resources/tc.wsml
ad=http://daml.umbc.edu/ontologies/ittalks/address
cu=http://www.daml.ecs.soton.ac.uk/ont/currency.daml
comment: OO Mediator for using the Date and Time, Train Connection
use-mediator vta-oom-purchaseorder.wsml
conceptDefinitions
concept address subconceptOf ad:address
non-functional-properties
dc:description "Extended address, adding more details to
city, state and country"
city oftype city
state oftype state
country oftype tc:country
concept city subconceptOf tc:location
concept state subconceptOf tc:location
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 cu:currency
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 subconceptOf paymentMethod
non-functional-properties
dc:description "A credit card"
member oftype string
expMonth oftype month
expYear oftype year
type oftype string
concept cash subconceptOf paymentMethod
non-functional-properties
dc:description "Cash payment method"
currency oftype currency
axiomDefinitions
axiom pricePositive
non-functional-properties
dc:description "The price of a trade item has to be positive"
logical-expression
"<-
T memberOf tradeItem[
price hasvalue P]
and P>=0."
instanceDefinitions
comment: A complete list of currencies can be found at
http://www.daml.ecs.soton.ac.uk/ont/currency.daml
|
The "Locations; Ontology defines an ontology of locations, including cities and states. It also defines addresses. This ontology is used by the international train connections and the purchase order ontologies.
ontology http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml
namespace
default=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml#,
dc=http://purl.org/dc/elements/1.1#,
wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418#,
cnt=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/owlFactbookMediator.wsml#,
ad=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/owlAddressMediator.wsml#,
xsd=http://www.w3.org/2001/XMLSchema#
non-functional-properties
dc:title "Locations Ontology"
dc:creator "DERI International"
dc:subject "Location", "Country", "State", "City", "Address"
dc:description "Locations"
dc:publisher "DERI International"
dc:contributor "Ruben Lara", "Axel Polleres"
dc:date "2004-06-03"
dc:type http://www.wsmo.org/2004/d2/v0.3/20040329/#ontos
dc:format "text/plain"
dc:language "en-US"
dc:relation
http://www.daml.org/2001/09/countries/fips-10-4-ont,
http://www.daml.org/2001/09/countries/iso-3166-ont,
http://www.daml.org/2003/09/factbook/factbook-ont,
http://daml.umbc.edu/ontologies/ittalks/address
dc:coverage "ID:7029392 Name:World"
dc:rights http://www.deri.org/privacy.html
version "$Revision: 1.4 $"
usedMediators
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/owlFactbookMediator.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/owlAddressMediator.wsml
conceptDefinitions
concept location
non-functional-properties
dc:description "General notion of location"
name oftype xsd:string
country oftype set country
concept country subconcept cnt:country
non-functional-properties
dc:description "Add the codes to the CIA country properties"
comment: FIPS 10-4 Country Code
fipsCode oftype xsd:string
comment: ISO 3166 Country Code
isoCode oftype xsd:string
concept address subconceptOf ad:address
non-functional-properties
dc:description "Extended address, adding more details to
city, state and country"
city oftype city
state oftype state
country oftype country
concept city subconceptOf tc:location
non-functional-properties
dc:description "City"
state oftype state
population oftype xsd:integer
extension oftype xsd:integer
non-functional-properties
dc:description "Extension of the city in square kilometers"
zipcodes oftype set xsd:string
concept state subconceptOf tc:location
non-functional-properties
dc:description "State"
cities oftype set city
population oftype xsd:integer
extension oftype xsd:integer
instanceDefinitions
comment: "A link to large set of instances is missing in WSMO.
Therefore, in this version of the ontology we only include
some example instances. The inclusion of links to large
set of instances will be considered in future versions of
WSMO"
instance austria memberOf country
fipsCode hasvalue "AU"
isoCode hasvalue "AT"
instance germany memberOf country
fipsCode hasvalue "GM"
isoCode hasvalue "DE"
instance innsbruck memberOf city
name hasvalue "Innsbruck"
country hasvalue austria
instance frankfurt memberOf city
name hasvalue "Frankfurt"
country hasvalue germany
instance boesby memberOf city
name hasvalue "Boesby"
country hasvalue germany
|
Goals denote what a user wants as the result of the Web Service. For modelling 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 our use case, we have one Goal: a user wants to buy a train itinerary from Innsbruck to Frankfurt on a certain date. The 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 5 shows this Goal with the following elements:
goal http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/goal.wsml
namespace
default=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/goal.wsml#,
dc=http://purl.org/dc/elements/1.1#,
dt=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/dt.wsml#,
tc=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/tc.wsml#,
po=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/po.wsml#,
loc=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml#,
wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418/#
non-functional-properties
dc:title "Buying a ticket for a train trip"
dc:creator "DERI International"
dc:subject "Train Tickets", "Online Ticket Booking", "Train trip"
dc:description "Expresses the goal of buying a ticket for a train trip"
dc:publisher "DERI International"
dc:contributor "Michael Stollberg", "Ruben Lara", "Holger Lausen", "Axel Polleres"
dc:date "2004-06-07"
dc:type http://www.wsmo.org/2004/d2/v0.3/20040329/#L3958
comment: MIME type according to [RFC2646,RFC2046]
dc:format "text/plain"
comment: language definition according [RFC3066, ISO639]
dc:language "en-us"
dc:relation
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/dt.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/tc.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/po.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml
dc:coverage "ID:7029392 Name:World"
dc:rights http://deri.at/privacy.html
version "$Revision: 1.7 $"
usedMediators
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/dt.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/tc.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/po.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml
postcondition
axiom buyATicketForItinerary
non-functional-properties
dc:description "The goal postcondition is represented as a fact, in this case the fact is
only specified partly, e.g. for the time of departure the minute and seconds
are not specified.
It represents that 'Tim Berners-Lee' wants to go from innsbruckHbf to frankfurtHbf departing
from innsbruckHbf at 17.07.2004 18h"
logical-expression
"someItinerary memberOf tc:itinerary[
tc:passenger hasvalue _# memberOf prs:person[
prs:firstName hasvalue "Tim",
prs:lastName hasvalue "Berners-Lee",
prs:email hasvalue "timbl@w3.org"
],
tc:trip hasvalue _# memberOf tc:trainTrip[
tc:start hasvalue tc:innsbruckHbf,
tc:end hasvalue tc:frankfurtHbf,
tc:departure hasvalue _# memberOf dt:dateAndTime[
dt:date hasvalue _# memberOf dt:date[
dt:dayOfMonth hasvalue 17,
dt:monthOfYear hasvalue 7,
dt:year hasvalue 2004
]
dt:time hasvalue _# memberOf dt:time[
dt:hourOfDay hasvalue 18
]
]
]
]."
effect
axiom havingTradeForTrip
non-functional-properties
dc:description "The goal effect is represented as a fact
It represents that 'Tim Berners-Lee' wants to have a trade
with a provider (not specified) for the itinerary given;
the ticket should be delivered to his address and he wants
to pay by creditcard"
logical-expression
"someTrade memberOf po:trade[
po:items hasvalues {someItinerary},
po:buyer hasvalue _# memberOf po:buyer[
po:shipTo hasvalue TimsAddress memberOf loc:address[
loc:roomNumber hasvalue "3",
loc:streetAddress hasvalue "Tims street",
loc:city hasvalue loc:boston,
loc:state hasvalue massachusetts,
loc:zip hasvalue "02103"
],
po:billTo hasvalue TimsAddress
],
po:payment hasvalue _#:memberOf po:creditCard[
po:member hasvalue "Tim Berners-Lee",
po:expMonth hasvalue 9,
po:expYear hasvalue 2007,
po:type hasvalue "MasterCard"
]
]."
|
Notice that in the goal, 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.
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 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 Service at this point in time.
A Web Service Capability in WSMO is described by pre- and postconditions, assumptions and effects, as defined in [Roman et al., 2004]. More detailed discussion of the Discovery mechanism of WSMO Goals and Capabilities is provided in section 3.1.3.
webservice http://www.wsmo.org/2004/d3/d3.2/v0.1/20040526/resources/vta-ws1.wsml
namespace
default=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040526/resources/vta-ws1.wsml#
tc=http://www.wsmo.org/2004/d3/d3.2/v0.1/20040531/resources/tc.wsml#
dc=http://purl.org/dc/elements/1.1#
wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418/#
non-functional-properties
dc:title "ÖBB Online Ticket Booking Web Service"
dc:creator "DERI International"
dc:subject
dc:description "web service for booking online train tickets for austria and germany"
dc:publisher "DERI International"
dc:contributor "Michael Stollberg"
dc:date "2004-06-03"
dc:type http://www.wsmo.org/2004/d2/v0.3/20040329/##L3966
comment: MIME type according to [RFC2646,RFC2046]
dc:format "text/plain"
comment: language definition according [RFC3066, ISO639]
dc:language "en-us"
dc:relation http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/tc.wsml,
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/po.wsml
dc:coverage tc:austria, tc:germany
dc:rights http://deri.at/privacy.html
version "1.0"
usedMediators
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040524/resources/vta-oom-ws1.wsml
capability
precondition
axiom CapPrecondition
non-functional-properties
dc:description "the input has to be the buyer information, for which the
purchase intention is in itinerary with start and end locations in Austria
or Germany and the departure date has to be after the current date. In addition,
the payment method has to be a credit card and the expiration date after
the current date."
logical-expression
"inputBuyer memberOf po:buyer[
po:shipTo hasvalue BuyerAddress memberOf loc:address,
po:billTo hasvalue BuyerAddress memberOf loc:address,
po:purchaseIntention hasvalue _# memberOf tc:itinerary[
tc:trip hasvalue _# memberOf tc:trainTrip[
tc:start hasvalue _# memberOf tc:station[
tc:locatedIn hasvalue StartCountry
],
tc:end hasvalue _# memberOf tc:station[
tc:locatedIn hasvalue EndCountry
],
tc:departure hasvalue _# memberOf dt:dateAndTime[
dt:date hasvalue DepartureDate
]
]
],
po:hasPayment Payment memberOf po:creditCard
]
and (StartCountry=tc:austria or StartCountry=tc:germany)
and (EndCountry=tc:austria or EndCountry=tc:germany)
and DepartureDate > currentDate
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
axiom CapPostcondition
non-functional-properties
dc:description "the output of the service is an itinerary with a trainTrip
for which the start and end
locations, and the departure date, are the ones in the precondition.
The constraints on the start and end locations, and on the departure
date, are, therefore, the ones in the precondition"
logical-expression
"outputItinerary memberOf tc:itinerary[
tc:trip hasvalue inputBuyer.purchaseIntention.trip
]."
effect
axiom CapEffect
non-functional-properties
dc:description "there is a trade for the trainTrip specified in the
capability postcondition with the buyer in the precondition."
logical-expression
"effectTrade memberOf po:trade[
po:items hasvalues {outputItinerary},
po:buyer hasvalue inputBuyer,
po:hasPayment hasvalue inputBuyer.payment
]."
interface
non-functional-properties
dc:description "link to Interface of Web Service"
wscinterface http://www.wsmo.org/2004/d3/d3.2/v0.1/200400517/resources/vta-ws1int.wsml
comment: in next version
|
As happened in the modelling of the goal, 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
OO Mediators "connect" ontologies other ontologies or OO Mediators. For our use case, we have defined the following OO Mediators:
ooMediator
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/owlAddressMediator.wsml
namespace
dc=http://purl.org/dc/elements/1.1#,
wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418/#
non-functional-properties
dc:title "OO Mediator importing the OWL Factbook ontology to WSML"
dc:creator "DERI International"
dc:publisher "DERI International"
dc:contributor "Axel Polleres"
dc:date "2004-06-07"
dc:type http://www.wsmo.org/2004/d2/v0.3/20040329/#L3962
dc:format "text/plain"
dc:language "en-us"
dc:rights http://deri.at/privacy.html
version "$Revision: 1.3 $"
sourceComponent
ontology http://daml.umbc.edu/ontologies/ittalks/address/
targetComponent
ontology
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml
mediationService
comment: not yet implemented.
comment: should have a full wsml-webservice description, here we only
comment: give the intended endpoint of the future service
comment: http://138.232.65.151:8080/TranslatorService/OWL2WSML/
comment: This source ontology might overlap with the owl person ontology.
comment: Not yet checked. In case, we should have one mediator importing both
comment: and resolving possible overlaps/conflicts.
|
ooMediator http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/owlCurrencyMediator.wsml
namespace
dc=http://purl.org/dc/elements/1.1#,
wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418/#
non-functional-properties
dc:title "OO Mediator importing the OWL Currency ontology to WSML"
dc:creator "DERI International"
dc:publisher "DERI International"
dc:contributor "Holger Lausen"
dc:date "2004-06-07"
dc:type http://www.wsmo.org/2004/d2/v0.3/20040329/#L3962
dc:format "text/plain"
dc:language "en-us"
dc:rights http://deri.at/privacy.html
version "$Revision: 1.3 $"
sourceComponent
ontology http://www.daml.ecs.soton.ac.uk/ont/currency.daml
targetComponent
ontology http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/po.wsml
mediationService
comment: not yet implemented.
comment: should have a full wsml-webservice description, here we only
comment: give the intended endpoint of the future service
comment: http://138.232.65.151:8080/TranslatorService/OWL2WSML/
|
ooMediator
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/owlFactbookMediator.wsml
namespace
dc=http://purl.org/dc/elements/1.1#,
wsml=http://www.wsmo.org/2004/d16/d16.1/v0.2/20040418/#
non-functional-properties
dc:title "OO Mediator importing the OWL Factbook ontology to WSML"
dc:creator "DERI International"
dc:publisher "DERI International"
dc:contributor "Axel Polleres"
dc:date "2004-06-07"
dc:type http://www.wsmo.org/2004/d2/v0.3/20040329/#L3962
dc:format "text/plain"
dc:language "en-us"
dc:rights http://deri.at/privacy.html
version "$Revision: 1.4 $"
sourceComponent
ontology http://www.daml.org/2003/09/factbook/factbook-ont/
targetComponent
ontology
http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/loc.wsml
mediationService
comment: not yet implemented.
comment: should have a full wsml-webservice description, here we only
comment: give the intended endpoint of the future service
comment: http://138.232.65.151:8080/TranslatorService/OWL2WSML/
|
ooMediator http://www.wsmo.org/2 |