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: 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 principles and the approach for WSMO. Section 3 presents the non functional properties (core properties) of each modelling element of WSMO. Following the philosophy of WSMF, we further refine in the next sections the ontologies (Section 4), goals (Section 5), mediators (Section 6) and web service (Section 7). Section 8 presents the formal language we use for specifying WSMO and Section 9 presents our conclusions and further intentions.
While there are many existing efforts trying to define Web Services as well as Semantic Web Services like OWL-S, BPEL4WS and so on, none of them explicitly states its underlying principles and approaches. Furthermore, none of the approaches follows through from the conceptualization all the way to a formal execution model backed up by an open source implementation.
The WSMO addresses all these deficiencies and is therefore a solution of a different quality, representing the first effort ever addressing the domain of Semantic Web Services completely
Every ontology design is based on principles of the domain that is going to be formally represented. In the following the principles of the WSMO are outlined that guide the ontology design decisions.
While it is possible and tempting to design one big, all encompassing WSMO, this is not followed due to its inherent complexity and difficulty to comprehend. Instead, a layered approach is followed that starts with a basic WSMO, called WSMO-Lite, continues with a mature set of concepts called WSMO-Standard and ends with a full ontology called WSMO-Full.
 |
As Figure 2 shows, the different variants of WSMO include each other, one building on top of the other.
Non functional properties are defined as a set of tuples, where each tuple
consists of a property and it’s value constraint. The core properties
are defined globally, meaning that they can be used for all the modelling
elements of WSMO. They consist of the Dublin Core Metadata Element
Set 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 is 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.In WSMO Ontologies are the key to link consensual real world semantics intended by humans with computers, cf. [Fensel, 2003]. 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. Eventually, we aim at representing ontologies no matter what ontology language is being used for describing them. 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, that 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.
Eventually, there might also be individuals included within an ontology that represent instances of concepts[1].
There are several ways to describe the contents of ontologies by an ontolog [2] 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 [3]:
| ontology[ nonFunctionalProperties => nonFunctionalProperties usedMediators =>> ooMediator conceptDefinitions =>> conceptDefinition relationDefinitions =>> relationDefinition axioms =>> axiom instances =>> instance ] |
non functional properties of an ontology consist of
the core properties described in Section 3.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
(OO-Mediators) for importing ontologies.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.
Furthermore, a concept can have several (possibly none) direct superconcepts as specified by the so-called "is_a"-relation.
When describing the semantics of concepts within some ontology, we favor an 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, then we can defined 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 [McGuinness & van Harmelen, 2003] as well.
Hence, we extract the following abstract description for concepts:
| conceptDefintion[ nonFunctionalProperties => nonFunctionalProperties superConcepts =>> axiom attributes =>> attributeDefintion methods =>> methodDefintion ] |
non functional properties of an ontology consist of
the core properties described in Section 3.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 definition 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, which specifies the extension of some concept in the
ontology in the simplest case;
more sophisticated constraints can be modeled easily.
| attributeDefinition[ nonFunctionalProperties => nonFunctionalProperties rangeDefinition => axiom ] |
non functional properties of an ontology
consist of the core properties described in Section 3.methods [4] that can be invoked on
each instance of a concept and in response return some result value.
A method definition 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, that is not explicitly contained in the set of input parameters. The computed value will then be returned to the invoker.
| methodDefinition[ nonFunctionalProperties => nonFunctionalProperties rangeDefinition => axiom parameters => LIST(parameter) ] |
non functional properties of an ontology
consist of the core properties described in Section 3.A list of the input parameters of the method. Concrete
values for these parameters have to be specified when the method
will be invoked.
A 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.
| parameter[ nonFunctionalProperties => nonFunctionalProperties domainDefinition => axiom ] |
non functional properties of an ontology
consist of the core properties described in Section 3.The second main building block for the specification of an ontology are relations. 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, 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, inverse relationship between two or more relations) will be dealt with in the same way.
| relationDefinition[ nonFunctionalProperties => nonFunctionalProperties parameters => LIST(parameter) ] |
non functional properties of an ontology consist of
the core properties described in Section 3.An axiom is considered to be a logical expression enriched by some extra-logical information.
| axiomDefinition[ nonFunctionalProperties => nonFunctionalProperties defined_by => logicalExpression ] |
non functional properties of an ontology consist of
the core properties described in Section 3.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.
| instance[ nonFunctionalProperties => nonFunctionalProperties instanceOf =>> axiom attributeValues =>> attributeDefinition ] |
non functional properties of an ontology consist of
the core properties described in Section 3.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 =>> axiom effects =>> axiom ] |
non functional properties of a goal consist of the
core properties described in the Section 3 (where,
in this case, an element in the core properties is equivalent to a
goal).Post-conditions in WSMO describe what a web service
returns in response to its input. They define the relation between the
inputs and the outputs.Effects describe the state of the world after the
execution of the service.In this section, we introduce the notion of mediators and
define the elements that are used in the description of a mediator.
We distinguish between four conceptually different mediators:
|
The mediator is defined as follows:
| mediator[ nonFunctionalProperties => nonFunctionalProperties 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) usedMediator => ooMediator reduction => axiom ] wgMediator :: mediator[ sourceComponent => (webService or wgMediator) targetComponent => (goal or wgMediator) usedMediator => ooMediator reduction => axiom ] wwMediator :: mediator[ sourceComponent => (webService or wwMediator) targetComponent => (webService or wwMediator) usedMediator => ooMediator ] |
mediation service points to a goal that declarative
describes the mapping or to a wwMediator that links to a web service[6] 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 discussed:
non functional properties, used mediators,
capability, interfaces and
groundings.
| webService[ nonFunctionalProperties => nonFunctionalProperties usedMediators =>> {ooMediator or ggMediator} capability => capability interfaces =>> interface groundings =>> grounding ] |
The non functional properties of a web service consist of the
core properties described in the appendix A (where, in this case, an element
in the core properties is equivalent to a web service). Besides these
properties, the non functional properties of a web service also include
aspects related to the quality aspect of a web service (QoS):
| nonFunctionalProperties[ performance => performance reliability =>reliability security => security scalability => scalability robustness => robustness accuracy => accuracy transactional => transactional trust => trusty financial => financial networkRelatedQoS => networkRelatedQoS ] |
A capability defines the web service by means of its
functionality, at a certain level of complexity, given by the following
properties:
| capability :: goal capability[ nonFunctionalProperties => nonFunctionalProperties usedMediators => (OO-Mediator or GG-Mediator) preconditions =>> axiom postconditions =>> axiom assumptions =>> axiom effects =>> axiom ] |
non functional properties of a capability consist of
the core properties described in the Section 3
(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 extends the description of the capability to a
higher level of complexity, by introducing the following properties:
| interface[ nonFunctionalProperties => nonFunctionalProperties errors =>> (errorCode or errorDomainConcept) choreography => choreographyDescription compensation => (WW-Mediator or Goal) messageExchange =>> messageExchangePatterns ] |
non functional properties of an interface consist of
the core properties described in the Section 3
(where, in this case, an element in the core properties is equivalent
to an interface).error data: data
indicating problems during the execution. This is represented in terms
of error codes. We classify errors in domain-independent and domain
dependent errors. The domain independent errors are similar to HTTP
errors. The domain dependent errors are considered to be defined in
ontologies (for example a service may return an error Invalid account
number – a domain dependent error, described in a domain
ontology).Choreography defines the sequence and conditions under
which multiple cooperating proxies exchange information in
order to achieve some useful function. 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 WW-Mediators) are supported. In addition,
choreography describes an access to the intermediate
states of the service. Very related to choreography are data and
control flow – both implementing the external accessible part of
the business logic of the web service. Choreography is described using
a choreography language. Rationalized sub-languages of BPEL4WS
or WSCI are candidates for
such a language.message exchange pattern describes the temporal and
causal relationships, if any, of multiple messages exchanged [5].A grounding specifies how to access the service. It has
mainly to do with protocol and message formats, serialization, transport and
addressing. The grounding is a mapping from the abstract specification to a
concrete specification of the elements that describe a service, which are
required for interacting with the service. The abstract elements for which we
need a concrete specification are:
From the conceptual point of view the grounding can link to various sorts
of interface implementations, e.g. WSDL, CORBA, ebXML and others. The W3C
defines web services as a software system offering and interface accessible
over SOAP with machine processable interface description and especially
mentions WSDL. Since the presented ontology is aiming at describing web
services it is reasonable to choose the current standard for such a
description which is WSDL 2.0, a specification language proposal, with strong
industry backing. One error message generated by the service through it's
interface is translated to a fault message in WSDL and a message
exchange in the interface corresponds to a WSDL message exchange pattern.
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 around 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.
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[Fensel, 2000] D. Fensel: Problem solving methods: understanding, description, development, and reuse, Lecture Notes in Artificial Intelligence (LNAI) 1791, Springer, 2000.
[Fowler, 2003] M. Fowler: UML Distilled: A Brief Guide to the Standard Object Modeling Language, Addison-Wesley, 3rd edition, 2003.
[Gruber, 1995] A. Gruber: A translation approach to portable ontology specifications, Knowlegde 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.
[McGuinness & van Harmelen, 2003] D. L. McGuinness and F. van Harmelen: OWL Web Ontology Language Overview, W3C Proposed Recommendation, 15 December 2003. Latest version is available at http://www.w3.org/TR/owl-features/.
[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.
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 project.
[1] Notice that WMSO is based on F-Logic, therefore, not only instances by also concepts and variables can be bound to variables. Therefore it does not suffer from artificial modelling constraints of other languages that often require to model concepts by instances in order to refer to them via variables.
[2] Such an ontology actually represents a metaontology.
[3] The notation used for defining the elements of WSMO is based on F-Logic syntax.
[4] 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 principly based on F-Logic, this is clearly the case.
[5] Quoted from Web Service Architecture, W3C Working Draft 8 August 2003.
[6] 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.