This document is also available in non-normative PDF version.
Copyright © 2004 DERI®, All Rights
Reserved. DERI liability,
trademark, document use, and software licensing rules apply.
This document presents an ontology called Web Service Modeling Ontology (WSMO) for describing various aspects related to Semantic Web Service. Having the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002] as a starting point, we refine this framework and develop a formal ontology and a formal language.
The WSMF [Fensel & Bussler, 2002] consists of four different main elements (see Figure 1): ontologies that provide the terminology used by other elements, goal repositories that define the problems that should be solved by web services, web services descriptions that define various aspects of a web service and mediators which bypass interoperability problem.
 |
Section 2 presents the non functional properties of the modeling elements of WSMO. Following the philosophy of WSMF, we further refine in the next sections the ontologies (Section 3), goals (Section 4), mediators (Section 5) and web service (Section 6). Section 7 presents the formal language we use for specifying WSMO Standard and Section 8 presents our conclusions and further intentions.
Non functional properties are defined as a set of tuples,
where each tuple consists of a property and its value constraint. We classify
non functional properties in two categories: core properties and web service
specific properties.
The core properties are defined globally, meaning that they can be used
for all the modeling elements of WSMO Standard. They consist of the Dublin Core Metadata Element
Set [Weibel et al.] plus the version
element:
| nonFunctionalProperties[ title => title creator => creator subject => subject description => description publisher => publisher contributor => contributor date => date type => type format => format identifier => identifier source => source language => language relation => relation coverage => coverage rights => rights version => version ] |
title will be a
name by which the element is formally known.creator include a person, an
organization, or a service. Typically, the name of a
creator should be used to indicate the entity.subject will be expressed as keywords, key phrases or
classification codes that describe a topic of the element. Recommended
best practice is to select a value from a controlled vocabulary or
formal classification scheme.description include, but are not limited to: an abstract,
table of contents, reference to a graphical representation of content
or a free-text account of the content.publisher include a person, an organization, or a service.
Typically, the name of a publisher should be used to
indicate the entity.contributor include a person, an
organization, or a service. Typically, the name of a
contributor should be used to indicate the entity.date will be associated with the creation or availability
of the element.Type includes terms describing general categories,
functions, genres, or aggregation levels for content.format may include the media-type or dimensions of the
element. Format may be used to identify the software, hardware, or
other equipment needed to display or operate the element. Examples of
dimensions include size and duration.source element
in whole or in part. Recommended best practice is to identify the
referenced element by means of a string or number conforming to a
formal identification system.coverage will include spatial location (a place name or
geographic coordinates), temporal period (a period label, date, or date
range) or jurisdiction (such as a named administrative entity).rights will contain a rights management statement for the
element, or reference a service providing such information. Rights
information often encompasses Intellectual Property Rights (IPR),
Copyright, and various Property Rights. If the Rights element is
absent, no assumptions may be made about any rights held in or over the
element.Besides the core properties described in the previous
section, the web service specific non functional
properties also include properties related to the quality aspect of a
web service (QoS):
| nonFunctionalPropertiesWS ::
nonFunctionalProperties nonFunctionalPropertiesWS[ performance => performance reliability => reliability security => security scalability => scalability robustness => robustness accuracy => accuracy transactional => transactional trust => trust financial => financial networkRelatedQoS => networkRelatedQoS ] |
In WSMO Ontologies are the key to link consensual real world semantics intended by humans with computers. Originating from field of philosophy, in AI the term “ontology” refers to a description of a part of the world in a program – a domain of discourse. An important definition of ontology, used by many researchers in the field of ontologies was introduced by Gruber [Gruber, 1993]: An ontology is a formal explicit specification of a shared conceptualization. Respecting this definition, WSMF defines the two essential aspects of ontologies as follows:
From this rather conceptual definition we want to extract the essential components which define an ontology. Ontologies define a consensual terminology by providing concepts and relationships among the set of concepts. In order to capture semantic properties of relations and concepts, an ontology generally also provides a set of axioms, which means expressions in some logical framework, for instance First-Order Logic.
Each element that belongs to the established terminology, i.e. concepts and relations, can be further constrained semantically by means of a logical constraint that expresses some sort of real-world semantics related to this element.
There are several ways to describe the contents of ontologies by an ontology [1] itself. For now, we decide to keep the model as simple as possible and represent each element of an ontology as simple as possible.
In principle, an ontology constitutes of four main building blocks:
concepts, relations, axioms and
instances. An ontology is defined as follows [2]:
| ontology[ nonFunctionalProperties => nonFunctionalProperties usedMediators =>> ooMediator axioms =>> axiomDefinition concepts =>> conceptDefinition relations =>> relationDefinition instances =>> instanceDefinition ] |
non functional properties of an ontology consist of
the core properties described in Section 2.1.Imported ontologies allow a
modular approach for ontology design. By importing other ontologies,
one can make use of concepts and relations defined elsewhere.
Nevertheless, when importing an arbitrary ontology, most likely some
steps for aligning, merging and transforming imported ontologies have
to be performed. For this reason and in line with the basic design
principles underlying the WSMF, we use ontology mediators (ooMediators)
for importing ontologies.An axiomDefinition is considered to be a logical expression
enriched by some extra-logical information.
| axiomDefinition[ nonFunctionalProperties => nonFunctionalProperties defined_by => logicalExpression ] |
non functional properties of an axiom consist of the
core properties described in Section 2.1.Concepts constitute the basic elements of the consensual
terminology for some problem domain. They provide an abstract view on
real-existing and artificial artifacts within the addressed domain of
discourse.
From a high-level perspective, a concept – described by a concept
definition – provides attributes with names and types. It has a name,
can be textually described in natural language and might change over time and
thus has a version (they are part of the non functional properties of the
concept).
Furthermore, a concept can have several (possibly none) direct super-concepts as specified by the so-called "is_a"-relation.
When describing the semantics of concepts within some ontology, we favor a uniform and rather general approach: we consider the semantics to be captured by means of a logical expression.
For instance, this allows us to state that some concept represents the union or intersection of two or more other concepts. Consider an ontology on social structures within a human society, and then we can define concepts like “Human-being” or “Female” and accurately describe the semantics of the concept “Granny” as precisely the intersection of the concepts “Human-being”, “Female” and “Parent of some parent”.
Such modeling styles are commonly used in many Description Logics [Baader et al., 2003] and can be found in widely-used ontology languages like OWL [Dean et al., 2004] as well.
Hence, we extract the following abstract description for concepts:
| conceptDefinition :: axiomDefinition conceptDefinition[ superConcepts =>> conceptDefinition attributes =>> attributeDefintion methods =>> methodDefintion ] |
superConcepts for some concept. attributes that represent named slots for data values and
instances that have to be filled at the instance level. An attribute
specifies a slot of a concept by fixing the name of the slot as well as
a logical constraint on the possible values filling that slot. Hence,
this logical expression can be interpreted as a typing constraint.
| attributeDefintion :: axiomDefinition attributeDefintion[ range => axiomDefinition ] |
methods [3] that can be invoked on
each instance of a concept and in response return some result value.
A method specifies a function that can be invoked on a specific instance of a concept. When invoking the function, one has to specify the values of the parameters, for which the function has to be computed. The specific instance, for which the method is invoked, can be seen as an implicit input parameter of the function, which is not explicitly contained in the set of input parameters. The computed value will then be returned to the invoker.
| methodDefintion :: axiomDefinition methodDefintion[ range => axiomDefinition parameters => LIST(parameterDefinition) ] |
parameter is a named placeholder for some value.
This concept is used in the definition of methods as well as in
the definition of n-ary relations.
| parameterDefinition ::
axiomDefinition parameterDefinition[ domain => axiomDefinition ] |
Relations are used in order to model interdependencies
between several concepts (respectively instances of these concepts) with
respect to the problem domain.
Relations between concepts are more general than simple
attributes or properties as for instance in OWL. Mathematically,
relationships are simply sets of n-tuples, over the domain of instances of
concepts. In popular and commonly used system modeling languages like UML [Fowler, 2003] such concrete tuples are often called links.
The underlying semantics of cardinalities in the case of n-ary relations
follows the definition in the UML framework [Rumbaugh et
al., 1998].
Relations can be very specific in nature and only applicable
in the context of a particular problem domain, but there are also relations
that occur frequently when modeling ontologies for different application
areas. There are several common properties that modeled relations can
provide, e.g. symmetry, transitivity, and reflexivity. Again, for the sake of
simplicity we decide not to represent these common properties of
relationships currently within the metaontology explicitly but implicitly by
means of axioms.
Other dependencies between relationships (for instance subset, intersection, union, difference, and inverse relationship between two or more relations) will be dealt with in the same way.
| relationDefinition :: axiomDefinition relationDefinition[ parameters => LIST(parameterDefinition) ] |
parameter descriptions specifying each of the
concepts that are interrelated.Eventually, within an ontology there might be instances
defined for some concept. Therefore we have to reflect the
“instance_of”-relation that can be given within an ontology
specification.
| instanceDefinition :: axiomDefinition instanceDefinition[ instanceOf =>> conceptDefinition attributeValues =>> attributeValueDefinition ] |
| attributeValueDefinition ::
axiomDefinition attributeValueDefinition[ value => axiomDefinition ] |
In this section, we introduce the notion of goals and define
the elements that are used in the description of a goal. Our definition of a
goal is the one given in [Fensel & Bussler, 2002]: A
goal specifies the objectives that a client may have when he consults a web
service.
In [Fensel & Bussler, 2002], a goal specification consists of two elements, namely:
WSMO restricts the definition of goals to Post-conditions. In addition,
the Web Services Modeling Ontology introduces non functional
properties, used mediators, and effects.
| goal[ nonFunctionalProperties => nonFunctionalProperties usedMediators =>> {ooMediator or ggMediator} postConditions =>> axiomDefintion effects =>> axiomDefinition ] |
non functional properties of a goal consist of the
core properties described in the Section 2.1
(where, in this case, an element in the core properties is equivalent
to a goal).Post-conditions in WSMO describe the state of the
information space that is desired.Effects describe the state of the world that is
desired.In this section, we introduce the notion of mediators and
define the elements that are used in the description of a mediator.
We distinguish four different types of mediators that can be classified
into two different classes (cf. [Fensel et al., 2003]):
refiners and bridges (see Figure
3 below).
Refiners can be used to define a new component as a
refinement of an existing component. Refiners support reuse by
minimizing the effort in generating new components from existing ones. In
WSMO, we have two refiners:
In addition to refiners, WSMO introduces the notion of
bridges. Bridges support reuse by enabling two
components to interact with each other that would otherwise not cooperate due
to interoperability problems in terms of functionality mismatch, data
mismatch, protocol, or process mismatch. In WSMO, we have two
bridges:
|
Figure 4 below illustrates the relation between different types of mediators, goals, web services and ontologies.
|
The mediator is defined as follows:
| mediator[ nonFunctionalProperties => nonFunctionalPropertiesWS sourceComponent =>> (ontology or goal or webService or mediator) targetComponent =>> (ontology or goal or webService or mediator) mediationService => (goal or wwMediator) ] ooMediator :: mediator[ sourceComponent =>> (ontology or ooMediator) ] ggMediator :: mediator[ sourceComponent => (goal or ggMediator) targetComponent => (goal or ggMediator) usedMediators =>> ooMediator reduction => axiomDefinition ] wgMediator :: mediator[ sourceComponent => (webService or wgMediator) targetComponent => (goal or wgMediator) usedMediators =>> ooMediator reduction => axiomDefinition ] wwMediator :: mediator[ sourceComponent => (webService or wwMediator) targetComponent => (webService or wwMediator) usedMediators =>> ooMediator ] |
mediation service points to a goal that declarative
describes the mapping or to a wwMediator that links to a web service[4] that actually implements the mapping.In this section we identify the concepts needed for describing various
aspects of a web service. From a complexity point of view of the description
of a web service, the following properties of a web service are considered:
non functional properties, used mediators,
capability and interfaces.
| webService[ nonFunctionalProperties => nonFunctionalPropertiesWS usedMediators =>> ooMediator capability => capability interfaces =>> interface ] |
non functional properties of a web service are
described in Section 2.2.capability of a web service is described in Section 6.1.interfaces of a web service are described in Section 6.2.A capability defines the web service by means of its
functionality.
| capability[ nonFunctionalProperties => nonFunctionalProperties usedMediators =>> (ooMediator or wgMediator) preconditions =>> axiomDefinition postconditions =>> axiomDefinition assumptions =>> axiomDefinition effects =>> axiomDefinition ] |
non functional properties of a capability consist of
the core properties described in the Section 2.1
(where, in this case, an element in the core properties is equivalent
to a capability).Pre-conditions in WSMO describe what a web service
expects for enabling it to provide its service. They define conditions
over the input.Post-conditions in WSMO describe what a web service
returns in response to its input. They define the relation between the
input and the output.Assumptions are similar to pre-conditions, however, also
reference aspects of the state of the world beyond the actual
input.Effects describe the state of the world after the
execution of the service.The purpose of defining again pre-conditions, post-conditions, assumptions, effects, non functional properties and used mediators in the service capability is to have self-contained web service descriptions, that can be referred or not to the defined goals. In this way, we provide greater flexibility for the use of goals and web services.
An interface describes how the functionality of the service
can be achieved (i.e. how the capability of a service can be
fulfilled) by providing a twofold view on the operational competence of the
service:
Choreography decomposes a capability in terms of
interaction with the service (service user's view)Orchestration decomposes a capability in terms of
functionality required from other services (other service providers'
view)With this distinction we provide different decompositions of
process/capabilities to the top (service requester) and to the bottom (other
service providers). This distinction reflects the difference between
communication and cooperation. The choreography defines how to
communicate with the web service in order to consume its functionality. The
orchestration defines how the overall functionality is achieved
by the cooperation of more elementary service providers. One could argue that
orchestration should not be part of a public interface because
it refers to how a service is implemented. However, this is a short-term view
that does not reflect the nature of fully open and flexible eCommerce. Here
companies shrink to their core processes were they are really profitable in.
All other processes are sourced out and consumed as eServices. They advertise
their services in their capability and choreography description and they
advertise their needs in the orchestration interfaces. This enables
on-the-fly creation of virtual enterprises in reaction to demands from the
market place. Even in the dinosaurian time of eCommerce where large companies
still exist, orchestration may be an important aspect. The
orchestration of a service may not be made public but may be
visible to the different departments of a large organization that compete for
delivering parts of the overall service. Notice that the actual business
intelligence of a service provider is still hidden. It is his capability to
provide a certain functionality with a chorography that is very different
from the sub services and their orchestration. The ability for a certain type
of process management (the overall functionality is decomposed differently in
the choreography and the orchestration) is where he
comes in as a Silver bullet in the process. How he manages the difference
between the process decomposition at the choreography and the
orchestration level is the business intelligence of the web
service provider. The firewall that is depictured in Figure 5 between
choreography and orchestration refers to the actual
implementation of the web service and its underlying process mediation
aspect.
|
An interface is defined by the following properties:
| interface[ nonFunctionalProperties => nonFunctionalProperties usedMediators =>> ooMediator choreography => instantiatedCMEP orchestration => instantiatedPSP ] |
non functional properties of an interface consist of
the core properties described in the Section
2.1.Choreography provides the necessary information for the
user to communicate with the web service (i.e. it describes how the
service works and how to access the service from the user's
perspective). A choreography achieves this by
instantiating a Message Exchange Pattern (MEP) for the
given capability of a web service. A message exchange
pattern specifies a sequence of conditional speech acts that
either send or receive communication symbols (messages in our case). In
between the communication ask, non-specified actions are defined.
State-less MEPs model stimulus-response patterns (i.e. the
behavioral point of view) and state-based MEPs model
conversations (i.e. the modern cognitive science point of view). A
choreography instantiates a generic communication pattern.
That means:
choreography decomposes the capability of a web
service capability into sub-capabilities. These sub-capabilities
are used to define the generic activities in a
MEP.The choreography in WSMO is further defined in Deliverable 14: Choreography
in WSMO[5].
Orchestration describes how the service works from the
provider's perspective (i.e. how a service makes use of other web
service or goals in order to achieve its capability).
An orchestration describes how the service works by
instantiating a Problem Solving Pattern (PSP) for the
given capability of a web service. A problem solving
pattern specifies a sequence of conditional activities. Again, a
description can be state-less or state-based. An
orchestration instantiates a generic cooperation pattern.
That means:
orchestration decomposes the capability of a web
service into sub-capabilities. These sub-capabilities are used to
define the activities in a PSP. It specifies a set of proxies that
the service uses in order to fulfill its functionality. A
proxy is defined as being either a goal or a
wwMediator. Proxies are used when a web service invokes other web
services in order to provide its service. Each time a web service
needs to be invoked, a proxy needs to be declared (by either
declaring a goal or linking it to a wwMediator). This way, both
dynamic (on the fly) composition (by declaring proxies consisting
of goals descriptions) and static composition (by linking proxies
to wwMediators) are supported.The orchestration in WSMO is further defined in Deliverable 15: Orchestration
in WSMO[5].
As shown in the previous sections, many properties of goals, mediators, ontologies and web services are considered to be axioms, defined by logical expressions. In order to be as specific as possible, we consider these logical expressions as being described in F-Logic [Kifer et al., 1995], by complex formulas.
F-Logic combines the advantages of conceptual high-level approaches typical for frame-based language and the expressiveness, the compact syntax, and the well defined semantics from logics. Features of F-Logic include: object identity, methods, classes, signatures, inheritance and rules.
The reasons for which we choose F-Logic to represent logical expressions are:
For a detailed description of F-Logic refer to [Kifer et al., 1995]. Furthermore, an evaluation of F-Logic and comparison to other languages is given in [Keller et al., to appear].
This document presented the Web Service Modeling Ontology (WSMO) for describing several aspects related to web services, by refining the Web Service Modeling Framework (WSMF). Further versions of this document will contain more detailed descriptions of some concepts presented here as well as refinements that add concepts to the current ontology.
WSMO is centered on the underlying technology to be described. The next step is to define a layer on top in terms of the application that is supported by it: fully flexible eCommerce and eWork.
[Baader et al., 2003] F. Baader, D. Calvanese, and D. McGuinness: The Description Logic Handbook, Cambridge University Press, 2003.
[Dean et al., 2004] M. Dean, G. Schreiber, S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, and L. A. Stein: OWL Web Ontology Language Reference, W3C Recommendation, 10 February 2004. Available at http://www.w3.org/TR/2004/REC-owl-ref-20040210/.
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[Fensel et al., 2003] D. Fensel, E. Motta, F. van Harmelen, V.R. Benjamins, S. Decker, M. Gaspari, R. Groenboom, W. Grosso, M. Musen, E. Plaza, G. Schreiber, R. Studer, and B. Wielinga: The Unified Problem-solving Method Development Language UPML, Knowledge and Information Systems(KAIS) journal, Vol. 5, No. 1, 2003.
[Fowler, 2003] M. Fowler: UML Distilled: A Brief Guide to the Standard Object Modeling Language, Addison-Wesley, 3rd edition, 2003.
[Gruber, 1993] T. Gruber: A translation approach to portable ontology specifications,Knowledge Acquisition, 5:199-220, 1993.
[Keller et al., to appear] U. Keller, A. Polleres, R. Lara, and Y. Ding: Language Evaluation and Comparison, to appear.
[Rajesh & Arulazi, 2003] S. Rajesh and D. Arulazi: Quality of Service for Web Services-Demystification, Limitations, and Best Practices, March 2003. (See http://www.developer.com/services/article.php/2027911.)
[Rumbaugh et al., 1998] J. Rumbaugh, I. Jacobson, and G. Booch: The Unified Modeling Language Reference Manual, Object Technology Series, Addison-Wesley, 1998.
[Weibel et al. 1998]S. Weibel, J. Kunze, C. Lagoze, and M. Wolf: RFC 2413 - Dublin Core Metadata for Resource Discovery, September 1998.
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto, COG and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program.
The editors would like to thank to all the members of the WSMO working group for their advice and input into this document.
[1] Such an ontology actually represents a metaontology.
[2] The notation used for defining the elements of WSMO is based on F-Logic syntax.
[3] It’s obvious, that this additional modeling element for describing ontologies only makes sense, if the logical framework underlying WSMO allows one to define and use methods within axioms. Since WSMO is principally based on F-Logic, this is clearly the case.
[4] Notice that the capability of this web service will also provide a declarative description of this mapping; however, in addition a link to an implementation of the mapping is provided, too.
[5] The grounding of a web service (i.e. the mapping from the abstract specification to a concrete specification of the elements that describe a web service, which are required for interacting with the service) will be specified in the choreography and orchestration, as they are the only elements where grounding is needed.