This document is also available in non-normative PDF version. The intent of the document is to be submitted to a standardization body.
This document presents an ontology called Web Service Modeling Ontology (WSMO) for describing various aspects related to Semantic Web Services. Having 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. Having 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: ontologies that provide the terminology used by other elements, goals 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 interpretability problems.
This document is organized as follows: Section 2 describes the language used for defining WSMO, then we define in the next Section the top level elements of WSMO (Section 3), Ontologies in Section 4, service descriptions in Section 5, goals in Section 6 and mediators in Section 7. In Section 8 we define 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 describes the non functional properties used in the definition of different WSMO elements and Section 10 presents our conclusions and further directions.
For a brief tutorial 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 related to the WSMO initiative: The WSML working group focusing on language issues and developing an adequate Web Service Modeling Language with various sublanguages as well 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 target 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 interchangeable in this document; they are meant to represent systems designed to support interoperable machine-to-machine interactions over the internet.
In order to define WSMO, which is meant to be a meta-model for semantic web services, we make use of Meta Object Facility (MOF) [OMG, 2002], a specification that defines an abstract language and a framework for specifying, constructing, and managing technology neutral metamodels. MOF defines a metadata architecture consisting of four layers, namely:
information layer comprises the data that we wish to
describe,model layer comprises the metadata that describes data
in the information layer,metamodel layer comprises the descriptions that define
the structure and semantics of the metadata,meta-metamodel layer comprises the description of the
structure and semantics of meta-metadata).In terms of the four MOF layers, the language in which WSMO is defined corresponds to the meta-meta model layer, WSMO itself constitutes the meta-model layer, the actual ontologies, services, goals, and mediators specifications constitute the model layer, and the actual data described by the ontologies and exchanged between the web services constitute the information layer.
The most used MOF metamodeling 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:
Every WSMO element is identified by one of the following identifiers:
WSMO is based on the idea of identifying things using web identifiers (called Uniform Resource Identifiers). Everything in WSMO is by default denoted by a URI, except when itself classifies it as Literal, Variable or Anonymous Id. Using URIs does not limit WSMO to make 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 Identifier. The same
numbered Anonymous Id represents the same Identifier within the same
scope (logicalExpression), otherwise Anonymous Ids represent
different Identifiers [Yang & Kifer, 2003].
Anonymous Ids can be used to denote objects that exists, but don't 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 connecting object between John
and "hitchhikersstreet", "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 wrt. implementation.
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 to a data type (e.g. to xsd:integer). Formally, such a data type 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 more in detail in the WSML Family of
Representation Languages [De Bruijn, 2004].
WSMO defines four top level elements:
Class WSMO
hasOntology type ontology
hasService type service
hasGoal type goal
hasMediator type mediator
|
In WSMO Ontologies are the key to link 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 a common agreed upon 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. The following listing consists of the definition of the WSMO ontology element and the following sub-sections describe in more details the attributes of the WSMO ontology element.
Class ontology
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
usesMediator type ooMediator
hasConcept type concept
hasRelation type relation
hasFunction type function
hasInstance type instance
hasAxiom type axiom
|
The following non functional properties are available for characterizing ontologies: Contributor, Coverage, Creator, Date, Description, Format, Identifier, Language, Owner, Publisher, Relation, Rights, Source, Subject, Title, Type, Version.
Building an ontology for some particular problem domain can be a rather
cumbersome and complex task. One standard way to deal with the complexity is
modularization. importedOntologies allow a modular approach for
ontology design; this simplified statement 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 Section 7 in more detail.
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
hasNonFunctionalProperties type nonFunctionalProperty
hasSuperConcept type concept
hasAttribute type attribute
hasDefinition type logicalExpression
|
non functional properties recommended are: Contributor, Coverage,
Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.attributes that represent named slots for data values for
instances that can 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.
Class attribute
hasNonFunctionalProperties type nonFunctionalProperty
hasRange type concept
|
non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.concept that serves as an integrity constraint
on the values of the attribute.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.
In the first case, one gives a necessary condition for membership in the extension of the concept; in the second case, one gives a sufficient condition and in the third case, we have 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
hasNonFunctionalProperties type nonFunctionalProperty
hasSuperRelation type relation
hasParameter type parameter
hasDefinition type logicalExpression
|
non functional properties recommended are: Contributor, Coverage,
Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.relations of which the defined relation
is declared as being a subrelation. Being a subrelation of some other
relation in particular means that the relation inherits the signature
of this superrelation and the corresponding constraints. Furthermore,
the set of tuples belonging to the relation (the extension of the
relation, resp.) is a subset of each of the extensions of the
superrelations.Class parameter
hasNonFunctionalProperties type nonFunctionalProperty
hasDomain type concept
|
non functional properties recommended are: Contributor, Coverage, Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.concept constraining the possible values that
the parameter can take.logicalExpression (see Section 8) defining the set of instances
(n-ary tuples, if n is the arity of the relation) of the relation. If
the parameters are specified the relation is represented by a n-ary
predicate symbol with named arguments (see Section 8) (where n is the number of
parameters of the relation) 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 specified then the logical
expression takes one of the following forms:
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 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, one gives a necessary condition for
instances ?v1,...,?vn to be related; using
impliedBy, one gives a sufficient condition and using
equivalent, we have a sufficient and necessary condition
for instances ?v1,...,?vn being related.
A function is a special relation, with a unary range and a
n-ary domain (parameters inherited from relation),
where the range value is functrional dependend on the domain values. In
contrast to a function symbol, a function is not only a syntactical entity
but has some semantics that allows to actually evaluate the function if one
considers concrete input values for the parameters of the function. That
means, that we actually can replace the (ground) function term in some
expression by its concrete value. Function can be used for instance to
represent and exploit built-in predicates of common datatypes. Their
semantics can be captured externally by means of an oracle or it can be
formalized by assigning a logical expression to the definedBy
property inherited from relation.
Class function sub-Class relation
hasRange type concept
|
concept constraining the possible return values of the
function.The logical representation of a function is almost the same as for
relations, whereby the result value of a function (resp. the value of a
function term) has to be represented explicitly: the function is represented
by an (n+1)-ary predicate symbol with named arguments (see Section 8) (where
n is the number of arguments of the function) where 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. In Case the paramters are not specified the
function is represented by an 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, 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
hasNonFunctionalProperties type nonFunctionalProperty
hasType type concept
hasAttributeValues type attributeValue
|
non functional properties recommended are: Contributor, Coverage,
Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.concept to which the instance belongs to.Class attributeValue
hasAttribute type attribute
|
attribute this value refers to.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
hasNonFunctionalProperties type nonFunctionalProperty
hasType type relation
hasParameterValues type parameterValue
|
non functional properties recommended are: Contributor, Coverage,
Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.relation this instance belongs to.parameterValues specifying the
single instances that are related according to this relation instance.
The list of parameter values of the instance has to be compatible wrt.
names and range constraints of that are specified in the corresponding
relation.
Class parameterValue
hasParameter type parameter
|
parameter this value refers to.A detailed discussion and a concrete proposal on how to integrate large sets of instance data in an ontology model can be found in DIP Deliverable D2.2 [Kiryakov et. al., 2004]. Basically, the approach there is to integrate large sets of instances which are already existing on some storage devices by means of sending queries to external storage devices or oracles.
An axiom is considered to be a logical expression together
with its non functional properties.
Class axiom
hasNonFunctionalProperties type nonFunctionalProperty
hasDefinition type logicalExpression
|
non functional properties recommended are: Contributor, Coverage,
Creator, Date, Description, Identifier, Relation, Source, Subject, Title, Type, Version.WSMO provides service descriptions for describing services that are
requested by service requesters, provided by service providers, and agreed
between service providers and requesters. In the following, we describe the
common elements of these descriptions as a general service
description definition:
Class service
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
usesMediator type {ooMediator, wwMediator}
hasCapability type capability
|
non functional properties recommended are: Accuracy, Contributor,
Coverage, Creator, Date, Description, Financial, Format, Identifier, Language, Network-related QoS, Owner, Performance, Publisher, Relation, Reliability, Rights, Robustness, Scalability, Security,
Source, Subject, Title, Transactional, Trust, Type, Version.ooMediators) when steps for aligning, merging and
transforming imported ontologies are needed. A service can use
wwMediators to deal with process and protocol
mediation.capability defines the service by means of its
functionality.
Class capability
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
usesMediator type {ooMediator, wgMediator}
hasPrecondition type axiom
hasAssumption type axiom
hasPostcondition type axiom
hasEffect type axiom
|
non functional properties recommended are: Accuracy, Contributor, Coverage, Creator, Date, Description, Financial, Format, Identifier, Language, Network-related QoS, Owner, Performance,
Publisher, Relation, Reliability, Rights, Robustness,
Scalability, Security, Source, Subject, Title, Transactional, Trust, Type, Version.ooMediators) when steps for aligning, merging and
transforming imported ontologies are needed. It can be linked to
a goal using a wgMediator.PreConditions specify the information space of the
service before its execution.Assumptions describe the state of the world before
the execution of the service.PostConditions describe the information space of
the service after the execution of the service.Effects describe the state of the world after the
execution of the service.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.orchestration decomposes a capability in terms of
functionality required from other services.This distinction reflects the difference between communication and
cooperation. The choreography defines how to communicate
with the service in order to consume its functionality. The
orchestration defines how the overall functionality is
achieved by the cooperation of more elementary service providers [1].
An interface is defined by the following properties:
Class interface
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
usesMediator type ooMediator
hasChoreography type choreography
hasOrchestration type orchestration
|
non functional properties recommended are: Accuracy, Contributor, Coverage, Creator, Date, Description, Financial, Format, Identifier, Language, Network-related QoS, Owner, Performance,
Publisher, Relation, Reliability, Rights, Robustness,
Scalability, Security, Source, Subject, Title, Transactional, Trust, Type, Version.ooMediators) when steps for aligning, merging and
transforming imported ontologies are needed.Choreography provides the necessary information to
communicate with the service. From a business-to-business
perspective, the choreography can be split in two distinct
choreographies:
Orchestration describes how the service makes use
of other services in order to achieve its capability.Goals are descriptions of problems that should be solved by services; they
can be descriptions of services that would potentially satisfy the user
desires. The following listing presents the goal definition:
Class goal
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
usesMediator type {ooMediator, ggMediator}
requestsCapability type capability
|
non functional properties recommended are: Accuracy, Contributor,
Coverage, Creator, Date, Description, Financial, Format, Identifier, Language, Network-related QoS, Owner, Performance, Publisher, Relation, Reliability, Rights, Robustness, Scalability, Security,
Source, Subject, Title, Transactional, Trust, Type, Version.ooMediators) when steps 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 (ggMediators). 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 :
ggMediators: mediators that link two goals. This link
represents the refinement of the source goal into the target goal.ooMediators: mediators that import ontologies and resolve
possible representation mismatches between ontologies.wgMediators: mediators that link services to goals,
meaning that the service (totally or partially) fulfills the goal to
which it is linked. wgMediators may explicitly state the
difference between the two entities and map different vocabularies
(through the use of ooMediators).wwMediators: mediators linking two services.
The mediator is defined as follows:
Class mediator
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
hasSource type {ontology, goal, service, mediator}
hasTarget type {ontology, goal, service, mediator}
hasMediationService type {goal, service, 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 {service, goal, wgMediator, ggMediator}
hasTarget type {service, goal, ggMediator, wgMediator}
Class wwMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {service, wwMediator}
hasTarget type {service, wwMediator}
|
non functional properties recommended are: Accuracy, Contributor,
Coverage, Creator, Date, Description, Financial, Format, Identifier, Language, Network-related QoS, Owner, Performance, Publisher, Relation, Reliability, Rights, Robustness, Scalability, Security,
Source, Subject, Title, Transactional, Trust, Type, Version.mediationService points to a goal that declarative
describes the mapping or to a service that actually implements the
mapping or to a wwMediator that links to a 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 service capabilities and align
different heterogeneous ontologies.
Notice that there are two principled ways of relating mediators with other
entities in the WSMO model: (1) an entity can specify a relation with a
mediator through the has usesMediators 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. service invocation) requires the use
of mediators. In such a case, a mediator needs to be selected, which provides
mediation services between these particular entities. WSMO does not prescribe
the type of use of mediators and therefore provides maximal flexibility in
the use of mediators and thus allows for loose coupling between 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 logicalExpressions. The semantics of
this language will be defined formally by the WSML working group in a separate
document.
Section 8.1 introduces the identifiers recommended for variables in WSMO. Sections 8.2 gives the definition of the basic vocabulary and the set of terms for building logical expression. Then we define in Section 8.3 the most basic formulas (atomic formulae, resp.) 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, _, -}, i.e.
?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, resp.) 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, resp.) L(V) (over vocabulary V) as follows:
Definition 3. A simple logical expression in L(V) (or atomic formula) is inductively defined by
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 prevent from extensive use of parenthesis. In case that 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 simpler by omitting the parenthesis.
A logical expression of the form false impliedBy L (commonly
used in Logic Programming system 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 as well 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.
Non functional properties are used in the definition of WSMO elements. Which non functional properties apply to which WSMO element is specified in the description of each WSMO element. We recommend most elements of [Weibel et al., 1998].
Non-functional properties are defined in the following way:
Class nonFunctionalProperty
hasAccuracy type accuracy
hasContributer type dc:contributor
hasCoverage type dc:coverage
hasCreator type dc:creator
hasDate type dc:date
hasDescription type dc:description
hasFinancial type financial
hasFormat type dc:format
hasIdentifier type dc:identifier
hasLanguage type dc:language
hasNetworkRelatedQoS type networkRelatedQoS
hasOwner type owner
hasPerformance type performance
hasPublisher type dc:publisher
hasRelation type dc:relation
hasReliability type reliability
hasRights type dc:rights
hasRobustness type robustness
hasScalability type scalability
hasSecurity type security
hasSource type dc:source
hasSubject type dc:subject
hastitle type dc:title
hasTransactional type transactional
hasTrust type trust
hasType type dc:type
hasVersion type version
|
dc:contributor include a person, an
organization, or a 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 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
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 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.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.
[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.
[Hayes, 2004] P. Hayes (Ed.): RDF Semantics, W3C Recommendation 10 February 2004, 2004.
[IANA, 2002] Intenet 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.
[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.
[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.)
[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.
The work is funded by the European Commission under the projects DIP, Knowledge Web, InfraWebs, SEKT, SWWS, ASG and Esperonto; by Science Foundation Ireland under the DERI-Lion project; by the 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 WSMO
hasOntology type ontology
hasService type service
hasGoal type goal
hasMediator type mediator
Class ontology
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
usesMediator type ooMediator
hasConcept type concept
hasRelation type relation
hasFunction type function
hasInstance type instance
hasAxiom type axiom
Class concept
hasNonFunctionalProperties type nonFunctionalProperty
hasSuperConcept type concept
hasAttribute type attribute
hasDefinition type logicalExpression muliplicity = single-valued
Class attribute
hasNonFunctionalProperties type nonFunctionalProperty
hasRange type concept muliplicity = single-valued
Class relation
hasNonFunctionalProperties type nonFunctionalProperty
hasSuperRelation type relation
hasParameter type parameter
hasDefinition type logicalExpression muliplicity = single-valued
Class parameter
hasNonFunctionalProperties type nonFunctionalProperty
hasDomain type concept muliplicity = single-valued
Class function sub-Class relation
hasRange type concept muliplicity = single-valued
Class instance
hasNonFunctionalProperties type nonFunctionalProperty
hasType type concept
hasAttributeValues type attributeValue
Class attributeValue
hasAttribute type attribute muliplicity = single-valued
hasValue type {instance, literal, anonymousId}
Class relationInstance
hasNonFunctionalProperties type nonFunctionalProperty
hasType type relation
hasParameterValues type parameterValue
Class parameterValue
hasParameter type parameter muliplicity = single-valued
hasValue type {instance, literal, anonymousId} muliplicity = single-valued
Class axiom
hasNonFunctionalProperties type nonFunctionalProperty
hasDefinition type logicalExpression
Class service
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
usesMediator type {ooMediator, wwMediator}
hasCapability type capability muliplicity = single-valued
hasInterface type interface
Class capability
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
usesMediator type {ooMediator, wgMediator}
hasPrecondition type axiom
hasAssumption type axiom
hasPostcondition type axiom
hasEffect type axiom
Class interface
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
usesMediator type ooMediator
hasChoreography type choreography
hasOrchestration type orchestration
Class goal
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
usesMediator type {ooMediator, ggMediator}
requestsCapability type capability muliplicity = single-valued
requestsInterface type interface
Class mediator
hasNonFunctionalProperties type nonFunctionalProperty
importsOntology type ontology
hasSource type {ontology, goal, service, mediator}
hasTarget type {ontology, goal, service, mediator}
hasMediationService type {goal, service, 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 {service, goal, wgMediator, ggMediator}
hasTarget type {service, goal, ggMediator, wgMediator}
Class wwMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {service, wwMediator}
hasTarget type {service, wwMediator}
Class nonFunctionalProperty
hasAccuracy type accuracy
hasContributer type dc:contributor
hasCoverage type dc:coverage
hasCreator type dc:creator
hasDate type dc:date
hasDescription type dc:description
hasFinancial type financial
hasFormat type dc:format
hasIdentifier type dc:identifier
hasLanguage type dc:language
hasNetworkRelatedQoS type networkRelatedQoS
hasOwner type owner
hasPerformance type performance
hasPublisher type dc:publisher
hasRelation type dc:relation
hasReliability type reliability
hasRights type dc:rights
hasRobustness type robustness
hasScalability type scalability
hasSecurity type security
hasSource type dc:source
hasSubject type dc:subject
hastitle type dc:title
hasTransactional type transactional
hasTrust type trust
hasType type dc:type
hasVersion type version
|
[1] 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 where 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 were it
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 service
provider.
$Date: Friday 24 December 2004 - 16:41:14$