The Web Service Modeling Ontology (WSMO) is an ontology for describing various aspects related to Semantic Web services. This primer is designed to provide the reader with the fundamental knowledge required to use WSMO effectively. It presents the basic concepts of WSMO with respect to the Version 1.1 of the conceptual specification. It describes how to model ontologies, Web services, goals and mediators using the language devised for formalizing WSMO, the Web Services Modeling Language (WSML). Finally, it describes the content and purpose of the other documents in the specification.
The Web Service Modeling Ontology (WSMO) is a conceptual model for describing various aspects related to Semantic Web services. The objective of WSMO and its accompanying efforts is to solve the application integration problem for Web services by defining a coherent technology for Semantic Web services. WSMO takes the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002] as starting point and further refines and extends its concepts. It is developed by the WSMO working group.
Automated discovery, composition, and execution of Web services is not facilitated by a conceptual model alone. Additionally, a formal language is required to write down annotations of Web services according to the conceptual model. Upon descriptions in this language logical inference-mechanisms can be applied. In order to allow appropriate, satisfactorily logic-based reasoning on Semantic Web services, the description language has to provide reasonable expressivity, together with well-defined formal semantics. The Web Services Modeling Language (WSML) is a family of languages which formalizes WSMO. An adjacent goal of WSML is to provide a rule-based language for the Semantic Web. It is developed by the WSML working group, which is a subgroup of the WSMO working group. For a specification of the different WSML variants you can consult [de Bruijn et al., 2005].
Another working group related with WSMO is dedicated to the Web Service Execution Environment (the WSMX working group). The goal of this working group is the development of an execution environment for the dynamic discovery, selection, mediation, invocation and inter-operation of Semantic Web services based on the WSMO specification. WSMX shall provide a reference architecture and implementation for this purpose.
The aim of this primer is to provide an introduction to WSMO and to describe it in sufficient detail to enable the reader to model goals, mediators and Web services. Further, it exemplifies the use and modeling of domain ontologies, which comprise the fourth pillar of WSMO. The target audience are researchers, software engineers and developers, and all other persons interested in and dealing with Semantic Web services. It is the primer's intention to answer questions such as:
The primer is based on the work carried on [Roman et al., 2005], which sets the pillars of the Web Service Modeling Ontology (WSMO), presenting its core elements and the relations among them. All the examples provided throughout the primer are written using WSML. It is not the intention of the primer to provide a complete specification of WSMO: further details can be found by taking a closer look into the remaining documents which are listed in Section 6.
The WSMO Primer is organized as follows: Section 2 introduces the basic concepts and model behind WSMO, together with its principles; Section 3 describes the use case that guides the primer; Section 4 provides an overview of the main elements of WSMO. Some conclusions regarding WSMO usability are drawn in Section 5. Finally, Section 6 presents the WSMO specification. The WSML definitions of the entities used for describing the chosen use case, which are spread throughout the whole document in order to exemplify each entity at a time, are gathered as a unified example in a separate Appendix.
WSMO provides means to describe all relevant aspects of Semantic Web services in a unified manner. Here, we particularly consider all aspects concerning the problems arising in Enterprise Application Integration as relevant. This section describes the approach and basic ideas behind WSMO in order to tackle these problems.
WSMO provides ontological specifications for the core elements of Semantic Web services. In fact, Semantic Web services aim at an integrated technology for the next generation of the Web by combining Semantic Web technologies and Web services, thereby turning the Internet from an information repository for human consumption into a world-wide system for distributed Web computing. Therefore, appropriate frameworks for Semantic Web services need to integrate the basic Web design principles, those defined for the Semantic Web, as well as design principles for distributed, service-orientated computing of the Web. WSMO is therefore based on the following design principles:
WSMO defines the modeling elements for describing several aspects of Semantic Web services based on the conceptual grounding set up in the Web Service Modeling Framework (WSMF) [Fensel and Bussler, 2002], wherein four main components are defined:
WSMO inherits these four top elements, further refining and extending them. Below there is a more detailed description of each of these top-level components of WSMO.
Ontologies represent a key element in WSMO. They serve a twofold purpose: first, defining the formal semantics of the information, and second, linking machine and human terminologies. Ontologies play a key role in the WSMO specification since they provide (domain specific) terminologies for describing the other elements. WSMO specifies the following constituents as part of the description of an ontology: concepts, relations, functions, axioms, and instances of concepts and relations, as well as non-functional properties, imported ontologies, and used mediators. The latter allows to interconnect different ontologies by using mediators that solve terminology mismatches. A more detailed description of the structure of an ontology together with an example of such a description is given in Section 4.1.
Web services connect computers and devices with each other using the standard Web-based protocols to exchange data and combine data in new ways. In terms of WSMO, Web services are mainly defined by their functional behavior which has to be described in order to allow their discovery, invocation, composition, execution, monitoring, mediation and compensation. Their distribution over the Web confers them the advantage of platform independence. Each Web service represents an atomic piece of functionality that can be reused to build more complex ones. In the WSMO specification, Web services are described by means of their non-functional properties, imported ontologies, used mediators, capability and interfaces. A Web service can be described by multiple interfaces, but has one and only one capability. For more detailed information about how to model Web services within WSMO please refer to Section 4.2.
Goals describe aspects related to user desires with respect to the requested functionality as opposed to the provided functionality described in the Web service capability. In WSMO a goal is characterized by a set of non-functional properties, imported ontologies, used mediators, the requested capability and the requested interface. They are described in Section 4.3.
Mediators describe elements that aim to overcome structural, semantic or conceptual mismatches that appear between the different components that build up a WSMO description. Currently the specification counts with four different types of mediators:
More details about the particular use of mediators and the role they play in WSMO are provided in Section 4.4.
In order to introduce the basic concepts and model, a use case from the domain of e-tourism is used throughout the Primer. In this use case, an agent wants to buy a ticket to travel from Innsbruck (Austria) to Venice (Italy) on a certain date. The goal that specifies the intent of buying a ticket for a trip from Innsbruck to Venice is abstracted from this agent desire. A hypothetical Book Ticket Web service, offered by a "Virtual Travel Agency "(VTA), is considered for achieving the goal. This Web service allows to search and buy tickets for itineraries starting in Austria. The only accepted payment method is credit card. For the execution of the transaction, the credit card must be a valid BestBuy or GoldCard (two fictitious credit card brands).
This section explains the WSMO modeling elements, describing their purpose and illustrating how they can be specified. This section is divided in four subsections: Section 4.1 describes ontologies and all the essential components used to define them, Section 4.2 presents Web services, Section 4.3 presents goals and how they are used to specify the functionality required from Web services, and finally Section 4.4 exemplifies the use of mediators which provide the means to bypass interoperability problems among the rest of the elements. The examples presented througout this section are based on the previously presented use case.
A widespread definition of ontology is given in [Gruber, 1993] where an ontology is defined as "a formal explicit specification of a shared conceptualization" . In WSMO, ontologies provide machine-readable semantics for the information used by all actors implied in the process of Web services usage, either providers or requesters, allowing interoperability and information interchange among components. As an example, we present the definition of an ontology used for specifying the "Book Ticket Web Service" described in the use case and for defining a goal that can be solved by this Web service. This ontology is called "Trip Reservation Ontology", since it defines the necessary terminology for describing trip and reservation related information.
A namespace declaration can appear at the beginning of each WSML file. Such a declaration may comprise the default namespace and abbreviations for other used namespaces. Listing 1 starts with the namespace declaration at the top of the WSML file where the "Trip Reservation Ontology" is specified.
Any ontology declaration starts with the keyword ontology
optionally followed by the ontology identifier. A set of non-functional properties
may follow this statement. Non-functional properties can be specified for almost
any WSMO element and they describe information that do not affect the functionality
of the element like title, authorship, copyrights, etc. For each different WSMO
element, there is a recommended set of non-functional properties, but this set
is extensible. The "Trip Reservation Ontology" is characterized by the non-functional
properties that appear in Listing 1.
As it can be noticed, the majority of the recommended non-functional properties are properties defined in the Dublin Core Metadata Element Set. However, their values have types according to the WSMO recommendation:
dc#title has as value the name of the element,
in this case the "Trip Reservation Ontology" . dc#identifier has been defined
following the WSMO recommendation to use an IRI for identifying the element.
In the case of the "Trip Reservation Ontology", the identifier was already
declared, but here is repeated in order to allow Dublin Core metadata aware
applications to process this information. dc#creator has been defined
following the WSMO recommendation to use an instance of the class foaf#agent
defined in the FOAF ontology [FOAF] to indicate unambigously the entity responsible for
creating the content of the element. dc#description has been defined
following the WSMO recommendation, as a free-text description of the content
of the element. dc#publisher has been defined
following the WSMO recommendation to use an instance of the class foaf#agent
defined in the FOAF ontology [FOAF] to indicate unambigously the entity responsible for
publishing the content of the element. dc#contributor has as value
an instance of the class foaf#agent defined in the FOAF ontology
[FOAF] in order to indicate unambigously the entity
responsible for making contributions to the content of the element, as WSMO
recommends. dc#date has been defined following
the WSMO recommendation to encode date values as defined in the ISO standard
8601:2000 [ISO8601]. dc#format has been defined
following the WSMO recommendation to use types defined in the list of Internet
Media Types by
the Internet Assigned Numbers Authority.
dc#language has as value a
language tag defined in the ISO standard 639 [ISO639].dc#rights reference a document
that contains a rights management statement for the element. The only non-functional property declared for this ontology
that is not included in the Dublin
Core Metadata Element Set is wsml#version, its value being
a CVS revision tag, as recommended by WSMO.
namespace {_"http://example.org/tripReservationOntology#",
dc _"http://purl.org/dc/elements/1.1#",
loc _"http://example.org/locationOntology#",
po _"http://example.org/purchaseOntology#",
foaf _"http://xmlns.com/foaf/0.1/",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
prs _"http://example.org/owlPersonMediator#"}
ontology _"http://example.org/tripReservationOntology"
nonFunctionalProperties
dc#title hasValue "Trip Reservation Ontology"
dc#identifier hasValue _"http://example.org/tripReservationOntology"
dc#creator hasValue _"http://example.org/foaf#deri"
dc#description hasValue
"an ontology for describing trip reservations related knowledge"
dc#publisher hasValue _"http://example.org/foaf#deri"
dc#contributor hasValue _"http://example.org/foaf#cristina"
dc#date hasValue _date(2004,12,16)
dc#format hasValue "text/x-wsml"
dc#language hasValue "en-us"
dc#rights hasValue _"http://deri.at/privacy.html"
wsml#version hasValue "$Revision 1.17 $"
endNonFunctionalProperties
importsOntology { _"http://example.org/locationOntology",
_"http://example.org/purchaseOntology"}
usesMediator _"http://example.org/owlPersonMediator"
|
Ontologies are applied in every other WSMO element as domain
specific vocabulary definitions. WSMO allows to import other ontologies into
an ontology either directly, when no conflicts need to be resolved, or indirectly,
by using mediation, which is the process of resolving any conflicts that may
appear through aligning, merging or transforming imported ontologies. In the
first case the imported ontologies are specified by using the keyword importsOntology,
while in the second case the usesMediator statement points to the
mediators, the components that realize the mediation. Mediation may be done
not only between ontologies, but also between other components involved in the
Web service descriptions, the mediators that realize the mediation between ontologies
being named ooMediators. More about the possible types of mediators
can be found in Section 4.4. In the "Trip Reservation Ontology", two ontologies
are imported without any mediation and one mediator is used for importing one
OWL [OWLSemantics] ontology.
The basic blocks of an ontology are concepts, relations, functions, instances, and axioms. The examples provided in the next subsections for each of these elements are taken mostly from the "Trip Reservation Ontology".
Concepts are defined by their subsumption hierarchy
and their attributes, including range specification. The range of the attributes
can be a datatype or another concept. There are two kinds of attribute definitions:
constraining definitions, using the keyword ofType and inferring
definitions using the keyword impliesType. In the first case, the
values of the attribute are constrained to have the mentioned type, while in
the latter, the values of the attribute are inferred to have the mentioned type.
For specifying that an attribute can have any type we can declare its type as
being wsml#true. Like for other WSMO entities, a set of non-functional
properties can be used for specifying additional information about concepts.
Below the definitions of some concepts from the "Trip Reservation Ontology"
are presented, that will be further used for defining other elements of WSMO.
concept trip
origin impliesType loc#location
destination impliesType loc#location
departure ofType _date
arrival ofType _date
concept tripFromAustria subConceptOf trip
nonFunctionalProperties
dc#relation hasValue tripFromAustriaDef
endNonFunctionalProperties
axiom tripFromAustriaDef
definedBy
forall {?x ,?origin}
(?x memberOf tripFromAustria
implies
?x[
origin hasValue ?origin] and
?origin[
loc#locatedIn hasValue loc#austria]
).
concept ticket
provider ofType _string
trip ofType trip
recordLocatorNumber ofType _integer
concept reservationRequest
nonFunctionalProperties
dc#description hasValue "This concept represents a
reservation request for some trip for a particular person"
endNonFunctionalProperties
reservationItem impliesType wsml#true
reservationHolder impliesType prs#person
concept reservation
nonFunctionalProperties
dc#description hasValue "concept of a confirmation for some item"
endNonFunctionalProperties
reservationItem impliesType wsml#true
reservationHolder impliesType prs#person
|
For expressing subsumption relations between concepts the keyword
subConceptOf is used. In the example above, the concept tripFromAustria
is subsumed by the concept trip.
The extension of a concept can be defined or restricted by
one or more logical expressions that specify a necessary and/or a sufficient
condition for an instance to be an element of the extension of the concept.
Such logical expressions are embedded in axioms. It is recommended that the
concept refers to its related axioms by declaring their identifiers as values
for the non-functional property dc#relation. The definition of
the concept tripFromAustria is completed with an axiom, tripFromAustriaDef,
that specifies that a necessary and sufficient condition for an individual to
be an instance of this concept is to have as the values of its origin
attribute the location Austria.
Relations describe interdependencies between a set
of parameters. Optionally, the domain of parameters which can be a datatype
or a certain concept can be specified using the impliesType or
ofType keywords. Thus, a relation declaration comprises the keyword
relation, the identifier of the relation and optionally: its arity,
its superrelations, the domain of its parameters, and a set of non-functional
properties. Axioms can be used for defining/constraining the relation extension.
If there are such axioms, it is recommended to refer to them in the dc#relation
non-functional property.
Below is a relation definition taken from a different ontology,
the "Purchase Ontology", that has a single argument, a credit card,
and holds when the credit card is valid. An axiom is accompanying this relation
that compares the credit card expiry date with the current date for establishing
its validity. For completeness, the definition of the concept creditCard
is also provided, since it is used in the function definition. Note that this
listing makes part from a different WSML file (the file in which the "Purchase
Ontology" is defined) than the file to which the other examples presented
in this section belong (the file in which the "Trip Reservation Ontology"
is defined).
namespace { _"http://example.org/purchaseOntology#",
dc _"http://purl.org/dc/elements/1.1",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
prs _"http://example.org/owlPersonMediator.wsml#"}
ontology _"http://example.org/purchaseOntology"
concept creditCard
owner impliesType prs#person
number ofType _integer
type ofType _string
expiryDate ofType _date
balance ofType _integer
relation validCreditCard(ofType creditCard)
nonFunctionalProperties
dc#description hasValue "Relation that holds for a valid credit card"
dc#relation hasValue ValidCreditCardDef
endNonFunctionalProperties
axiom ValidCreditCardDef
definedBy
forall {?x, ?y} (
validCreditCard(?x) impliedBy
?x[expiryDate hasValue ?y] memberOf creditCard
and
neg (wsml#dateLessThan(?y, wsml#currentDate()))).
|
Functions are a special type of relations that have
a unary range beside the set of parameters. Although in the conceptual model,
they are regarded as distinct entities from relations, in WSML they are modelled
as a special type of relations that have one functional parameter. Besides the
typical declaration for a relation, when declaring a function one must include
an axiom that states the functional dependency. The function ticketPrice
is modeled as a relation with three parameters: the first one is a ticket, the
second one is a currency, while the third one is the result returned by the
function: the price of the ticket in the given currency.
relation ticketPrice(ofType ticket, ofType po#currency, ofType _integer)
nonFunctionalProperties
dc#description hasValue
"Function that returns the price of a ticket in a given currency"
dc#relation hasValue {FunctionalDependencyTripPrice}
endNonFunctionalProperties
axiom FunctionalDependencyTicketPrice
definedBy
!- ticketPrice(?x,?y,?z1) and ticketPrice(?x,?y,?z2) and ?z1 != ?z2 . |
Instances are embodiments of concepts or relations,
being defined either explicitly by specifying concrete values for attributes
or parameters or by a link to an instance store. In the listing below three
instances are presented, the first two being instances of the concepts trip,
respectively ticket, presented in Listing 2, and the third one being an instance of the function
(relation) ticketPrice introduced in Listing 4. Instances explicitly specified in an ontology are those
that are shared together with the ontology. This may be the case for the first
instance, tripInnVen. However, most instance data exists outside
the ontology in private data stores. These private data stores are called instance
stores and they are linked to the ontology. We expect the second and the third
instance which represent the coordinates of a ticket for a trip from Innsbruck
to Venice, respectively the price for that given ticket instance, to reside
in such an instance store, since they are specific to the Web service provider.
For simplicity, here we consider them to be declared in the same file as the
"Trip Reservation Ontology". We will come back at this issue in a
next section.
instance tripInnVen memberOf trip origin hasValue loc#innsbruck destination hasValue loc#venice departure hasValue _date(2005,11,22) arrival hasValue _date(2005,11,22) instance ticketInnVen memberOf ticket provider hasValue "Book Ticket Service" trip hasValue tripInnVen recordLocatorNumber hasValue 93 relationInstance ticketPrice(ticketInnVen, po#euro, 120) |
Axioms are specified as logic expressions and help
to formalize domain specific knowledge. Different WSML variants allow different
expressivities for the logical expressions. For more detail about that, see
the WSML specification. As already described
in the previous sections, they are declared by using the keyword axiom
optionally followed by the axiom identifier, by a set of non-functional properties
and by the logical expression introduced by the keyword definedBy.
A Web service description in WSMO consists of five sub-components: non-functional properties, imported ontologies, used mediators, a capability and interfaces.
In this section we illustrate the declaration of a Web service, by defining the "Book Ticket Web Service" offered by the "Virtual Travel Agency" described in Section 3.
The declaration of a Web service starts with the keyword webService
followed by the identifier of the Web service. After this, it follows the declaration
of the non-functional properties of the Web service. A Web service can import
ontologies either directly, by using the importsOntology statement,
or via oomediators declared in the usesMediator statement.
The "Book Ticket Web Service" imports the "Trip Reservation Ontology".
It must be noted that the Web service has its own instance store linked to this
ontology in which there are instances specific to the Web service like the available
tickets and the prices of those tickets. Below is the definition of this Web
service.
namespace {_"http://example.org/bookTicket#",
dc _"http://purl.org/dc/elements/1.1#",
tr _"http://example.org/tripReservationOntology#",
foaf _"http://xmlns.com/foaf/0.1/",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
bti _"http://www.example.org/BookTicketInterfaceOntology#"}
webService _"http://example.org/bookTicketWebService"
importsOntology _"http://example.org/tripReservationOntology"
capability BookTicketCapability
interface BookTicketInterface |
The capability of a Web service defines its functionality in terms of pre and postconditions, assumptions and effects. A Web service defines one and only one capability. A Web service capability is defined by specifying the next elements: non-functional properties, imported ontologies, used mediators, shared variables, precondition, postcondition, assumption, and effect.
Ontologies may be imported either directly using the keyword
importsOntology or via ooMediators declared in the usesMediator
section.
A capability, therefore a Web service, may be linked to certain
goals that are solved by the Web service via a special type of mediators, named
wgMediators. These links are useful in the Web Service Discovery phase.
WGMediators resolve also terminology mismatches between Web services
and goals. Such mediators are specified in the usesMediator part
of a Web service capability definition.
For declaring the basic blocks of the "Book Ticket Web Service" capability, we will take a closer look at what the Web service offers to a client (postcondition), when some conditions are met in the information space (precondition), and how the execution of the Web service changes the world (effect), given that some conditions over the world state are met before execution (assumption). Preconditions, assumptions, postconditions and effects are expressed through a set of axioms. A set of shared variables can be declared within the capability. These variables are implicitly all-quantified and their scope is the whole Web service capability. Thus, in informal language, the logical interpretation of a Web service capability is: for any values taken by the shared variables, the conjunction of the precondition and of the assumption implies the conjunction of the postcondition and of the effect.
In case of successful execution, the "Book Ticket Web
Service" has as result a reservation that includes the reservation holder
and a ticket for the desired trip (postcondition) if there is a reservation
request for a trip with its starting point in Austria for a certain person (precondition)
and if the credit card intended to be used for paying is a valid one and its
type is either BestBuy or GoldenCard (assumption). As a consequence
of the execution of the Web service, the price of the ticket will be deducted
from the credit card (effect). The shared variables for the "Book
Ticket Web Service" are those that designate the desired trip (the variable
?trip), the reservation holder (the variable ?reservationHolder),
the credit card information (the variable ?creditCard), the initial
balance of the credit card (the variable ?initialBalance) and the
provided ticket (the variable ?ticket). The precondition checks
whether the user request is about a trip whose origin is in Austria. This is
done by checking the membership of the trip value from the user request to the
concept tripFromAustria defined in the "Trip Reservation Ontology".
The assumption uses the relation validCreditCard defined in the
"Purchase Ontology" to see whether the credit card is valid. The postcondition
states that the result of the trip is a reservation that includes a ticket for
the desired trip using the special symbol result. The effect updates
the value of the credit card balance by subtracting the price of the ticket.
The price of the ticket is supposed to be kept in the Web service instance store
as an instance of the function (relation) ticketPrice.
capability BookTicketCapability
sharedVariables {?creditCard, ?initialBalance, ?trip, ?reservationHolder, ?ticket}
precondition
nonFunctionalProperties
dc#description hasValue "The information of a trip which starts in Austria
together with the information about the person who wants to have a reservation
must be given as a part of a reservation request. A credit card is also required."
endNonFunctionalProperties
definedBy
?reservationRequest[
reservationItem hasValue ?trip,
reservationHolder hasValue ?reservationHolder
] memberOf tr#reservationRequest
and
?trip memberOf tr#tripFromAustria and
?creditCard[
balance hasValue ?initialBalance
] memberOf po#creditCard.
assumption
nonFunctionalProperties
dc#description hasValue "The credit card information provided by the
requester must designate a valid credit card that should be either
BestBuy or GoldenCard."
endNonFunctionalProperties
definedBy
po#validCreditCard(?creditCard)
and ( ?creditCard[
type hasValue "BestBuy"]
or
?creditCard[
type hasValue "GoldenCard"]
).
postcondition
nonFunctionalProperties
dc#description hasValue "A reservation containing the details of a ticket for
the desired trip and the reservation holder is the result of the successful
execution of the Web service."
endNonFunctionalProperties
definedBy
?reservation memberOf tr#reservation[
reservationItem hasValue ?ticket,
reservationHolder hasValue ?reservationHolder
]
and
?ticket[
trip hasValue ?trip
]
memberOf tr#ticket.
effect
nonFunctionalProperties
dc#description hasValue "The credit card will be charged with the cost of
the ticket."
endNonFunctionalProperties
definedBy
ticketPrice(?ticket, "euro", ?ticketPrice)
and
?finalBalance= (?initialBalance - ?ticketPrice)
and
?creditCard[
po#balance hasValue ?finalBalance
] .
|
The interface of a Web service provides further information on how the functionality of the Web service is achieved. It contains:
Thus, a Web service interface is defined by specifying the next elements: non-functional properties, imported ontologies, used mediators, choreography, and orchestration.
interface BookTicketInterface importsOntology _"http://www.example.org/BookTicketInterfaceOntology" choreography BookTicketChoreography orchestration BookTicketOrchestration |
The interface of the Web service, more specifically its components, the choreography and the orchestration, are depicted in Figure 1. The next subsections will describe in greater detail each of these two components.
Figure 1. The "Book Ticket Web Service" interface
The choreography specifies the behavior interface for Web service consumption. A user of the Web service has to support this for consuming a Web service. A choreography description has two parts: the state and the guarded transitions. A state is represented by an ontology, while guarded transitions are if-then rules that specify transitions between states.
choreography BookTicketChoreography state _"http://example.org/BookTicketInterfaceOntology" guardedTransitions BookTicketChoreographyTransitionRules |
The ontology that represents the state has a twofold role: first, it provides the vocabulary of the transition rules, and second, it contains the set of instances that change their values from one state to the other. Thus, its content is dynamic. Informally, a state is considered to be the dynamic set of intances at a certain point in time. The concepts, relations and functions of an ontology used for representing a state may have specified one or two additional non-functional properties. These non-functional properties are mode and grounding. The mode of an element gives an indication about who(the Web service and/or the environment) is allowed to modify the extension of the element and in which way (read/write). It can have one of the following values: static (the default value), controlled, in, out, shared. In the case of elements which have the mode in, out or shared, a grounding mechanism should be provided by using the non-functional property grounding. The ontology used for defining the choreography may reuse external ontologies by importing them and redefining the elements for which the specification of the mode is needed, and possibly that of grounding. This is done by declaring similar elements that inherit the definition of the original ones and adding the desired non-functional properties.
In our use case, the ontology used for describing the choreography,
named "Book Ticket Interface Ontology" imports the ontologies "Trip Reservation
Ontology" and "Purchase Ontology", and redefines the concepts reservationRequest,
creditCard and reservation as having the modes in,
in, and out respectively. Two new concepts are defined in
this ontology, temporaryReservation and negativeAcknowledgement
that have the modes controlled and out respectively. An instance
of the first concept will be created in the choreography after receiving a reservation
request and before receiving the credit card information, and an instance of
the second concept will be created as a result of receiving the information
of an invalid credit card. The name of this ontology is "Book Ticket Interface
Ontology" and not "Book Ticket Choreography Ontology", as it would be expected,
because both the choreography and the orchestration of this Web service defined
in the interface "BookTicketInterface" use this ontology.
namespace {_"http://example.org/BookTicketInterfaceOntology#",
dc _"http://purl.org/dc/elements/1.1#",
tr _"http://example.org/tripReservationOntology#",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
po _"http:/example.org/purchaseOntology#"
}
ontology _"http://example.org/BookTicketInterfaceOntology#"
nonFunctionalProperties
dc#title hasValue "Book Ticket Interface Ontology"
dc#creator hasValue "DERI Innsbruck"
dc#description hasValue "an ontology that redefines concepts and
relations from other ontologies in order to reuse them in the
choreography and orchestration; two additional non-functional
properties are defined for the targeted concepts and relations:
mode and grounding"
dc#publisher hasValue "DERI International"
endNonFunctionalProperties
importsOntology { _"http://www.example.org/tripReservationOntology",
_"http://www.wsmo.org/ontologies/purchaseOntology"
}
concept reservationRequest subConceptOf tr#reservationRequest
nonFunctionalProperties
wsml#mode hasValue wsml#in
wsml#grounding hasValue reservationWSDL#reservationRequest
endNonFunctionalProperties
concept reservation subConceptOf tr#reservation
nonFunctionalProperties
wsml#mode hasValue wsml#out
wsml#grounding hasValue reservationWSDL#reservation
endNonFunctionalProperties
concept temporaryReservation subConceptOf tr#reservation
nonFunctionalProperties
wsml#mode hasValue wsml#controlled
endNonFunctionalProperties
concept creditCard subConceptOf po#creditCard
nonFunctionalProperties
wsml#mode hasValue wsml#in
wsml#grounding hasValue reservationWSDL#creditCard
endNonFunctionalProperties
concept negativeAcknowledgement
nonFunctionalProperties
wsml#mode hasValue wsml#out
wsml#grounding hasValue reservationWSDL#negAck
endNonFunctionalProperties
|
The guarded transitions are rules that are triggered when the current state fulfils certain conditions. This is done by checking the values of the attributes of the instances from the state ontology or the existence of certain instances in the state ontology in the current state. When this is the case a transition to a new state is performed, by changing the values of some of the attributes of the instances from the state ontology or by adding new instances to this ontology. The choreography defined in this example has three transition rules.
guardedTransitions BookTicketChoreographyTransitionRules
if (reservationRequestInstance [
reservationItem hasValue ?trip,
reservationHolder hasValue ?reservationHolder
] memberOf bti#reservationRequest
and
?trip memberOf tr#tripFromAustria
and
ticketInstance[
trip hasValue ?trip,
recordLocatorNumber hasValue ?rln
] memberOf tr#ticket
then
temporaryReservationInstance[
reservationItem hasValue ticketInstance,
reservationHolder hasValue ?reservationHolder
] memberOf bti#temporaryReservation
if (temporaryReservationInstance[
reservationItem hasValue ticketInstance,
reservationHolder hasValue ?reservationHolder
] memberOf bti#temporaryReservation
and
creditCardInstance memberOf bti#creditCard
and
po#validCreditCard(creditCardInstance))
then
reservationInstance[
reservationItem hasValue ticketInstance,
reservationHolder hasValue ?reservationHolder
]memberOf bti#reservation
if (temporaryReservationInstance [
reservationItem hasValue ticketInstance,
reservationHolder hasValue ?reservationHolder
] memberOf bti#temporaryReservation
and
creditCardInstance memberOf bti#creditCard
and
neg (po#validCreditCard(creditCardInstance)))
then
negativeAcknowledgementInstance memberOf bti#negativeAcknowledgement |
The first rule checks whether a reservation request instance exists (i.e. it has been already received, since the corresponding concept has the mode in) with the request for a trip that starts in Austria and whether there a ticket instance for the desired trip in the Web service instance store. If this is the case, it creates a temporary reservation for that ticket. The next step is to wait for a credit card information, to check whether it points to a valid credit card and if this is the case to create a reservation instance. This is depicted by the second guarded transition rule. In case the received credit card information points to an invalid credit card, a negative acknowledgement instance is created. This is depicted by the third transition rule.
The orchestration of a WSMO Web service defines how a Web service makes use of other WSMO Web services or goals in order to achieve its capability. Like for the choreography, an orchestration description has two parts: the state and the guarded transitions. A state is represented by an ontology, while guarded transitions are if-then rules that specify transitions between states.
orchestration BookTicketOrchestration state _"http://example.org/BookTicketInterfaceOntology" guardedTransitions BookTicketOrchestrationTransitionRules |
In extention to the choreography, in the orchestration can also appear transition rules that have as postcondition the invocation of a mediator. Such a mediator is used for linking the orchestration with the choreography of a required Web service. This is done either directly, when the required Web service is known (the type of the mediator being wwMediator) or indirectly, via a goal, when the required Web service is not known (the type of the mediator being wgMediator) .
guardedTransitions BookTicketOrchestrationTransitionRules
if (creditCardInstance[
type hasValue "BestBuy"
] memberOf bti#creditCard
and
po#validCreditCard(creditCardInstance))
then
_"http://example.org/BookTicketBestBuyMediator"
if (creditCardInstance[
type hasValue "GoldenCard"
] memberOf bti#creditCard
and
po#validCreditCard(creditCardInstance))
then
_"http://example.org/BookTicketGoldenCardMediator" |
Thus, the orchestration of this Web service is described by
two transition rules. These transition rules specify that when a valid credit
card is received, depending on its type, the appropriate Web service for payment
is invoked. As already described in its capability, this Web service only accepts
BestBuy or GoldenCard credit cards. The invocation of one of the payment Web
services is done using one of the two wwMediators, BookTicketBestBuyMediator
or BookTicketGoldenCardMediator.
A goal specifies objectives that a client might have when consulting a Web service, i.e. functionalities that a Web service should provide from the user perspective. The coexistence of goals and Web services as non-overlapping entities ensures the decoupling between request and Web service. The requester, either human or machine, defines a goal to be resolved and the Web Service Discovery detects suitable Web services for solving the goal automatically. This kind of stating problems, in which the requester formulates objectives independent/ without regard to Web services for resolution is known as the goal-driven approach, derived from the AI rational agent approach.
A goal in WSMO is described by non-functional properties, imported ontologies, used mediators, requested capability and requested interface.
As already described in Section 3, our scenario is that a user wants to buy a ticket from Innsbruck (Austria) to Venice (Italy) on the date of 15 June 2005. A goal is abstracted from this user desire that does not include the desired date for the trip, because this information is not considered relevant in the Web service Discovery phase. Usually, a Web service will not advertise that it sells tickets only for certain dates and since the goal will have to be matched with one or more Web service capabilities, there is no point in making it more complex than any of these Web services capabilities.
A goal declaration starts with the keyword goal
followed by the goal identifier. Optionally a set of non-functional properties
follows, those being defined in a similar fashion with the non-functional
properties for the components already described.
Furthermore, a goal can import existing ontologies to make use of ontological knowledge defined elsewhere, either directly, or via ontology-to-ontology mediators. The goal described above makes use of three ontologies, no mediation being needed. Another type of resources that can be reused within the definition of a goal via mediators are another goals. The mediation between two goals is realized by a type of mediators named goal-to-goal mediators. The relation between a goal and another goal imported via such a mediator is one of refinement. More generic goals are reused by specifying additional constraints. For example, the goal described above, abstracted from the user's desires, can be based on another goal, more generic, that says only that the intent is to have a reservation for a ticket for any trip. For the moment it is not defined how the goal-to-goal mediator achieves its functionality and how the functionality of the generic goal is refined by the concrete goal. When this will be defined, the generic goal will be included in the example and the concrete goal will only reuse this goal.
Below is the definition of the concrete goal previously described:
namespace {_"http://example.org/goals#",
dc _"http://purl.org/dc/elements/1.1#",
tr _"http://example.org/tripReservationOntology",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
loc _"http://www.wsmo.org/ontologies/locationOntology#"}
goal _"http://example.org/havingATicketReservationInnsbruckVenice"
importsOntology {_"http://example.org/tripReservationOntology",
_"http://www.wsmo.org/ontologies/locationOntology"}
capability
postcondition
definedBy
?reservation[
reservationHolder hasValue ?reservationHolder,
item hasValue ?ticket
] memberOf tr#reservation
and
?ticket[
trip hasValue ?trip
] memberOf tr#ticket
and
?trip [
origin hasValue loc#innsbruck,
destination hasValue loc#venice
] memberOf tr#trip.
|
The main element that appears in the declaration of a goal
is the requested capability, which specifies the functionality required
from a Web service. This is declared in the same way as a Web service capability,
by using the keyword capability followed by the actual declaration.
As described in the scenario above, the user expects to find a Web service,
which as a result of its execution offers a reservation for a ticket for the
desired trip. Thus, the only element of the capability the user is interested
in, is its postcondition.
The user has also the possibility to specify the desired way
of interacting with the Web service by declaring the requested interface.
Such a declaration is done using the keyword interface followed
by a declaration of some interface. It is not the case in this example.
The existence of mediators allows one to link possibly heterogeneous resources. Mediators resolve incompatibilities that arise at different levels:
In the general case WSMO defines mediators by means of non-functional properties, imported ontologies, source component, target component and mediation service, where source and target component can be a mediator, a Web service, an ontology or a goal. As it was anticipated in Section 2.2 the current version of the WSMO specification distinguishes among four types of mediators: ooMediators, ggMediators, wgMediators and wwMediators.
OOMediators allow any WSMO component to import an ontology by solving all the terminological mismatches that can appear during the process. Ontology mediation may be done in more than one step, hence the possibility for an ooMediator to mediate between an ontology and another ooMediator. The listing below contains the declaration of the ooMediator used by the "Trip Reservation Ontology" (target) for importing the "OWL Person Ontology" (source).
namespace{_"http://example.org/mediators#",
dc _"http://purl.org/dc/elements/1.1" ,
wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}
ooMediator _"http://example.org/owlPersonMediator"
nonFunctionalProperties
dc#title hasValue "OO Mediator importing the OWL Person ontology to WSML"
dc#creator hasValue _"http://example.org/foaf#deri"
dc#description hasValue "Mediator to import an OWL person ontology into a WSML
trip reservation ontology"
dc#publisher hasValue _"http://example.org/foaf#deri"
dc#contributor hasValue _"http://example.org/foaf#lausen"
dc#language hasValue "en-us"
dc#relation hasValue {_"http://daml.umbc.edu/ontologies/ittalks/person/",
_"http://example.org/tripReservationOntology"}
dc#rights hasValue _"http://www.deri.org/privacy.html"
wsml#version hasValue "$Revision: 1.34 $"
endNonFunctionalProperties
source _"http://daml.umbc.edu/ontologies/ittalks/person/"
target _"http://example.org/tripReservationOntology"
usesService _"http://example.org/OWL2WSML"
|
GGmediators can link a goal to another goal. Like in the case of ontologies, mediation between goals can be done in more than one step, hence the possibility to have ggMediators that have as source or target other ggMediators. The link represents the refinement of the source goal into the target goal, allowing the definition of sub-goal hierarchies. Assuming that for our use case, besides the concrete goal, a generic goal was also defined, as described in Section 4.3, a ggMediator will be used for linking the two goals. This mediator is described in Listing 16. GGMediators can also use ooMediators for resolving terminology mismatches between the vocabularies used for description of goals, but this is not the case for the VTA example.
namespace { _"http://www.example.org/mediators",
dc# _"http://purl.org/dc/elements/1.1#",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}
ggMediator _"http://www.example.org/ggMed"
nonFunctionalProperties
dc#title hasValue "GG Mediator that links the generic goal for
reserving tickets with a concrete goal for reserving a ticket
for a trip from Innsbruck to Venice"
dc#creator hasValue _"http://example.org/foaf#deri"
dc#publisher hasValue _"http://example.org/foaf#deri"
dc#contributor hasValue _"http://example.org/foaf#stollberg"
dc#format hasValue "text/html"
dc#identifier hasValue _"http://example.org/ggmed"
dc#language hasValue "en-us"
dc#relation hasValue {
_"http://example.org/havingATicketReservationInnsbruckVenice",
_"http://example.org/havingATicketReservation"}
dc#rights hasValue _"http://deri.at/privacy.html"
wsml#version hasValue "$Revision: 1.34 $"
endNonFunctionalProperties
source _"http://example.org/havingATicketReservationInnsbruckVenice"
target _"http://example.org/havingATicketReservation"
|
WGMediators are mediators that link Web services to goals. A wgMediator has- depending on which is the source and target of the mediator - one of the following functions: (1) it links a goal to a Web service via its choreography interface meaning that the Web service (totally or partially) fulfills the goal to which it is linked (2) it links a Web service to a goal via its orchestration interface meaning that the Web service needs this goal to be resolved in order to fulfil the functionality described in its capability. A wgMediator can be defined for the VTA use case that links the concrete goal "reserve a ticket for a trip from Innsbruck to Venice"(source) with the Book Ticket Web service(target).
namespace{ _"http://example.org/mediators",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}
wgMediator _"http://example.org/wgMed"
nonFunctionalProperties
dc#title hasValue "WG Mediator that links the Book Ticket Web
service with the goal that specifies the requirement of having a
ticket reservation for a trip from Innsbruck to Venice"
endNonFunctionalProperties
source _"http://example.org/BookTicketWebService"
target _"http://example.org/havingATicketReservationInnsbruckVenice"
|
WWMediators link two Web services in order to enable
interoperability of heterogeneous Web services. In the orchestration of the
"Book Ticket Web Service" two such mediators are used for realizing
the connection with the two Web services for payment, belonging to BestBuy,
respectively GoldenCard. Listing 18 presents the definition
of the BookTicketBestBuyMediator.
namespace{ _"http://example.org/mediators",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}
wwMediator _"http://example.org/BookTicketBestBuyMediator"
nonFunctionalProperties
dc#title hasValue "WWMediator that links the orchestration of the
Book Ticket Web service with the choreography of the BestBuy Web service"
endNonFunctionalProperties
source _"http://example.org/BookTicketWebService"
target _"http://example.org/BestBuyWebService"
|
This document presented how the main elements defined by the WSMO specification, ontologies, goals, Web services and mediators, and their subcomponents can be modeled in WSMO by providing examples for each of them. Due to the core design principles that underpin WSMO, decoupling and mediation, describing the various aspects of Semantic Web services can be done in an efficient and simple way.
For some parts of the specification, like the mediators, the work is in progress. In the future versions, the primer will include more detailed examples for modeling these parts.
This section presents an overview of the documents the WSMO specification consists in. Every deliverable is listed below, together with a brief description of its content. Further, it provides links to the latest final draft, and the latest working draft of each currently available document. At the moment of writing the primer the WSMO specification included the following deliverables:
[Baida et al., 2004] Z. Baida, J. Gordijn, B. Omelayenko and H. Akkermans: A Shared Service Terminology for Online Service Provisioning, ICEC '04: Proceedings of the 6th International Conference on Electronic Commerce, p.1-10, 2004.
[Brickley & Miller, 2004] D. Brickley and L. Miller: FOAF Vocabulary Specification, available at: http://xmlns.com/foaf/0.1/
[de Bruijn et al., 2005] J. de Bruijn, H. Lausen, R. Krummenacher, A. Polleres, L. Predoiu, M. Kifer, and D. Fensel: The Web Service Modeling Language (WSML). Deliverable D16.1v02, WSML, 2005. Available from http://www.wsmo.org/TR/d16/d16.1/v0.2/
[Fensel and Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[IANA] Internet Assigned Numbers Authority. <http://www.isi.edu/in-notes/iana/assignments/media-types/media-types>
[ISO639, 1988] International Organization for Standardization (ISO): ISO 639:1988 (E/F). Code for the Representation of Names of Languages. First edition, 1988-04-01. Reference number: ISO 639:1988 (E/F). Geneva: International Organization for Standardization, 1988.
[ISO8601, 2004] International Organization for Standardization (ISO): ISO 8601:2000. Representation of dates and times. Second edition, 2004-06-08. Reference number. Geneva: International Organization for Standardization, 2004. Available from http://www.iso.org/.
[Patel-Schneider et al., 2004] P. F. Patel-Schneider, P. Hayes, and I. Horrocks: OWL Web Ontology Language Semantics and Abstract Syntax. Recommendation 10 February 2004, W3C, 2004. Available from http://www.w3.org/TR/owl-semantics/.
[Preist, 2004] Chris Preist. A Conceptual Architecture for Semantic Web Services. In Proceedings of the International Semantic Web Conference 2004 (ISWC 2004), November 2004.
[Roman et al., 2005] D. Roman, H. Lausen, U. Keller (eds.): Web Service Modeling Ontology (WSMO). Deliverable D2v1.1, WSMO, 2005. Available from http://www.wsmo.org/TR/d2/v1.1/.
[TGN] Getty Thesaurus of Geographic Names. <http://www.getty.edu/research/tools/vocabulary/tgn/index.html>
[W3CDTF] Date and Time Formats, W3C Note. <http://www.w3.org/TR/NOTE-datetime>
Here you can find the WSML definitions for the entities used to describe the use case that guides the primer. While all these definitions were presented throughout the document, the definitions of certain entities (e.g. the Trip Reservation Ontology) were spread in different listings or interleaved with the definitions of other entities. Hence, the need for this integrated listing.
/*************************************
The Trip Reservation Ontology
************************************/
namespace {_"http://example.org/tripReservationOntology#",
dc _"http://purl.org/dc/elements/1.1#",
loc _"http://example.org/locationOntology#",
po _"http://example.org/purchaseOntology#",
foaf _"http://xmlns.com/foaf/0.1/",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
prs _"http://example.org/owlPersonMediator#"}
ontology _"http://example.org/tripReservationOntology"
nonFunctionalProperties
dc#title hasValue "Trip Reservation Ontology"
dc#identifier hasValue _"http://example.org/tripReservationOntology"
dc#creator hasValue _"http://example.org/foaf#deri"
dc#description hasValue
"an ontology for describing trip reservations related knowledge"
dc#publisher hasValue _"http://example.org/foaf#deri"
dc#contributor hasValue _"http://example.org/foaf#cristina"
dc#date hasValue _date(2004,12,16)
dc#format hasValue "text/x-wsml"
dc#language hasValue "en-us"
dc#rights hasValue _"http://deri.at/privacy.html"
wsml#version hasValue "$Revision 1.17 $"
endNonFunctionalProperties
importsOntology{ _"http://example.org/locationOntology",
_"http://example.org/purchaseOntology"}
usesMediator _"http://example.org/owlPersonMediator"
concept trip
origin impliesType loc#location
destination impliesType loc#location
departure ofType _date
arrival ofType _date
concept tripFromAustria subConceptOf trip
nonFunctionalProperties
dc#relation hasValue tripFromAustriaDef
endNonFunctionalProperties
axiom tripFromAustriaDef
definedBy
forall {?x ,?origin}
(?x memberOf tripFromAustria
implies
?x[
origin hasValue ?origin] and
?origin[
loc#locatedIn hasValue loc#austria]
).
concept ticket
provider ofType _string
trip ofType trip
recordLocatorNumber ofType _integer
concept reservationRequest
nonFunctionalProperties
dc#description hasValue "This concept represents a
reservation request for some trip for a particular person"
endNonFunctionalProperties
reservationItem impliesType wsml#true
reservationHolder impliesType prs#person
concept reservation
nonFunctionalProperties
dc#description hasValue "concept of a confirmation for some item"
endNonFunctionalProperties
reservationItem impliesType wsml#true
reservationHolder impliesType prs#person
relation ticketPrice(ofType ticket, ofType po#currency, ofType _integer)
nonFunctionalProperties
dc#description hasValue
"Function that returns the price of a ticket in a given currency"
dc#relation hasValue {FunctionalDependencyTripPrice}
endNonFunctionalProperties
axiom FunctionalDependencyTicketPrice
definedBy
!- ticketPrice(?x,?y,?z1) and ticketPrice(?x,?y,?z2) and ?z1 != ?z2.
instance tripInnVen memberOf trip
origin hasValue loc#innsbruck
destination hasValue loc#venice
departure hasValue _date(2005,11,22)
arrival hasValue _date(2005,11,22)
instance ticketInnVen memberOf ticket
provider hasValue "Book Ticket Service"
trip hasValue tripInnVen
recordLocatorNumber hasValue 27
relationInstance ticketPrice(ticketInnVen, po#euro, 120)
/*************************************
The Purchase Ontology
************************************/
namespace { _"http://example.org/purchaseOntology#",
dc _"http://purl.org/dc/elements/1.1",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
prs _"http://example.org/owlPersonMediator#"}
ontology _"http://example.org/purchaseOntology"
usesMediator _"http://example.org/owlPersonMediator"
concept creditCard
owner impliesType prs#person
number ofType _integer
type ofType _string
expiryDate ofType _date
balance ofType _integer
relation validCreditCard(ofType creditCard)
nonFunctionalProperties
dc#description hasValue "Relation that holds for a valid credit card"
dc#relation hasValue ValidCreditCardDef
endNonFunctionalProperties
axiom ValidCreditCardDef
definedBy
forall {?x, ?y} (
validCreditCard(?x) impliedBy
?x[expiryDate hasValue ?y] memberOf creditCard
and
neg (wsml#dateLessThan(?y, wsml#currentDate()))).
relationInstance TicketPrice(ticketInnVen, po#euro, 120)
/**********************************************
The Book Ticket Interface Ontology
**********************************************/
namespace {_"http://example.org/BookTicketInterfaceOntology#",
dc _"http://purl.org/dc/elements/1.1#",
tr _"http://example.org/tripReservationOntology#",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
po _"http:/example.org/purchaseOntology#"
}
ontology _"http://example.org/BookTicketInterfaceOntology#"
nonFunctionalProperties
dc#title hasValue "Book Ticket Interface Ontology"
dc#creator hasValue "DERI Innsbruck"
dc#description hasValue "an ontology that redefines concepts and
relations from other ontologies in order to reuse them in the
choreography and orchestration; two additional non-functional
properties are defined for the targeted concepts and relations:
mode and grounding"
dc#publisher hasValue "DERI International"
endNonFunctionalProperties
importsOntology { _"http://www.example.org/tripReservationOntology",
_"http://www.wsmo.org/ontologies/purchaseOntology"
}
concept reservationRequest subConceptOf tr#reservationRequest
nonFunctionalProperties
wsml#mode hasValue wsml#in
wsml#grounding hasValue reservationWSDL#reservationRequest
endNonFunctionalProperties
concept reservation subConceptOf tr#reservation
nonFunctionalProperties
wsml#mode hasValue wsml#out
wsml#grounding hasValue reservationWSDL#reservation
endNonFunctionalProperties
concept temporaryReservation subConceptOf tr#reservation
nonFunctionalProperties
wsml#mode hasValue wsml#controlled
endNonFunctionalProperties
concept creditCard subConceptOf po#creditCard
nonFunctionalProperties
wsml#mode hasValue wsml#in
wsml#grounding hasValue reservationWSDL#creditCard
endNonFunctionalProperties
concept negativeAcknowledgement
nonFunctionalProperties
wsml#mode hasValue wsml#out
wsml#grounding hasValue reservationWSDL#negAck
endNonFunctionalProperties
/*************************************
The Book Ticket Web service
************************************/
namespace {_"http://example.org/bookTicket#",
dc _"http://purl.org/dc/elements/1.1#",
tr _"http://example.org/tripReservationOntology#",
foaf _"http://xmlns.com/foaf/0.1/",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
bti _"http://www.example.org/BookTicketInterfaceOntology#"}
webService _"http://example.org/bookTicketWebService"
importsOntology _"http://example.org/tripReservationOntology"
capability BookTicketCapability
sharedVariables {?creditCard, ?initialBalance, ?trip, ?reservationHolder, ?ticket}
precondition
nonFunctionalProperties
dc#description hasValue "The information of a trip which starts in Austria
together with the information about the person who wants to have a reservation
must be given as a part of a reservation request. A credit card is also required."
endNonFunctionalProperties
definedBy
?reservationRequest[
reservationItem hasValue ?trip,
reservationHolder hasValue ?reservationHolder
] memberOf tr#reservationRequest
and
?trip memberOf tr#tripFromAustria and
?creditCard[
balance hasValue ?initialBalance
] memberOf po#creditCard.
assumption
nonFunctionalProperties
dc#description hasValue "The credit information provided by the requester
must designate a valid credit card that should be either BestBuy
or GoldenCard."
endNonFunctionalProperties
definedBy
po#validCreditCard(?creditCard)
and ( ?creditCard[
type hasValue "BestBuy"]
or
?creditCard[
type hasValue "GoldenCard"]
).
postcondition
nonFunctionalProperties
dc#description hasValue "A reservation containing the details of a ticket for
the desired trip and the reservation holder is the result of the successful
execution of the Web service."
endNonFunctionalProperties
definedBy
?reservation memberOf tr#reservation[
reservationItem hasValue ?ticket,
reservationHolder hasValue ?reservationHolder
]
and
?ticket[
trip hasValue ?trip
]
memberOf tr#ticket.
effect
nonFunctionalProperties
dc#description hasValue "The credit card will be charged with the cost of
the ticket."
endNonFunctionalProperties
definedBy
ticketPrice(?ticket, "euro", ?ticketPrice)
and
?finalBalance= (?initialBalance - ?ticketPrice)
and
?creditCard[
po#balance hasValue ?finalBalance
] .
interface BookTicketInterface
choreography BookTicketChoreography
state _"http://example.org/BookTicketInterfaceOntology"
guardedTransitions BookTicketTransitionRules
guardedTransitions BookTicketChoreographyTransitionRules
if (reservationRequestInstance [
reservationItem hasValue ?trip,
reservationHolder hasValue ?reservationHolder
] memberOf bti#reservationRequest
and
?trip memberOf tr#tripFromAustria
and
ticketInstance[
trip hasValue ?trip,
recordLocatorNumber hasValue ?rln
]memberOf tr#ticket
then
temporaryReservationInstance[
reservationItem hasValue ticketInstance,
reservationHolder hasValue ?reservationHolder
] memberOf bti#temporaryReservation
if (temporaryReservationInstance[
reservationItem hasValue ticketInstance,
reservationHolder hasValue ?reservationHolder
] memberOf bti#temporaryReservation
and
creditCardInstance memberOf bti#creditCard
and
po#validCreditCard(creditCardInstance))
then
reservationInstance[
reservationItem hasValue ticketInstance,
reservationHolder hasValue ?reservationHolder
]memberOf bti#reservation
if (temporaryReservationInstance [
reservationItem hasValue ticketInstance,
reservationHolder hasValue ?reservationHolder
]memberOf bti#temporaryReservation
and
creditCardInstance memberOf bti#creditCard
and
neg (po#validCreditCard(creditCardInstance)))
then
negativeAcknowledgementInstance memberOf bti#negativeAcknowledgement
orchestration BookTicketOrchestration
state _"http://example.org/BookTicketInterfaceOntology"
guardedTransitions BookTicketOrchestrationTransitionRules
if (creditCardInstance[
type hasValue "BestBuy"
] memberOf bti#creditCard
and
po#validCreditCard(creditCardInstance))
then
_"http://example.org/BookTicketBestBuyMediator"
if (creditCardInstance[
type hasValue "GoldenCard"
] memberOf bti#creditCard
and
po#validCreditCard(creditCardInstance))
then
_"http://example.org/BookTicketGoldenCardMediator"
/**************************************************************
The goal of booking a ticket for a trip from Innsbruck to Venice
***************************************************************/
namespace {_"http://example.org/goals#",
dc _"http://purl.org/dc/elements/1.1#",
tr _"http://example.org/tripReservationOntology",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#",
loc _"http://www.wsmo.org/ontologies/locationOntology#"}
/**************************************************************
An example of oomediator
***************************************************************/
namespace{_"http://example.org/mediators#",
dc _"http://purl.org/dc/elements/1.1" ,
wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}
ooMediator _"http://example.org/owlPersonMediator"
nonFunctionalProperties
dc#title hasValue "OO Mediator importing the OWL Person ontology to WSML"
dc#creator hasValue _"http://example.org/foaf#deri"
dc#description hasValue "Mediator to import an OWL person ontology into a WSML
trip reservation ontology"
dc#publisher hasValue _"http://example.org/foaf#deri"
dc#contributor hasValue _"http://example.org/foaf#lausen"
dc#language hasValue "en-us"
dc#relation hasValue {_"http://daml.umbc.edu/ontologies/ittalks/person/",
_"http://example.org/tripReservationOntology"}
dc#rights hasValue _"http://www.deri.org/privacy.html"
wsml#version hasValue "$Revision: 1.34 $"
endNonFunctionalProperties
source _"http://daml.umbc.edu/ontologies/ittalks/person/"
target _"http://example.org/tripReservationOntology"
usesService _"http://example.org/OWL2WSML"
/**************************************************************
An example of ggmediator
***************************************************************/
namespace { _"http://www.example.org/mediators",
dc# _"http://purl.org/dc/elements/1.1#",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}
ggMediator _"http://www.example.org/ggMed"
nonFunctionalProperties
dc#title hasValue "GG Mediator that links the generic goal for
reserving tickets with a concrete goal for reserving a ticket
for a trip from Innsbruck to Venice"
dc#creator hasValue _"http://example.org/foaf#deri"
dc#publisher hasValue _"http://example.org/foaf#deri"
dc#contributor hasValue _"http://example.org/foaf#stollberg"
dc#format hasValue "text/html"
dc#identifier hasValue _"http://example.org/ggmed"
dc#language hasValue "en-us"
dc#relation hasValue {
_"http://example.org/havingATicketReservationInnsbruckVenice",
_"http://example.org/havingATicketReservation"}
dc#rights hasValue _"http://deri.at/privacy.html"
wsml#version hasValue "$Revision: 1.34 $"
endNonFunctionalProperties
source _"http://example.org/havingATicketReservationInnsbruckVenice"
target _"http://example.org/havingATicketReservation"
/**************************************************************
An example of wgmediator
***************************************************************/
namespace{ _"http://example.org/mediators",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}
wgMediator _"http://example.org/wgMed"
nonFunctionalProperties
dc#title hasValue "WG Mediator that links the Book Ticket Web
service with the goal that specifies the requirement of having a
ticket reservation for a trip from Innsbruck to Venice"
endNonFunctionalProperties
source _"http://example.org/BookTicketWebService"
target _"http://example.org/havingATicketReservationInnsbruckVenice"
/**************************************************************
An example of wwmediator
***************************************************************/
namespace{ _"http://example.org/mediators",
wsml _"http://www.wsmo.org/wsml/wsml-syntax#"
}
wwMediator _"http://example.org/BookTicketBestBuyMediator"
nonFunctionalProperties
dc#title hasValue "WWMediator that links the orchestration of the
Book Ticket Web service with the choreography of the BestBuy Web service"
endNonFunctionalProperties
source _"http://example.org/bookTicketWebService"
target _"http://example.org/BestBuyWebService"
The work is funded by the European Commission under the projects DIP, Knowledge Web, InfraWebs, SEKT, SWWS, ASG and Esperonto; by Science Foundation Ireland under the DERI-Lion project; by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW² and TSC.
The editor would like to thank to all the members of the WSMO working group for their advices and inputs to this document.