This document is also available in a non-normative PDF version.
Note: This version of the document is compliant with the W3C
submission of WSMO in April 2005.
This document presents an ontology called Web Service Modeling Ontology (WSMO) for describing various aspects related to Semantic Web Services. Taking the Web Service Modeling Framework (WSMF) as a starting point, we refine and extend this framework, and develop an ontology and a description language.
This document presents an ontology called Web Service Modeling Ontology (WSMO) for describing various aspects related to Semantic Web Services. Taking the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002] as a starting point, we refine and extend this framework, and develop a formal ontology and language. WSMF [Fensel & Bussler, 2002] consists of four different main elements for describing semantic Web Services: (1) ontologies that provide the terminology used by other elements, (2) goals that define the problems that should be solved by Web Services, (3) Web Services descriptions that define various aspects of a Web Service, and (4) mediators which bypass interoperability problems.
WSMO provides ontological specifications for the core elements of Semantic Web services. In fact, Semantic Web services aim at an integrated technology for the next generation of the Web by combining Semantic Web technologies and Web services, thereby turning the Internet from a information repository for human consumption into a world-wide system for distributed Web computing. Therefore, appropriate frameworks for Semantic Web services need to integrate the basic Web design principles, those defined for the Semantic Web, as well as design principles for distributed, service-orientated computing of the Web. WSMO is therefore based on the following design principles:
This document is organized as follows: Section 2 describes the meta-model structure and language used for defining WSMO based on the Meta-Object Facilities (MOF). We introduce the top level elements of WSMO in Section 3, which are then further refined: Section 4 outlines ontologies, Section 5 discusses Web service descriptions, Section 6 explains WSMO goals, and Section 7 defines mediators. Section 8 defines the syntax of the logical language that is used in WSMO. The semantics and computationally tractable subsets of this logical language are defined and discussed by the WSML working group. Section 9 presents our conclusions and suggestions for further work.
Finally, the appendix provide an overview of the complete WSMO conceptual model in MOF-style (in Appendix A) as well as in the form of UML Class Diagrams (in Appendix B.)
For a more explanatory document on WSMO we refer to the WSMO Primer [Feier, 2004]. For a non-trivial use case demonstrating how to use WSMO in a real-world setting we refer to the WSMO Use Case Modeling and Testing [Stollberg et al., 2004] and for the formal representation languages we refer to The WSML Family of Representation Languages [De Bruijn, 2004].
Besides the WSMO working group there are two more working groups involved in the WSMO initiative: The WSML working group focusing on language issues and developing an adequate Web Service Modeling Language with various sublanguages, and the WSMX working group that is concerned with designing and building a reference implementation of an execution environment for WSMO.
Note: The vocabulary defined by WSMO is fully extensible.
It is based on URIs with optional fragment identifiers (URI references, or
URIrefs) [Berners-Lee et al, 1998]. URI references are
used for naming all kinds of things in WSMO. The default namespace of this
document is wsmo:http://www.wsmo.org/2004/d2/.
Furthermore this document uses the following namespace abbreviations:
dc:http://purl.org/dc/elements/1.1#,
xsd:http://www.w3.org/2001/XMLSchema#,
and foaf:http://xmlns.com/foaf/0.1/.
Note: "Web Service" and "Service" are used interchangeably in this document; they are meant to represent systems designed to support interoperable machine-to-machine interactions over the Internet.
In this section we introduce the language used to define WSMO. Besides the Meta-Model Layers (Section 2.1) we explain the use of identifiers (Section 2.2) and data type values (Section 2.3). Section 2.4 describes a set of annotations used in the definition of different WSMO elements.
WSMO is a meta-model for Semantic Web Services related aspects. The Meta-Object Facility (MOF) [OMG, 2002] specification is used to specify this model. MOF defines an abstract language and framework for specifying, constructing, and managing technology neutral meta-models.
MOF defines a metadata architecture consisting of four layers, namely:
In terms of the four MOF layers,
The most frequently used MOF meta-modeling construct in the definition of WSMO is the Class construct (and implicitly its class-generalization sub-Class construct), together with its Attributes, the type of the Attributes and their multiplicity specifications. When defining WSMO, the following assumptions are made:
For describing the WSMO conceptual model we will use MOF-style listings throughout this document, using the Class, sub-Class Attributes and type keywords. Note that, for better readability we additionally provide a graphical illustration of the the conceptual model of WSMO in the form of UML class diagrams in Appendix B.
Every WSMO element is identified by one of the following identifiers:
WSMO is based on the principle of identifying entities using Web identifiers (called Uniform Resource Identifiers [Berners-Lee et al, 1998]). Everything in WSMO is by default denoted by an URI, except when it classifies itself as Literal, Variable or Anonymous Id. Using URIs does not limit WSMO from making statements about things that are not accessible on the Web, like with the URI: "urn:isbn:0-520-02356-0" that identifies a certain book. URIs can be expressed as follows: full URIs: e.g. http://www.wsmo.org/2004/d2/ or qualified Names (QNames) that are resolved using namespace declarations. For more details on QNames, we refer to [Bray et al., 1999].
Anonymous IDs can be numbered (_#1, _#2, ...) or
unnumbered (_#). They represent identifiers. The same
numbered Anonymous Id represents the same identifier within the same
scope (logical expression), otherwise Anonymous IDs represent different
identifiers [Yang & Kifer, 2003]. Anonymous IDs
can be used to denote objects that exists, but do not need a specific
identifier (e.g. if someone wants to say that a Person John has an
address _# which itself has a street name "hitchhikerstreet" and a street
number "42", then the object of the address itself does not need a
particular URI, but since it must exist as a connecting object between
John and "hitchhikersstreet" and "42" we can denote it with an Anonymous
Id).The concept of anonymous IDs is similar to blank nodes in RDF [Hayes, 2004], however there are some differences.
Blank Nodes are essentially existential quantified variables, where the
quantifier has the scope of one document. RDF defines different
strategies for the union of two documents (merge and union), whereas the
scope of one Anonymous Id is a logical expression and the semantics of
Anonymous IDs do not require different strategies for a union of two
documents respectively two logical expressions. Furthermore Anonymous IDs
are not existentially quantified variables, but constants. This allows
two flavors of entailment: "Strict" and "relaxed", where the relaxed
entailment is equivalent to the behavior of blank nodes and the strict
entailment allows an easier treatment within implementations.
In WSMO, literals are used to identify values such as numbers by means of a lexical representation. Literals are either plain literals or typed literals. A literal can be typed by a XML data type (e.g. to xsd:integer). Formally, such a data type d is defined by [Hayes, 2004]:
Furthermore the data type may introduce facets on its value space, such as
ordering, and therefore define the axiomatization for the relations
<, >, and function symbols like
+ or -. These special relations and functions are
called data type predicates and are defined in more detail in the WSML Family of
Representation Languages [De Bruijn, 2004].
Annotations are used in the definition of WSMO elements. We recommend most elements of [Weibel et al., 1998]. The listing below presents a set of general annotations which can be applied to any WSMO element.
Class annotation
hasContributor type dc:contributor
hasCoverage type dc:coverage
hasCreator type dc:creator
hasDate type dc:date
hasDescription type dc:description
hasFormat type dc:format
hasIdentifier type dc:identifier
hasLanguage type dc:language
hasOwner type owner
hasPublisher type dc:publisher
hasRelation type dc:relation
hasRights type dc:rights
hasSource type dc:source
hasSubject type dc:subject
hasTitle type dc:title
hasType type dc:type
hasVersion type version
|
dc:contributor include a person, an
organization, or a Web service. The Dublin Core specification
recommends that typically the name of a dc:contributor
should be used to indicate the entity.foaf:Agent as value type [Brickley &
Miller, 2004].dc: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).dc:creator include a person, an
organization, or a Web service. The Dublin Core specification
recommends that typically the name of a dc:creator should
be used to indicate the entity.foaf:Agent as value type [Brickley &
Miller, 2004].dc:date will be associated with the creation or
availability of the element.dc: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.dc: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.dc:identifier in order to allow Dublin Core meta data
aware applications the processing of that information.dc:publisher include a person, an organization, or a Web
service. The Dublin Core specification recommends that typically the
name of a dc:publisher should be used to indicate the
entity.foaf:Agent as value type [Brickley &
Miller, 2004].dc:rights will contain a rights management statement for
the element or reference a Web 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.dc: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.dc: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.dc:title will be
a name by which the element is formally known.dc:type includes terms describing general categories,
functions, genres, or aggregation levels for content.WSMO refers to the concepts it defines as "elements". The listing below presents a general definition which applies to every element defined in WSMO. As we shall see in the subsequent sections, each element refines this definition.
Class wsmoElement
hasAnnotation type annotation
|
Following the main elements identified in the Web Service Modeling Framework, WSMO identifies four top level elements as the main concepts which have to be described in order to describe Semantic Web services.
Ontologies provide the terminology used by other WSMO elements to describe the relevant aspects of the domains of discourse; they are described in detail in Section 4.
Web services describes the computational entity providing access to services that provide some value in a domain. These descriptions comprise the capabilities, interfaces and internal working of the Web service (as further described in Section 5). All these aspects of a Web Service are described using the terminology defined by the ontologies.
Goals represent user desires, for which fulfillment could be sought by executing a Web service. Ontologies can be used for the domain terminology to describe the relevant aspects. Goals model the user view in the Web service usage process and are therefore a separate top-level entity in WSMO described in detail in Section 6.
Finally, Mediators describe elements that overcome interoperability problems between different WSMO elements. Mediators are the core concept to resolve incompatibilities on the data, process and protocol level, i.e. in order to resolve mismatches between different used terminologies (data level), in how to communicate between Web services (protocol level) and on the level of combining Web services (and goals) (process level). These are described in detail in Section 7.
In WSMO, Ontologies are the key to linking conceptual real-world semantics defined and agreed upon by communities of users. An ontology is a formal explicit specification of a shared conceptualization [Gruber, 1993]. From this rather conceptual definition we want to extract the essential components which define an ontology. Ontologies define an agreed common terminology by providing concepts, and relationships between the concepts. In order to capture semantic properties of relations and concepts, an ontology generally also provides a set of axioms, which are expressions in some logical language. The following listing consists of the definition of the WSMO ontology element and the following sub-sections describe in more detail the attributes of the WSMO ontology element.
Class ontology sub-Class wsmoElement
importsOntology type ontology
usesMediator type ooMediator
hasConcept type concept
hasRelation type relation
hasFunction type function
hasInstance type instance
hasRelationInstance type relationInstance
hasAxiom type axiom
|
Building an ontology for some particular problem domain can be a rather
cumbersome and complex task. One standard way of dealing with the complexity
is modularization. Importing Ontologies allows a modular approach for
ontology design. Importing can be used as long as no conflicts need to be
resolved, otherwise an ooMediator needs to be used.
When importing ontologies, 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 ontology
mediators (ooMediator) are used when an alignment of the
imported ontology is necessary. Mediators are described in in more detail in
Section 7.
Concepts constitute the basic elements of the agreed terminology for some problem domain. From a high-level perspective, a concept – described by a concept definition – provides attributes with names and types. Furthermore, a concept can be a subconcept of several (possibly none) direct superconcepts as specified by the isA-relation.
Class concept sub-Class wsmoElement
hasSuperConcept type concept
hasAttribute type attribute
hasDefinition type logicalExpression
|
Class attribute sub-Class wsmoElement
hasRange type concept
|
forAll ?x ( ?x memberOf C
implies l-expr(?x) )forAll ?x ( ?x memberOf C
impliedBy l-expr(?x) )forAll ?x ( ?x memberOf C
equivalent l-expr(?x) )where l-expr(?x) is a logical expression with precisely
one free variable ?x.
The first example expresses that there is a necessary condition for membership in the extension of the concept. The second example expresses that there is a sufficient condition, and the third case means that there is a sufficient and necessary condition for an object being an element of the extension of the concept.
Relations are used in order to model interdependencies between several concepts (respectively instances of these concepts).
Class relation sub-Class wsmoElement
hasSuperRelation type relation
hasParameter type parameter
hasDefinition type logicalExpression
|
Class parameter sub-Class wsmoElement
hasDomain type concept
|
forAll ?v1,...,?vn ( R[p1
hasValue ?v1,...,pn hasValue
?vn]
implies l-expr(?v1,...,?vn)
)forAll ?v1,...,?vn ( R[p1
hasValue ?v1,...,pn hasValue
?vn]
impliedBy l-expr(?v1,...,?vn)
)forAll ?v1,...,?vn ( R[p1
hasValue ?v1,...,pn hasValue
?vn]
equivalent
l-expr(?v1,...,?vn) )If the parameters are not specified, then the relation is represented by a predicate symbol (see Section 8) where the identifier of the relation is used as the name of the predicate symbol. If R is the identifier denoting the relation and the parameters are not specified, then the logical expression takes one of the following forms:
forAll ?v1,...,?vn ( R(?v1,...,?vn)
implies l-expr(?v1,...,?vn)
)forAll ?v1,...,?vn ( R(?v1,...,?vn)
impliedBy l-expr(?v1,...,?vn)
)forAll ?v1,...,?vn ( R(?v1,...,?vn)
equivalent
l-expr(?v1,...,?vn) )l-expr(?v1,...,?vn) is a logical expression with
precisely ?v1,...,?vn as its free variables and
p1,...,pn are the names of the parameters of the
relation.
Using implies means there is a necessary condition for
instances ?v1,...,?vn to be related. Using
impliedBy means that there is a sufficient condition and
using equivalent means that there is a sufficient and
necessary condition for instances ?v1,...,?vn being
related.
A function is a special relation, with an unary range and a n-ary domain (parameters inherited from the relation), where the range value is functionally dependent on the domain values. In particular, the following constraint must hold (where F is the name of the function and != stands for inequality):
forAll ?x1,...,?xn,?r1,?r2 (false impliedBy
F(?x1,...,?xn,?r1) and F(?x1,...,?xn,?r2) and ?r1 !=
?r2)
In contrast to a function symbol, a function is not only a syntactical
entity but has a defined semantics that allows to actually evaluate the
function if concrete input values for the parameters are given. That means
that we can actually substitute the (ground) function term in some expression
by its concrete value. Functions for example can be used to represent and
exploit built-in predicates of common datatypes. Their semantics can be
captured externally by means of an oracle, or can be formalized by assigning
a logical expression to the hasDefinition property inherited
from relation.
Class function sub-Class relation
hasRange type concept
|
The logical representation of a function is almost the same as that of relations, whereby the result value of a function (respectively the value of a function term) has to be represented explicitly: the function is represented by a (n+1)-ary predicate symbol with named arguments (see Section 8) (where n is the number of arguments of the function) and the identifier of the function is used as the name of the predicate. In particular, the names of the parameters of the corresponding relation symbol are the names of the parameters of the function as well as one additional parameter range for denoting the value of the function term with the given parameter values. If the parameters are not specified, the function is represented by a predicate symbol with ordered arguments, and by convention the first argument specifies the value of the function term with given argument values.
If F is the identifier denoting the function and
p1,..., pn is the set of parameters of the function then the
logical expression for defining the semantics of the function (inherited from
relation) can for example take the form
forAll ?v1,...,?vn,?range ( F[p1
hasValue ?v1,...,pn hasValue ?vn, range
hasValue ?range]
equivalent
l-expr(?v1,...,?vn,?range) )
where l-expr(?v1,...,?vn,?range) is a logical expression with
precisely ?v1,...,?vn,?range as its free variables
and p1,...,pn are the names of the parameters of the function.
Clearly, in order to prevent ambiguities, range may not be used
as the name for a parameter of a function in order to prevent ambiguities.
Instances are either defined explicitly or by a link to an instance store, i.e., an external storage of instances and their values.
An explicit definition of instances of concepts is as follows:
Class instance sub-Class wsmoElement
hasType type concept
hasAttributeValues type attributeValue
|
Class attributeValue sub-Class wsmoElement
hasAttribute type attribute
|
Instances of relations (with arity n) can be seen as n-tuples of instances of the concepts which are specified as the parameters of the relation. Thus we use the following definition for instances of relations:
Class relationInstance sub-Class wsmoElement
hasType type relation
hasParameterValue type parameterValue
|
Class parameterValue sub-Class wsmoElement
hasParameter type parameter
|
A detailed discussion and a concrete proposal for how to integrate large sets of instance data in an ontology model can be found in the DIP Deliverable D2.2 [Kiryakov et. al., 2004]. Basically, the approach taken there is to integrate large sets of instances which already exist on some storage device by means of sending queries to external storage devices or oracles.
An axiom is a logical expression together with its annotations.
Class axiom sub-Class wsmoElement
hasDefinition type logicalExpression
|
WSMO Web service descriptions consist of non-functional, functional, and the behavioral aspects of a Web service. A Web service is a computational entity which is able (by invocation) to achieve a users goal. A service in contrast is the actual value provided by this invocation. Thereby a Web service might provide different services, such as for example Amazon can be used for acquiring books as well as to find out an ISBN number of a book.
In the following, we describe the elements of a Web service description:
Class webService sub-Class wsmoElement
importsOntology type ontology
usesMediator type {ooMediator, wwMediator}
hasNonFunctionalProperties type nonFunctionalProperty
hasCapability type capability
|
ooMediator) when steps for aligning, merging, and
transforming imported ontologies are needed. A Web service can use
wwMediators to deal with process and protocol mediation.The listing below defines a class for describing Web service specific non-functional properties. Examples of such non-functional properties include cost-related and charging-related properties of a Web service [O`Sullivan et al., 2002], or properties like like accuracy, network-related QoS, performance, reliability, robustness, scalability, security, etc [Rajesh & Arulazi, 2003]. In opposite to simple annotation non-functional properties are not only represented by simple key value pairs, but can be expressed using a logical expression. WSMO does not pose any restrictions on the set of valid formulae that can be used.
Class nonFunctionalProperty sub-Class wsmoElement
hasDefinition type logicalExpression
|
A capability defines the Web service by means of its functionality.
Class capability sub-Class wsmoElement
importsOntology type ontology
usesMediator type {ooMediator, wgMediator}
hasNonFunctionalProperties type nonFunctionalProperty
hasSharedVariables type sharedVariables
hasPrecondition type axiom
hasAssumption type axiom
hasPostcondition type axiom
hasEffect type axiom
|
ooMediator) when steps for aligning, merging, and
transforming imported ontologies are needed. It can be linked to a goal
using a wgMediator.If ?v1,...,?vn are the shared variables defined in a
capability, and pre(?v1,...,?vn),
ass(?v1,...,?vn), post(?v1,...,?vn) and
eff(?v1,...,?vn), are used to denote the formulae defined
by the preconditions, assumptions, postconditions, and effects
respectively, then the following holds:
forAll ?v1,...,?vn (
pre(?v1,...,?vn) and ass(?v1,...,?vn)
implies post(?v1,...,?vn) and
eff(?v1,...,?vn)).
An interface describes how the functionality of the Web service can be achieved (i.e. how the capability of a Web service can be fulfilled) by providing a twofold view on the operational competence of the Web service:
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 Web service providers [1].
An interface is defined by the following properties:
Class interface sub-Class wsmoElement
importsOntology type ontology
usesMediator type ooMediator
hasNonFunctionalProperties type nonFunctionalProperty
hasChoreography type choreography
hasOrchestration type orchestration
|
ooMediator) when steps for aligning, merging, and
transforming imported ontologies are needed.Goals are representations of an objective for which fulfillment is sought through the execution of a Web service. Goals can be descriptions of Web services that would potentially satisfy the user desires. The following listing presents the goal definition:
Class goal sub-Class wsmoElement
importsOntology type ontology
usesMediator type {ooMediator, ggMediator}
hasNonFunctionalProperties type nonFunctionalProperty
requestsCapability type capability
|
ooMediator) in case assistance for aligning, merging, and
transforming imported ontologies are needed. A goal may be defined by
reusing one or several already-existing goals. This is achieved by
using goal mediators (ggMediator). For a detailed account
on mediators we refer to Section 7.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:
The mediators are defined as follows:
Class mediator sub-Class wsmoElement
importsOntology type ontology
hasNonFunctionalProperties type nonFunctionalProperty
hasSource type {ontology, goal, webService, mediator}
hasTarget type {ontology, goal, webService, mediator}
hasMediationService type {goal, webService, wwMediator}
Class ooMediator sub-Class mediator
hasSource type {ontology, ooMediator}
Class ggMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {goal, ggMediator}
hasTarget type {goal, ggMediator}
Class wgMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {webService, goal, wgMediator, ggMediator}
hasTarget type {webService, goal, ggMediator, wgMediator}
Class wwMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {webService, wwMediator}
hasTarget type {webService, wwMediator}
|
wwMediator that links to a Web service that actually
implements the mapping.ggMediator,
wgMediator, and wwMediator, use a set of
ooMediators in order to map between different vocabularies
used in the description of goals and Web service capabilities and align
different heterogeneous ontologies.A further remark on wgMediators is in place: 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 Web service via its choreography interface meaning that the Web service (totally or partially) fulfills the goal to which it is linked (2) A Web service links to a goal via its orchestration interface meaning that the Web service needs this goal to be resolved in order to fulfill the functionality described in its capability.
Notice that there are two principal ways of relating mediators with other
entities in the WSMO model: (1) an entity can specify a relation with a
mediator through the has usesMediator attribute and (2) entities
can be related with mediators through the source and target attributes of the
mediator. We expect cases in which a mediator needs to be referenced directly
from an entity, for example for importing a particular ontology necessary for
the descriptions in the entity. We also expect cases in which not the
definition of the entity itself, but rather the use of entities in a
particular scenario (e.g. Web service invocation) requires the use of
mediators. In such a case, a mediator needs to be selected, which provides
mediation Web services between these particular entities. WSMO does not
prescribe the type of use of mediators and therefore provides maximum
flexibility in the use of mediators and thus allows for loose coupling
between Web services, goals, and ontologies.
As the major component of axiom logical expressions are used almost everywhere in the WSMO model to capture specific nuances of meaning of modeling elements or their constituent parts in a formal and unambiguous way. In the following, we give a definition of the syntax of the formal language that is used for specifying logical expressions. The semantics of this language is defined formally by the WSML working group in a separate document.
Section 8.1 introduces the identifiers recommended for variables in WSMO. Section 8.2 gives the definition of the basic vocabulary and the set of terms for building logical expression. Section 8.3 defines the most basic formulas (i.e. atomic formulae) which allows us to eventually define the set of logical expressions.
Apart from the identifiers (URIs and anonymous) defined in Section 2.1 and values defined in Section
2.2, logical expressions in WSMO can also identify variables. Variable
names are strings that start with a question mark '?', followed
by any positive number of symbols in {a-z, A-Z,
0-9, _, -}, for example
?var or ?lastValue_Of.
Let URI be the set of all valid uniform resource identifiers. This set will be used for the naming (or identifying, respectively) various entities in a WSMO description.
Definition 1. The vocabulary V of our language L(V) consists of the following symbols:
(, ), ofType, ofTypeSet,
memberOf, subConceptOf, hasValue,
hasValues, false, true.or,
and, not,
implies,impliedBy, equivalent ,
forAll, exists.As usual, 0-ary function symbols are called constants. 0-ary predicate symbols correspond to propositional variables in classical propositional logic.
Definition 2. Given a vocabulary V, we can define the set of terms Term(V) (over vocabulary V) as follows:
u in URI is a term in
Term(V).i in AnID is a term in
Term(V).l in Lit is a term in
Term(V).v in Var is a term in
Term(V).f is a function symbol from FSym with arity(f)
= n and t1, ..., tn are terms, then f(t1, ...,
tn) is a term in Term(V).As usual, the set of ground terms GroundTerm(V) is the subset of terms in Term(V) which do not contain any variables.
Terms can be used in general to describe computations (in some domain). One important additional interpretation of terms is that they denote objects in some universe and thus provide names for entities in some domain of discourse.
We extend the previous definition (Definition 2) to the set of (complex) logical expressions (or formulae, respectively) L(V) (over vocabulary V) as follows:
Definition 3. A simple logical expression in L(V) (or atomic formula) is inductively defined as follows:
p is a predicate symbol in PSym with arity(p)
= n and t1, ..., tn are terms, then p(t1, ...,
tn) is a simple logical expression in L(V) .r is a predicate symbol with named arguments in
PSymNamed with arity(p) = n, parNames(r) = {p1,
...,pn} and t1, ...,tn are terms, then R[p1
hasValue t1, ..., pn hasValue tn] is a simple logical expression
in L(V) .true and false are simple logical expression
in L(V).P, ATT, T are terms in
Term(V), then P[ATT ofType T] is a simple logical
expression in L(V) .P, ATT,
T1,...,Tn (where n >= 1) are terms in
Term(V), then P[ATT ofTypeSet (T1,...,Tn)] is a
simple logical expression in L(V).O, T are terms in Term(V), then
O memberOf T is a simple logical expression in
L(V).C1, C2 are terms in Term(V), then
C1 subConceptOf C2 is a simple
logical expression in L(V).R1, C2 are predicate symbols in
PSym or PSymNamed with the same signature, then
R1 subRelationOf R2 is a simple logical expression on
L(V).O, V, ATT are terms in
Term(V), then O[ATT hasValue V] is a simple logical
expression in L(V).O, V1,...,Vn,
ATT (where n >=1) are terms in Term(V), then
O[ATT hasValues {V1,...,Vn}] is a simple logical expression
in L(V).T1 and T2 are terms in Term(V),
then T1 = T2 is a simple logical expression in
L(V).The intuitive semantics for simple logical expressions (wrt. an interpretation) is as follows:
C[ATT ofType T] defines a constraint on the
possible values that instances of class C may take for property
ATT to values of type T. Thus, this is
expression is a signature expression.C[ATT ofTypeSet (T1,...Tn)]. It
defines a constraint on the possible values that instances of class
C may take for property ATT to values of types
T1, .., Tn. That means all values of all the specified types are allowed
as values for the property ATT.O memberOf T is true, iff element O is an
instance of type T, that means the element denoted by
O is a member of the extension of type T.C1 subConceptOf C2 is true iff concept
C1 is a subconcept of concept C2, that means
the extension of concept C1 is a subset of the extension of
concept C2.O[ATT hasValue V] is true if the element
denoted by O takes value V under property
ATT.O[ATT
hasValues {V1,...,Vn}]: The expression holds if the set of values
that the element O takes for property ATT
includes all the values V1,...Vn. That means the set of
values of O for property ATT is a superset of
the set {V1, ..., Vn}.T1 = T2 is true, if both terms T1 and
T1 denote the same element of the universe.Definition 4. Definition 3 is extended to complex logical expressions in L(V) as follows
L is a logical expression in L(V) , then
not L is a logical expression in L(V).L1 and L2 are logical expressions in
L(V) and op is one of the logical connectives in {
or,and,implies, impliedBy,
equivalent }, then L1 op L2 is a logical expression
in L(V).L is a logical expression in L(V),
x is a variable from Var and Q is a
quantor in { forAll, exists }, then Qx(L) is a
logical expression in L(V).The intuitive semantics for complex logical expressions (wrt. to in interpretation) is as follows:
not L is true iff the logical expression L does not
holdor,and,implies, equivalent,
impliedBy denote the common disjunction, conjunction,
implication, equivalence and backward implication of logical
expressionsforAll x (L) is true iff L holds for all possible
assignments of x with an element of the universe.exists x (L) is true iff there is an assignment of x with
an element of the universe such that L holds.Notational conventions:
There is a precedence order defined for the logical connectives as
follows, where op1 < op2 means
that op2 binds stronger than op1:
implies,
equivalent,impliedBy<
or, and <
not.
The precedence order can be exploited when writing logical expressions in order to avoid extensive use of parenthesis. If there are ambiguities in evaluating an expression, parenthesis must be used to resolve the ambiguities.
The terms O[ATT ofTypeSet (T)] and O[ATT hasValues
{V}] (that means for the case n = 1 in the respective clauses above)
can be written more simple by omitting the parenthesis.
A logical expression of the form false impliedBy L (commonly
used in Logic Programming systems for defining integrity constraints) can be
written using the following syntactical shortcut: constraint
L.
We allow the following syntactic composition of atomic formulas as a
syntactic abbreviation for two separate atomic formulas: C1
subConceptOf C2 and C1[ATT op V] can be syntactically
combined to C1[ATT op V] subConceptOf C2. Additionally, for the
sake of backwards compatibility with F-Logic, we also allow the following
notation for the combination of the two atomic formulae: C1
subConceptOf C2 [ATT op V]. Both abbreviations stand for the set of
the two single atomic formulae. The first abbreviation is considered to be
the standard abbreviation for combining these two kinds of atomics
formulae.
Furthermore, we allow path expressions as a syntactical shortcut for
navigation related expressions: p.q stands for the element which
can be reached by navigating from p via property q. The property q has to be
a non-set-valued property (hasValue). For navigation over
set-valued properties (hasValues), we use a different expression
p..q. Such path expressions can be used like a term wherever a
term is expected in a logical expression.
Note: Note that this definition for our language L(V) is extensible by extending the basic vocabulary V. In this way, the language for expressing logical expressions can be customized to the needs of some application domain.
Semantically, the various modeling elements of ontologies can be represented as follows: concepts can be represented as terms, relations as predicates with named arguments, functions as predicates with named arguments, instances as terms and axioms as logical expressions.
This document presented the Web Service Modeling Ontology (WSMO) for describing several aspects related to services on the Web, by refining the Web Service Modeling Framework (WSMF). The definition of the missing elements (choreography and orchestration) will be provided in separate deliverables of the WSMO working group, and future versions of this document will contain refinements of the mediators.
[Baida et al., 2004] Z. Baida, J. Gordijn, B. Omelayenko, and H. Akkermans: A shared service terminology for online service provisioning, ICEC '04: Proceedings of the 6th international conference on Electronic commerce, p.1-10, 2004.
[Feier, 2004] C. Feier (Ed.): WSMO Primer, WSMO Deliverable D3.1, DERI Working Draft, 2004, latest version available at http://www.wsmo.org/2004/d3/d3.1/.
[Berners-Lee et al, 1998] T. Berners-Lee, R. Fielding, and L. Masinter: RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax, IETF, August 1998, available at http://www.isi.edu/in-notes/rfc2396.txt.
[Biron & Malhotra, 2001] P. V. Biron and A. Malhotra: XML Schema Part 2: Datatypes, W3C Recommendation 02, 2001, avaliable at: http://www.w3.org/TR/xmlschema-2/.
[Bray et al., 1999] T. Bray, D. Hollander, and A. Layman (Eds.): Namespaces in XML, W3C Recommendation REC-xml-names-19990114, 1999, available at: http://www.w3.org/TR/REC-xml-names/.
[Brickley & Miller, 2004] D. Brickley and L. Miller: FOAF Vocabulary Specification, available at: http://xmlns.com/foaf/0.1/.
[de Bruijn., 2004] J. de Bruijn (Ed.): The WSML Family of Representation Languages, WSMO Deliverable D16, DERI Working Draft, 2004, latest version available at http://www.wsmo.org/2004/d16/.
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[Gruber, 1993] T. Gruber: A translation approach to portable ontology specifications,Knowledge Acquisition, 5:199-220, 1993.
[Gurevich, 1995] Yuri Gurevich: Evolving Algebras 1993: Lipari Guide, Specification and Validation Methods, Oxford University Press, 1995, 9--36
[Hayes, 2004] P. Hayes (Ed.): RDF Semantics, W3C Recommendation 10 February 2004, 2004.
[IANA, 2002] Internet Assigned Number Authority: MIME Media Types, available at: http://www.iana.org/assignments/media-types/, February 2002.
[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. iii + 17 pages.
[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.ch.
[Keller et. al., 2004] U. Keller, R. Lara, and A. Polleres: WSMO Web Service Discovery, WSMO Deliverable D5.1, November 2004, Available from http://www.wsmo.org/2004/d5/d5.1/v0.1/20041112/
[Preist, 2004]Chris Preist: A conceptual architecture for semantic web services. In Proceedings of the International Semantic Web Conference 2004 (ISWC 2004), November 2004.
[Kiryakov et. al., 2004] A. Kiryakov, D. Ognyanov, and V. Kirov: A Framework for Representing Ontologies Consisting of Several Thousand Concepts Definitions, Project Deliverable D2.2 of DIP, June 2004, Available from http://dip.semanticweb.org/deliverables/D22ORDIv1.0.pdf
[O`Sullivan et al., 2002] J. O`Sullivan, D. Edmond, and A. Ter Hofstede: What is a Service?: Towards Accurate Description of Non-Functional Properties, Distributed and ParallelDatabases, 12:117-133, 2002.
[OMG, 2002] The Object Management Group: Meta-Object Facility, version 1.4, 2002. Available at http://www.omg.org/technology/documents/formal/mof.htm.
[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.)
[Roman et al., 2005] D. Roman, J. Scicluna and C. Feier: Ontology-based Choreography and Orchestration of WSMO Services, WSMO Deliverable D14, DERI Working Draft, 2005, latest version available at http://www.wsmo.org/TR/d14/
[Stollberg et al., 2004] M. Stollberg, H. Lausen, A. Polleres, and R. Lara (Eds.): WSMO Use Case Modeling and Testing, WSMO Deliverable D3.2, DERI Working Draft, 2004, latest version available at http://www.wsmo.org/2004/d3/d3.2/
[Weibel et al., 1998] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf: RFC 2413 - Dublin Core Metadata for Resource Discovery, September 1998.
[Yang & Kifer, 2003] G. Yang and M. Kifer: Reasoning about Anonymous Resources and Meta Statements on the Semantic Web J. Data Semantics I 2003: 69-97.
[W3C Glossary, 2004] Hugo Haas, and Allen Brown (editors): Web Services Glossary, W3C Working Group Note 11 February 2004, available at http://www.w3.org/TR/ws-gloss/
This work is funded by the European Commission under the projects DIP, Knowledge Web, InfraWebs, SEKT, SWWS, ASG and Esperonto; by Science Foundation Ireland under the DERI-Lion project; by the Vienna city government under the CoOperate programme and by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW² and TSC.
The editors would like to thank to all the members of the WSMO, WSML, and WSMX working groups for their advice and input into this document.
Class annotation
hasContributor type dc:contributor
hasCoverage type dc:coverage
hasCreator type dc:creator
hasDate type dc:date
hasDescription type dc:description
hasFormat type dc:format
hasIdentifier type dc:identifier
hasLanguage type dc:language
hasOwner type owner
hasPublisher type dc:publisher
hasRelation type dc:relation
hasRights type dc:rights
hasSource type dc:source
hasSubject type dc:subject
hasTitle type dc:title
hasType type dc:type
hasVersion type version
Class wsmoElement
hasAnnotation type annotation
Class ontology sub-Class wsmoElement
importsOntology type ontology
usesMediator type ooMediator
hasConcept type concept
hasRelation type relation
hasFunction type function
hasInstance type instance
hasRelationInstance type relationInstance
hasAxiom type axiom
Class concept sub-Class wsmoElement
hasSuperConcept type concept
hasAttribute type attribute
hasDefinition type logicalExpression multiplicity = single-valued
Class attribute sub-Class wsmoElement
hasRange type concept multiplicity = single-valued
Class relation sub-Class wsmoElement
hasSuperRelation type relation
hasParameter type parameter
hasDefinition type logicalExpression multiplicity = single-valued
Class parameter sub-Class wsmoElement
hasDomain type concept multiplicity = single-valued
Class function sub-Class relation
hasRange type concept multiplicity = single-valued
Class instance sub-Class wsmoElement
hasType type concept
hasAttributeValues type attributeValue
Class attributeValue sub-Class wsmoElement
hasAttribute type attribute multiplicity = single-valued
hasValue type {instance, literal, anonymousId}
Class relationInstance sub-Class wsmoElement
hasType type relation
hasParameterValues type parameterValue
Class parameterValue sub-Class wsmoElement
hasParameter type parameter multiplicity = single-valued
hasValue type {instance, literal, anonymousId} multiplicity = single-valued
Class axiom sub-Class wsmoElement
hasDefinition type logicalExpression
Class webService sub-Class wsmoElement
importsOntology type ontology
usesMediator type {ooMediator, wwMediator}
hasNonFunctionalProperties type nonFunctionalProperty
hasCapability type capability multiplicity = single-valued
hasInterface type interface
Class capability sub-Class wsmoElement
importsOntology type ontology
usesMediator type {ooMediator, wgMediator}
hasNonFunctionalProperties type nonFunctionalProperty
hasSharedVariables type sharedVariables
hasPrecondition type axiom
hasAssumption type axiom
hasPostcondition type axiom
hasEffect type axiom
Class interface sub-Class wsmoElement
importsOntology type ontology
usesMediator type ooMediator
hasNonFunctionalProperties type nonFunctionalProperty
hasChoreography type choreography
hasOrchestration type orchestration
Class goal sub-Class wsmoElement
importsOntology type ontology
usesMediator type {ooMediator, ggMediator}
hasNonFunctionalProperties type nonFunctionalProperty
requestsCapability type capability multiplicity = single-valued
requestsInterface type interface
Class mediator sub-Class wsmoElement
importsOntology type ontology
hasNonFunctionalProperties type nonFunctionalProperty
hasSource type {ontology, goal, webService, mediator}
hasTarget type {ontology, goal, webService, mediator}
hasMediationService type {goal, webService, wwMediator}
Class ooMediator sub-Class mediator
hasSource type {ontology, ooMediator}
Class ggMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {goal, ggMediator}
hasTarget type {goal, ggMediator}
Class wgMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {webService, goal, wgMediator, ggMediator}
hasTarget type {webService, goal, ggMediator, wgMediator}
Class wwMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {webService, wwMediator}
hasTarget type {webService, wwMediator}
Class nonFunctionalProperty sub-Class wsmoElement
hasDefinition type logicalExpression
Footnotes:
[1] One could argue that
orchestration should not be part of a public interface because it refers to
how a Web service is implemented. However, this is a short-sighted view that
does not reflect the nature of fully open and flexible eCommerce. Here
companies shrink to their core processes which they are really profitable in.
All other processes are outsourced and consumed as eServices. eCommerce
companies 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 this dinosaurian phase of eCommerce
where large companies still exist, orchestration may be an
important aspect. The orchestration of a Web 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 their
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 it comes in
as a silver bullet in the process. How they manage the difference between the
process decomposition at the choreography and the orchestration level is the
business intelligence of the service provider.
[2] Note that [Preist, 2004] also distinguishes between a computational entity in general and Web service, where the former does not necessarily have a Web accessible interface. WSMO does not make this distinction.
$Date: 06-11-2006 - 14:16$