The Web Service Modeling Ontology (WSMO) is an ontology for describing various aspects related to Semantic Web Services. The 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, 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, by defining a coherent technology for Semantic Web services. As stated in the WSMO Mission Statement, the WSMO solution to the integration problem is characterized by simplicity, completeness (solves all aspects of the integration problem) and executability (a set of execution semantics exists as well as a reference implementation). WSMO 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. WSML (Web Service Modeling Language) is a family of languages that formalizes the Web Service Modeling Ontology (WSMO). An adjacent goal of WSML is to provide a a rule-based language for the Semantic Web. It is developed by the WSML working group, which is a WSMO subgroup. For a specification of the different WSML variants you can consult [de Bruijn et al., 2004].
Another working group related with WSMO is WSMX. 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 primer is based on the work carried on [Roman et al., 2004], 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.
The WSMO specification takes as starting point the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002] as starting point and further refines and extends its concepts.
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:
It is not the primer intention 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.
The main design principles of WSMO derived from WSMF are summarized as follows:
The main design principles of WSMO derived from WSMF are summarized as follows:
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 refines and extends this framework, the four top level elements of the ontology being: ontologies, goals, services and mediators. The major difference between WSMO and WSMF is that instead of Web services, WSMO more generally introduces services as a top element in its specification. Services represent descriptions of services that could be requested by service requesters, provided by service providers or agreed upon by both parties[Priest, 2004].
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, and axioms, 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.
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, 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 service represents an atomic piece of functionality that can be reused to build more complex ones. In the WSMO specification, Services are described by means of their non-functional properties, imported ontologies, used mediators, capability and interfaces. A service can be described by multiple interfaces, but has one and only one capability. For more detailed information about how to model 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 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 from Innsbruck to Venice is abstracted from this agent desire. A hypothetical Book Ticket Service, offered by a Virtual Travel Agency (VTA), is considered for achieving the goal. This 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 services, Section 4.3 presents goals and how they are used to specify the functionality required from 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] who defined an ontology 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 Service described in the use case and for defining a goal that can be solved by this 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, a lot of these 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 "International Train Connections 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 [Brickley&Miller,
2004] 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 [Brickley&Miller,
2004] 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 [Brickley&Miller,
2004] 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,
2004]. 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 [IANA]. dc#language has as value a language tag defined
in the ISO standard 639 [ISO639, 1988].dc#right reference a document that contains a
rights management statement for the element. The only used property 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.
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 services description, the mediators that realize the mediation between
ontologies being identified by the keyword ooMediator. 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 [Patel-Schneider et al., 2004] 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.
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 some 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).
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 given itinerary in the given currency.
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 two instances are presented, the first one being an instance of
the concept trip presented in Listing 2, the second one being an instance of the function (relation)
validCreditCard 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 instance wich
represents the price for a given ticket instance(ticketInnVen)
to reside in such an instance store, since it is specific to the service provider.
We will come back at this issue in a next section.
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 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 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 service, by defining the Book Ticket Service offered by the Virtual Travel Agency described in Section 3.
The declaration of a service starts with the keyword
webService followed by the identifier of the service. After this,
it follows the declaration of the non-functional properties of the service.
A service can import ontologies either directly, by using the importsOntology
statement, or via ontology-to-ontology mediators declared in the usesMediator
statement. The Book Ticket Service imports the Trip Reservation Ontology. It
must be noted that the service has its own instance store linked to this ontology
in which there are instances specific to the service like the available tickets
and the prices of those tickets. Bellow is the definition of this service.
The capability of a service defines its functionality in terms of pre and postconditions, assumptions and effects. A service defines one capability. A 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 service, may be linked
to certain goals that are solved by the service via a special type of mediators,
named wgMediators. These links are useful in the Service Discovery
phase. WgMediators resolve also terminology mismatches between services
and goals. Such mediators are specified in the usesMediator part
of a service capability definition.
For declaring the basic blocks of the Book Ticket Service capability, we will take a closer look at what the service offers to a client (postcondition), when some conditions are met in the information space (precondition), and how the execution of the 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 service capability. Thus, in informal language, the logical interpretation of a 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
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 service, the price of the ticket will be deducted from
the credit card (effect). The shared variables for the Book Ticket
Service are those that designate the desired trip (the variable ?trip),
the reservation holder (the variable ?reservationHolder), its 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 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 service
instance store as an instance of the function (relation) ticketPrice.
The interface of a service provides further information on how the functionality of the service is achieved. It comprises the description of the communication pattern that allows to consume the functionality, named choreography, and the description of how the overall functionality is achieved by means of cooperation of different service providers, named orchestration. Thus, a service interface is defined by specifying the next elements: non-functional properties, imported ontologies, used mediators, choreography, and orchestration.
The choreography and the orchestration that comprise this interface are depicted in Figure 1. The next subsections will describe in greater detail each of these two components.
 |
The choreography specifies the behavior interface for service consumption. A user of the service has to support this for consuming a 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.
The ontology that represents the state provides at the same time the vocabulary of the transition rules as well as 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 is allowed to modify the extension of the element (the service and/or the environment) 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 instance 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
service defined in the interface "BookTicketInterface"
use this ontology.
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.
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 is a ticket for the desired trip in the 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 the 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 service defines how a service makes use of other WSMO 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.
In extention to the choreography, in the orchestration transition rules that have as postcondition the invocation of a mediator can also appear. Such a mediator is used for linking the orchestration with the choreography of a required service. This is done either directly, when the required service is known (the type of the mediator being wwMediator) or indirectly, via a goal, when the required service is not known (the type of the mediator being wgMediator) .
Thus, the orchestration of this 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 payment service is
invoked. As already described in the capability of the service, this service
only accepts BestBuy or GoldenCard credit cards. The invocation of one of the
payment services is done using one of the two wwMediators, BestBuyPaymentMediator
or GoldenCardPaymentMediator.
A goal specifies objectives that a client might have when consulting a service, i.e. functionalities that a service should provide from the user perspective. The coexistence of goals and services as non-overlapping entities ensures the decoupling between request and service. The requester, either human or machine, defines a goal to be resolved and the Service Discovery detects suitable services for solving the goal automatically. This kind of stating problems, in which the requester formulates objectives independent/ without regard to 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 June 15th 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 Service Discovery phase. Usually, a 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 service capabilities, there is no point in making it more complex than any of these service 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:
The main element that appears in the declaration
of a goal is the requested capability, which specifies the functionality
required from a service. This is declared in the same way as a service capability,
by using the keyword capability followed by the actual declaration.
As described in the scenario above, the user expects to find a service, which
as a result of its execution offfers 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 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 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.
Ontology-to-ontology mediators 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).
A goal-to-goal mediator 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 another 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 17. 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.
WGMediators are mediators that link services to goals. A wgMediator can - depending on which is the source and target of the mediator - have two different functions: (1) A goal is linked to a service via its choreography interface meaning that the service (totally or partially) fulfills the goal to which it is linked (2) A service links to a goal via its orchestration interface meaning that the 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 Innsbruk to Venice"(source) with the Book Ticket Service(target).
namespace{ _"http://example.org/mediators",
wsml _"http://www.wsmo.org/wsml-syntax#"
}
|
WWMediators link two services in order
to enable interoperability of heterogeneous services. In the orchestration of
the Book Ticket Service two such mediators are used for realizing the connection
with the two payment services, belonging to BestBuy, respectively GoldenCard.
Listing 19 presents the definition of the BestBuyPaymentMediator.
This document presented how the main elements defined by the WSMO specification, ontologies, goals, services and mediators, and their subcomponents can be modeled in WSMO by providing examples for each of them. Due to the 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:
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#",
xsd _"http://www.w3.org/2001/XMLSchema#",
foaf _"http://xmlns.com/foaf/0.1/",
wsml _"http://www.wsmo.org/2004/wsml#",
prs _"http://example.org/owlPersonMediator.wsml#"}
ontology _"http://example.org/tripReservationOntology"
nonFunctionalProperties
dc#title hasValue "Trip Reservation Ontology"
dc#identifier hasValue _"http://example.org/tripReservationOntology"
dc#creator hasValue _"http://www.deri.org/foaf#deri"
dc#description hasValue "an ontology for describing trip reservation related knowledge"
dc#publisher hasValue _"http://www.deri.org/foaf#deri"
dc#contributor hasValue _"http://homepage.uibk.ac.at/~c703240/foaf.rdf"
dc#date hasValue "2004-12-16"
dc#type hasValue _"http://www.wsmo.org/2004/d2/#ontology"
dc#format hasValue "text/x-wsml"
dc#language hasValue "en-us"
dc#rights hasValue _"http://deri.at/privacy.html"
version hasValue "$Revision 1.17 $"
endNonFunctionalProperties
importsOntology { _"http://example.org/locationOntology",
_"http://www.wsmo.org/ontologies/purchaseOntology"}
usesMediator _"http://example.org/owlPersonMediator.wsml"
concept trip
origin impliesType loc#location
destination impliesType loc#location
departure ofType xsd#dateTime
arrival ofType xsd#dateTime
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 reservationRequest
nonFunctionalProperties
dc#description hasValue "This concept represents a reservation request
for some trip for a particular person (represented by foaf:agent)"
endNonFunctionalProperties
reservationItem impliesType true
reservationHolder impliesType prs#person
concept reservation
nonFunctionalProperties
dc#description hasValue "concept of a confirmation for some item"
endNonFunctionalProperties
reservationItem impliesType true
reservationHolder impliesType prs#person
instance tripInnsbruckVenice memberOf trip
origin hasValue loc#innsbruck
destination hasValue loc#venice
departure hasValue _date("2005-06-15")
arrival hasValue _date("2005-06-15")
/*************************************
The Purchase Ontology
************************************/
namespace {_"http://example.org/purchaseOntology#",
dc _"http://purl.org/dc/elements/1.1#",
xsd _"http://www.w3.org/2001/XMLSchema#",
foaf _"http://xmlns.com/foaf/0.1/",
wsml _"http://www.wsmo.org/2004/wsml#",
prs _"http://example.org/owlPersonMediator.wsml#"}
ontology _"http://example.org/purchaseOntology#"
concept creditCard
owner impliesType prs#person
expiryDate ofType xsd#dateTime
balance ofType xsd#integer
relation ValidCreditCard/2
nonFunctionalProperties
dc#description hasValue "Function that checks whether a credit card is valid or not"
dc#relation hasValue {ValidCreditCardDef, FunctionalDependenceValidCreditCard}
endNonFunctionalProperties
axiom ValidCreditCardDef
definedBy
forall ?x, ?y (
validCreditCard(?x, ?y, ?z) equivalent
?x[expiryDate hasValue ?z] memberOf creditCard and
?y = true impliedBy neg (wsml#date\-less\-than(?z, wsml#current\-date()))
or
?y = false impliedBy wsml#date\-less\-than(?z, wsml#current\-date())
).
axiom FunctionalDependencyValidCreditCard
definedBy
forall ?x,?y1,?y2 (
false impliedBy ValidCreditCard(?x,?y1) and
(ValidCreditCard(?x,?y2) and ?y1 != ?y2)) .
/**********************************************
The Book Ticket Choreography Ontology
**********************************************/
namespace {_"http://example.org/BookTicketChoreographyOntology#",
dc _"http://purl.org/dc/elements/1.1#",
xsd _"http://www.w3.org/2001/XMLSchema#",
tr _"http://example.org/tripReservationOntology#",
wsml _"http://www.wsmo.org/2004/wsml#",
reservationWSDL _"http://example.org/WSDLreservation#",
po _"http:/example.org/purchaseOntology#"
}
ontology _"http://example.org/BookTicketChoreographyOntology#"
nonFunctionalProperties
dc#title hasValue " Trip Reservation Choreography Ontology"
dc#creator hasValue "DERI Innsbruck"
dc#description hasValue "an ontology for that redefines concepts from other
ontologies in order to use them in the choreography by defining for those
two additional non-functional properties: 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#
endNonFunctionalProperties
/*************************************
The Book Ticket Service
************************************/
namespace {_"http://example.org/bookTicket#",
dc _"http://purl.org/dc/elements/1.1#",
tr _"http://example.org/tripReservationOntology#",
vta _"http://example.org/VTAOntology#",
btc _"http://example.org/bookTicketChoreographyOntology#"
xsd _"http://www.w3.org/2001/XMLSchema#",
foaf _"http://xmlns.com/foaf/0.1/",
wsml _"http://www.wsmo.org/2004/wsml#"}
webService "http://example.org/bookTicketService"
importsOntology {_"http://example.org/tripReservationOntology",
_"http://example.org/VTAOntology"
}
capability BookTicketCapability
sharedVariable ?creditCard, ?trip, ?reservationHolder
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 memberOf po#creditCard.
assumption
nonFunctionalProperties
dc#description hasValue "The credit information provided by the requester must designate a valid credit
card. The function validCreditCard is used for evaluating whether a credit card is valid. "
endNonFunctionalProperties
definedBy
po#validCreditCard(?creditCard, true).
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 service."
endNonFunctionalProperties
definedBy
result[
reservationItem hasValue ?trip,
reservationHolder hasValue ?reservationHolder
]memberOf tr#reservation.
effect
nonFunctionalProperties
dc#description hasValue "The credit card will be charged with the cost of the trip."
endNonFunctionalProperties
definedBy
vta#tripPrice(?trip, ?tripPrice) and
?creditCard[
po#balance hasValue@pre ?initialBalance
]and
?finalBalance hasValue (?initialBalance-?tripPrice)
and
?creditCard[
po#balance hasValue ?finalBalance
] .
interface BookTicketInterface
choreography BookTicketChoreography
state _"http://example.org/BookTicketChoreographyOntology"
guardedTransitions BookTicketTransitionRules
if (reservationRequestInstance[
reservationItem hasValue ?trip,
reservationHolder hasValue ?reservationHolder
]memberOf btc#reservationRequest
and
?trip memberOf tr# tripFromAustria
then
temporaryReservationInstance[
reservationItem hasValue ?trip,
reservationHolder hasValue ?reservationHolder
]memberOf btc#temporaryReservation
if (temporaryReservationInstance[
reservationItem hasValue ?trip,
reservationHolder hasValue ?reservationHolder
]memberOf btc#temporaryReservation
and
creditCardInstance memberOf btc#creditCard
and
po#validCreditCard(creditCardInstance, true))
then
reservationInstance [
reservationItem hasValue ?trip,
reservationHolder hasValue ?reservationHolder
]memberOf btc#reservation
if (temporaryReservationInstance[
reservationItem hasValue ?trip,
reservationHolder hasValue ?reservationHolder
]memberOf btc#temporaryReservation
and
creditCardInstance memberOf btc#creditCard
and
po#validCreditCard(creditCardInstance, false))
then
negativeAcknowledgementInstance memberOf btc#negativeAcknowledgement
orchestration BookTicketOrchestration
/**************************************************************
The goal of booking a ticket from Innsbruck to Venice
***************************************************************/
namespace {_"http://example.org/goals#",
dc _"http://purl.org/dc/elements/1.1#",
tr _"http://example.org/tripReservation",
xsd _"http://www.w3.org/2001/XMLSchema#",
wsml _"http://www.wsmo.org/2004/wsml#",
loc _"http://www.wsmo.org/ontologies/location"}
goal _"http://example.org/havingATripReservationInnsbruckVenice"
importsOntology _"http://example.org/tripReservationOntology"
capability
postcondition
definedBy
?result[
reservationHolder hasValue ?reservationHolder,
trip hasValue ?trip
] memberOf tr#reservation
and
?trip [
origin hasValue loc#innsbruck,
destination hasValue loc#venice
] memberOf tr#trip.
/**************************************************************
An ontology-to-ontology mediator
***************************************************************/
namespace{ _"http://example.org/mediators#",
dc _"http://purl.org/dc/elements/1.1" ,
wsml _"http://www.wsmo.org/2004/wsml#",
}
ooMediator _"http://example.org/owlPersonMediator.wsml"
nonFunctionalProperties
dc#title hasValue "OO Mediator importing the OWL Person ontology to WSML"
dc#creator hasValue _"http://www.deri.org/foaf#deri"
dc#description hasValue "Mediator to import an OWL person ontology into a WSML trip reservation ontology"
dc#publisher hasValue _"http://www.deri.org/foaf#deri"
dc#contributor hasValue _"http://www.deri.org/foaf#lausen"
dc#date hasValue "2004-08-30"
dc#type hasValue _"http://www.wsmo.org/2004/d2/#ooMediator"
dc#identifier hasValue _"http://example.org/owlPersonMediator.wsml"
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"
version hasValue "$Revision: 1.14 $"
endNonFunctionalProperties
source _"http://daml.umbc.edu/ontologies/ittalks/person/"
target _"http://example.org/tripReservationOntology"
useService _"http://138.232.65.151:8080/TranslatorService/OWL2WSML"
/**************************************************************
A goal-to-goal mediator
***************************************************************/
namespace { _"http://www.example.org/mediators",
dc# _"http://purl.org/dc/elements/1.1#",
wsml _"http://www.wsmo.org/2004/wsml#"
}
ggMediator _"http://www.example.org/ggMed"
nonFunctionalProperties
dc#title hasValue "GG Mediator that links the a generic goal for reserving trips with
a concrete goal for reserving a trip from Innsbruck to Venice"
dc#creator hasValue _"http://www.deri.org/foaf#deri"
dc#publisher hasValue _"http://www.deri.org/foaf#deri"
dc#contributor hasValue _"http://www.deri.org/foaf#stollberg"
dc#date hasValue "2004-10-04"
dc#type hasValue _"http://www.wsmo.org/2004/d2/#ggMediator"
dc#format hasValue "text/html"
dc#identifier hasValue _"http://www.example.org/ggmed"
dc#language hasValue "en-us"
dc#relation hasValues {_"http://example.org/havingATripReservationInnsbruckVenice" ,
_"http://example.org/havingATripReservation"}
dc#rights hasValue _"http://deri.at/privacy.html"
version hasValue "$Revision: 1.14 $"
endNonFunctionalProperties
source _"http://example.org/havingATripReservationInnsbruckVenice"
target _"http://example.org/havingATripReservation"
/**************************************************************
A Webservice-to-goal mediator
***************************************************************/
namespace{ _"http://example.org/mediators",
wsml _"http://www.wsmo.org/2004/wsml#"
}
ggMediator _"http://example.org/wgMed"
nonFunctionalProperties
dc:title hasValue "WG Mediator that links the Book Ticket Service with the concrete"
endNonFunctionalProperties
source _"http://example.org/bookTicketService"
target _"http://example.org/havingATripReservationInnsbruckVenice"
[Brickley & Miller, 2004] D. Brickley and L. Miller: FOAF Vocabulary Specification, available at: http://xmlns.com/foaf/0.1/
[de Bruijn et al., 2002] J. de Bruijn, D. Foxvog, H. Lausen, E. Oren, D. Roman and D. Fensel: The WSML Family of Representation Languages. Deliverable D16.0v02, WSML, 2004. http://www.wsmo.org/2004/d16/d16.0/v0.2/20040926/
[Fensel and Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[Gruber, 1993] Thomas R. Gruber, "A Translation Approach to Portable Ontology Specifications", Knowledge Acquisition, 5:199-220, 1993.
[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/.
[Roman et al., 2004] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology - Standard (WSMO - Standard), version 1.0. Available from http://www.wsmo.org/2004/d2/v02/.
[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>
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, and SWWS; by Science Foundation Ireland under the DERI-Lion project; and by the Austrian government under the CoOperate programm.
The editor would like to thank to all the members of the WSMO working group for their advices and inputs to this document.