This document is also available in non-normative PDF version. The intent of the document is to be submitted to W3C.
This document presents an ontology called Web Service Modeling Ontology (WSMO) for describing various aspects related to Semantic Web Service. Having the Web Service Modeling Framework (WSMF) as a starting point, we refine this framework and develop a formal ontology and language.
WSMF [Fensel & Bussler, 2002] consists of four different main elements for describing semantic web services (see Figure 1): 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 problem.
| Figure 1. The main elements of WSMF |
 |
This document presents an ontology called Web Service Modeling Ontology (WSMO) for describing various aspects related to Semantic Web Service. Having the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002] as a starting point, we refine this framework and develop a formal ontology and language.
Section 2 presents global issues related to the elements that are considered in the ontology. Following the philosophy of WSMF, we further define in the next sections the ontologies (Section 3), goals (Section 4), mediators (Section 5) and web service (Section 6). In Section 7 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 8 presents our conclusions and further directions.
For a brief tutorial on WSMO we refer to the WSMO Primer [Arroyo & Stollberg, 2004] and 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].
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 a 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.
This section addresses issues that concern all subsequent sections, it is especially concerned with compliance to current web standards.
The vocabulary is fully extensible, being 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. Subsequent we allow the use of namespace abbreviations and its declaration.
The default namespace for the listings in this document is wsmo: http://www.wsmo.org/2004/d2/. Furthermore this document assumes the following namespace declarations:
In the remainder of this document the above prefixes denote the correspondingly defined URIs.
WSMO distinguishes 4 kinds of identifiers: URI references, Literals, Anonymous Ids and variables names; this general idea is taken from the RDF concepts [Manoler & Miller, 2004]:
In order to explicitly distinguish full URIs syntactically from QNames, we always use angle brackets to envelope full URIs, e.g. <http://www.wsmo.org/2004/d2>
<, > and function symbols like
+ or -). The XML Schema Definition [Biron & Malhotra, 2001] does this in an informal
way, we are currently using this to define the usual arithmetic
build-in operators used in the logical expressions (see Section 3.6)
Syntactically, in WSMO literals always start and end with quotes, e.g. 'WSMO working group' or 'http://www.wsmo.org/2004/d2'. This allows to distinguish between URIs and literals syntactically.
_#1, _#2, ...) or
unnumbered (_#). Anonymous Ids represent Identifier. The
same numbered Anonymous Id represents the same Identifier within the
same scope (logical-expression), otherwise Anonymous Ids
represent different Identifier [Yang & Kifer,
2003]. Anonymous Ids can be used to denote objects that exists, but
don't need an explicit identifier (e.g. if someone wants to say that a
Person john has a address _# which itself has a street name
"hitchhikerstreet" and a street number "42"), then the object of the
address itself does not need a own URI, but since it must exist as
connecting object between john and "hitchhikersstreet", "42" we can
denote it with an Anonymous Id). This concept is similar to blank nodes
in RDF [Hayes, 2004], however there are some
differences as outlined in the before mentioned paper [Yang & Kifer, 2003].?', followed by any positive number of symbols in
{a-z, A-Z, 0-9, _, -}, i.e. ?var or
?lastValue_Of.We classify non functional properties in two categories: core properties and web service specific properties.
The core properties can be used for all the modeling elements of WSMO.
They consist of the Dublin Core
Metadata Element Set [Weibel et al., 1998] plus the
version element. We do not enforce restrictions on the range
value type (and this also omit the range restriction in the following
listings) but in some cases provide additional recommendations. In case that
no WSMO recommendation is given, the Dublin Core rules apply as a default:
entity non-functional-properties
dc:title
dc:creator
dc:subject
dc:description
dc:publisher
dc:contributor
dc:date
dc:type
dc:format
dc:identifier
dc:source
dc:language
dc:relation
dc:coverage
dc:rights
version
|
dc:title will be
a name by which the element is formally known.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: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: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: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: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:date will be associated with the creation or
availability of the element.dc:type includes terms describing general categories,
functions, genres, or aggregation levels for 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: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: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:rights will contain a rights management statement for
the element, or reference a service providing such information. Rights
information often encompasses Intellectual Property Rights (IPR),
Copyright, and various Property Rights. If the Rights element is
absent, no assumptions may be made about any rights held in or over the
element.Besides the core properties described in the previous section, the web service specific non functional properties also include properties related to the quality aspect of a web service (QoS):
entity ws-non-functional-properties subentity-of non-functional-properties
accuracy
availability
financial
network-related-qoS
performance
reliability
robustness
scalability
security
transactional
trust
|
Further discussions on service specific non-functional-properties can be used during the service life cycle can be found in [O`Sullivan et al., 2002]. In conclusion, the web service specific non functional properties extend the common core properties (in Section 2.3.1) especially by quality of service aspects. Nonetheless, the model is extensible and more (even application-domain specific) aspects could be added.
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. An ontology is defined as follows:
entity ontology
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set oo-mediator
concept-definitions oftype set concept
relation-definitions oftype set relation
function-definitions oftype set function
instance-definitions oftype set instance
axiom-definitions oftype set axiom
|
The non-functional-properties of an ontology consist of the
core properties described in Section 2.3.1.
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. Import-ontologies allow a modular approach for
ontology design; this simplified statement can be used as long as no
conflicts need to be resolved, otherwise an oo-mediator 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 (oo-mediator) are used when an alignment of the
imported ontology is necessary. Mediators are described in Section 5 in more detail.
Concepts constitute the basic elements of the agreed upon 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 have several (possibly none) direct superconcepts as specified by the "is-a"-relation.
entity concept
super-concepts oftype set {concept, logical-concept}
attributes oftype set attribute
|
super-concepts for some concept. Being a subconcept of
some other concept in particular means that a concept inherits the
signature of this superconcept and the corresponding constraints.
Furthermore, all instances of a concept are also instances of its
superconcept. Additionally, we allow to use a finite number of
logical-concepts as super-concepts whereby
logical-concepts are similar to complex concept
expressions in Description Logics and consist basically of a symbol
representing a set of instances and a logical expression defining the
extension of the concept in a formal way.
entity logical-concept
defined-by oftype logical-expression
|
logical-expression (see Section 7) defining the
set of instances (the extension, resp.) of the complex concept.
The complex concept is represented by a constant with the same
name as the complex concept itself . The logical expression has
one of the following forms (assuming that the concept symbol is
denoted by C):
forall ?x ( ?x instanceOf C <-> log-expr
)forall ?x ( ?x instanceOf C -> log-expr
)forall ?x ( ?x instanceOf C <- log-expr
)where log-expr is an arbitrary logical
expression.
In the first case, one gives a necessary and sufficient
description of the extension of the complex concept, whereas in
the second case there is only a sufficient and in the third case
there is only a necessary description for set of instances of the
complex concept C.
attributes that represent named slots for data values for
instances that have to be filled at the instance level. An attribute
specifies a slot of a concept by fixing the name of the slot as well as
a logical constraint on the possible values filling that slot. Hence,
this logical expression can be interpreted as a typing constraint.
entity attribute subentity-of axiom
range oftype {concept, logical-concept}
|
Relations are used in order to model interdependencies
between several concepts (respectively instances of these concepts).
entity relation subentity-of axiom
super-relations oftype set {relation, logical-relation}
parameters oftype set parameter
|
relations of which the defined relation
is declared as being a subrelation. That particularly implies that 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. As
a superrelation one can use logical-relations as well,
which are similar to complex relation expressions in Description
Logics. Similar to the case of logical concepts, logical relations
basically consist of a predicate symbol (with the same name
P and the same arity n as the defined complex
relation) and a logical expression which defines the extension of the
complex relation formally:
entity logical-relation
parameters oftype set parameter
defined-by oftype logical-expression
|
parameter can be found
in Listing 7.logical-expression (see Section 7) defining the
set of instances (n-ary tuples, if n is the arity of the
relation) of the complex relation. The complex relation is
represented by an n-ary predicate symbol (where n is the number
of parameters of the complex relation) with the same name as the
complex relation itself . The logical expression has one of the
following forms (assuming that the relation symbol is denoted by
R):
forall ?x1, ...,?xn ( R(?x1,...,?xn) <->
log-expr )forall ?x1, ...,?xn ( R(?x1,...,?xn) -> log-expr
)forall ?x1, ...,?xn ( R(?x1,...,?xn) <- log-expr
)where log-expr is an arbitrary logical
expression.
In the first case, one gives a necessary and sufficient
description of the extension, whereas in the second case there is
only a sufficient and in the third case there is only a necessary
description for set of instances of the complex relation
R.
entity parameter subentity-of axiom
domain oftype {concept, logical-concept}
|
A function is a special relation, with a unary range and a n-ary domain
(parameters inherited from relation), where the
range specifies the return value. The (n+1)-ary relation which represents the
function has the property of being functional, i.e. there are no two
values v1 and v2 and a n-tuple t such that such that the function takes both
values as the range for the tuple as the parameter values.
entity function subentity-of relation
range oftype {concept, logical-concept}
|
Instances are either defined explictly 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:
entity instance
type oftype {concept}
|
concept to which the instance belongs to.For instances of relations (with arity n) we additionally need the parameter values which are assigned to this specific instance:
entity relation-instance
type oftype relation
values oftype set parameter-value
|
relation this instance belongs to.parametervalues defining the tuple
of values that are assigned to the instance of the relation. 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.
entity parameter-value
value oftype instance
|
A logical expression constraining the possible values that the parameter can take.
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].
An axiom-definition is considered to be a logical expression
together with its non functional properties.
entity axiom
non-functional-properties oftype non-functional-properties
defined-by oftype logical-expression
|
non-functional-properties of an axiom consist of the
core properties described in Section 2.3.1.Logical expressions are formal statements expressed in the language defined in Section 7.
In this section, we introduce the notion of goals and define
the elements that are used in the description of a goal. A Goal is defined as
follows:
entity goal
namespaces oftype set namespace
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set (oo-mediator or gg-mediator)
post-conditions oftype set axiom-definition
effects oftype set axiom-definition
|
non-functional-properties of a goal consist of the
core properties described in the Section
2.3.1.Post-conditions in WSMO describe the state of the
information space that is desired. Effects describe the state of the world that is
desired.In this section, we introduce the notion of mediators and
define the elements that are used in the description of a mediator.
We distinguish four different types of mediators :
gg-mediators: mediators that link two goals. This link
represents the refinement of the source goal into the target goal.oo-mediators: mediators that import ontologies and resolve
possible representation mismatches between ontologies.wg-mediators: mediators that link web service to goals.
They explicitly may state the difference between the two entities and map
different vocabularies (through the use of
oo-mediators).ww-mediators: mediators linking two Web Services.
The mediator is defined as follows:
entity mediator
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
source oftype set (ontology or goal or web-service or mediator)
target oftype (ontology or goal or web-service or mediator)
mediation-service oftype (goal or ww-mediator)
entity oo-mediator subentity-of mediator
source oftype set (ontology or oo-mediator)
entity gg-mediator subentity-of mediator
used-mediators oftype set oo-mediator
source oftype set (goal or gg-mediator)
target oftype (goal or gg-mediator)
entity wg-mediator subentity-of mediator
used-mediators oftype set oo-mediator
source oftype (web-service or wg-mediator)
target oftype (goal or gg-mediator)
entity ww-mediator subentity-of mediator
used-mediators oftype set oo-mediator
source oftype (web-service or ww-mediator)
target oftype (web-service or ww-mediator)
|
mediation-service points to a goal that declarative
describes the mapping or to a ww-mediator that links to a
web service that actually implements the mapping.gg-mediator,
wg-mediator and ww-mediator, use a set of
oo-mediators in order to map between different
vocabularies used in the description of goals and webservice
capabilites 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 used-mediators 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 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 web services, goals and ontologies.
In this section we identify the concepts needed for describing various
aspects of a web service. The following properties of a web service are
considered: namespaces, non-functional-properties,
import-ontologies, used-mediators,
capability and interfaces.
entity web-service
namespaces oftype set namespace
non-functional-properties oftype ws-non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set oo-mediator
capability oftype capability
interfaces oftype set interface
|
non-functional-properties of a web service are
described in Section 2.3.2.capability of a web service is described in Section 6.1.interfaces of a web service are described in Section 6.2.A capability defines the web service by means of its
functionality.
entity capability
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set (oo-mediator or wg-mediator)
preconditions oftype set axiom-definition
assumptions oftype set axiom-definition
postconditions oftype set axiom-definition
effects oftype set axiom-definition
|
non-functional-properties of a capability consist of
the core properties described in the Section
2.3.1.Pre-conditions in WSMO describe what a web service
expects for enabling it to provide its service. In other words, they
constrain the set of states of the information space such that each
state satisfiying these constraints can serve as a valid starting state
(in the information space) for executing the service in a defined
manner.Post-conditions in WSMO describe the states of the
information space that must be reached by executing the service.Assumptions in WSMO describe the expectation of the
service on the state of the world when starting an execution of the
service. The service garantuees the declared functionality only if it
is started in such a state. Thus, the assumptions constrain the set of
states of the world to the set of valid staring states.Effects describe the state of the world after that is
going to be reached after the execution of the service.An interface describes how the functionality of the service
can be achieved (i.e. how the capability of a service can be
fulfilled) by providing a twofold view on the operational competence of the
service:
choreography decomposes a capability in terms of
interaction with the service (service user's view)orchestration decomposes a capability in terms of
functionality required from other services (other service providers'
view)This distinction reflects the difference between communication and
cooperation. The choreography defines how to communicate with
the web service in order to consume its functionality. The
orchestration defines how the overall functionality is achieved
by the cooperation of more elementary service providers.
An interface is defined by the following properties:
entity interface
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set oo-mediator
choreography oftype choreography
orchestration oftype orchestration
|
non-functional-properties of an interface consist of
the core properties described in the Section
2.3.1.Choreography provides the necessary information for the
user to communicate with the web service (i.e. it describes how the
service works and how to access the service from the user's
perspective).Orchestration describes how the service works from the
provider's perspective (i.e. how a service makes use of other web
service or goals in order to achieve its capability).The distinction between choreography and
orchestration [1] should be considered in
the context of the role the service is playing in a conversation: provider or
requester. In case the service acts as a provider, the way of interacting
with it is specified in its choreography. If the service acts as a requester,
requesting functionalities of different services, then
are specified in the orchestration of the service.
As the major component of axiom-definition, logical
expressions are used almost everywhere in the WSMO model to capture specific
nuances of meaning of modeling elements or their consitutent 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 will be
defined formally by the WSML working group in a seperate document.
The language defines here basically is a first-order language, similar to First-order Logics [Enderton, 1972] and Frame Logic (F-Logic, resp.) [Kifer et al., 1995]. . In particular, we exploit the advanced object-oriented modeling constructs of F-Logic and reflect these constructs in our language.
We start with the definition of the basic vocabulary for building logical expression. Then we define the set of terms and the most basic formulas (atomic formulae, resp.) which allows us to eventually define the set of logical expressions.
Let URIbe 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.
The vocabulary V of our language L(V) consists of the following symbols:
(, ), ofType, ofType set,
memberOf, subConceptOf, hasValue,
hasValues, false, true.or,
and, not,
<-,->, <-> ,
forall, exists.S in FSym or PSym, we
assume that there is a corresponding arity
arity(S) defined, which is a non-negative integer specifying the
number of arguments that are expected by the corresponding symbol when
building expressions in our language.As usual, 0-ary function symbols are called constants. 0-ary predicate symbols correspond to propositional variables in classical propositional logic.
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).q in QN 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 imporant 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 this definition to the set of logical-expression (or formulae, resp.) L(V) (over vocabulary V) as follows:
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) .true and false are simple logical expression
in L(V) .P, T are terms in Term(V), then
P ofTypeT is a simple logical expression in
L(V) .P, T1,...,Tn,(1<= n) are
terms in Term(V), then P ofTypeset
(T1,...Tn) is a simple logical expression in L(V).O, T are terms in Term(V), then
O memberOfT is a simple logical expression in
L(V).C1,C2 are terms in Term(V), then
C1 subConceptOfC2 is a simple
logical expression in L(V).O, V are terms in Term(V), then
O hasValueV is a simple logical expression in
L(V).O, V1,...,Vn (1<= n) are
terms in Term(V), then OhasValues
{V1,...,Vn} is a simple logical expression in L(V).This definition is extended to complex logical-expression 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,not,<-,->,
<->}, then L1 op L2 is a logical expressionin
L(V).L is a logical expressionin L(V),
x is a variable from Var and Q is a
quantor in {forall, exists}, then Qx(L) is a
logical expressionin L(V).Notational conventions:
There is a precedence order defined for the logical connectives as
follows, where op1 < op2 means
that op2 binds stronger than op1:
<- ,->, <->
< or < and
< not.
The precedence order can be eploited when writing logical expressions in order to prevent from extensive use of parantheses. In case that there are ambiguities in evaluating an expression, parantheses must be used to resolve the ambiguities.
The terms P ofTypeset (T) and
OhasValues {V} (that means for the case n = 1 in
the respective clauses above) can be written simpler by omitting the
parantheses.
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 onotogies can be represented as follows: concepts can be represented as terms, relations as predicates, functions as predicates, instances as terms and variables as variables.
This document presented the Web Service Modeling Ontology (WSMO) for describing several aspects related to web services, by refining the Web Service Modeling Framework (WSMF). The definition of the missing elements (choreography and orchestration) will be treated separately, in seperate deliverables in the WSMO project.
[Arroyo & Stollberg, 2004] S. Arroyo and M. Stollberg (Eds.): WSMO Primer, WSMO Deliverable D3.1, DERI Working Draft, 2004, latest version available at http://www.wsmo.org/2004/d3/d3.1/.
[Baader et al., 2003] F. Baader, D. Calvanese, and D. McGuinness: The Description Logic Handbook, Cambridge University Press, 2003.
[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/.
[Dean et al., 2004] M. Dean, G. Schreiber, S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, and L. A. Stein: OWL Web Ontology Language Reference, W3C Recommendation, 10 February 2004. Available at http://www.w3.org/TR/2004/REC-owl-ref-20040210/.
[Enderton, 1972] H.B. Enderton: A Mathematical Introduction to Logic, Academic Press, 1972.
[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.
[Kifer et al., 1995] M. Kifer, G. Lausen, and J. Wu:Logical foundations of object-oriented and frame-based languages. Journal of the ACM, 42:741-843, July 1995.
[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.
[Manoler & Miller, 2004] F. Manola and E. Miller: RDF Primer, W3C Recommendation 10 February 2004, available at http://www.w3.org/TR/2004/REC-rdf-primer-20040210/.
[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.
[Pan & Horrocks, 2004] J. Z. Pan and I. Horrocks: OWL-E: Extending OWL with expressive datatype expressions. IMG Technical Report IMG/2004/KR-SW-01/v1.0, Victoria University of Manchester, 2004. Available from http://dl-web.man.ac.uk/Doc/IMGTR-OWL-E.pdf.
[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, SEKT, SWWS, and Esperonto; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program.
The editors would like to thank to all the members of the WSMO, WSML, and WSMX working groups for their advice and input into this document.
entity non-functional-properties
dc:title
dc:creator
dc:subject
dc:description
dc:publisher
dc:contributor
dc:date
dc:type
dc:format
dc:identifier
dc:source
dc:language
dc:relation
dc:coverage
dc:rights
version
entity ws-non-functional-properties
performance
reliability
security
scalability
robustness
accuracy
transactional
trust
financial
network-related-qoS
entity ontology
namespaces oftype set namespace
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set oo-mediator
concept-definitions oftype set concept-definition
relation-definitions oftype set relation-definition
function-definitions oftype set function-definition
instance-definitions oftype set instance-definition
variable-definitions oftype set variable-definition
axiom-definitions oftype set axiom-definition
entity concept-definition subentity-of axiom-definition
super-concepts oftype set concept-definition
attributes oftype set attribute-definition
entity attribute-definition subentity-of axiom-definition
range oftype axiom-definition
entity relation-definition subentity-of axiom-definition
parameters oftype set parameter-definition
entity relation-definition subentity-of axiom-definition
parameters oftype set parameter-definition
entity function-definition subentity-of axiom-definition
range oftype axiom-definition
parameters oftype set parameter-definition
entity variable-definition subentity-of axiom-definition
restriction oftype set concept-definition
entity axiom-definition
non-functional-properties oftype non-functional-properties
defined-by oftype logical-expression
entity goal
namespaces oftype set namespace
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set (oo-mediator or gg-mediator)
post-conditions oftype goalAxiomDefinition
effects oftype goalAxiomDefinition
entity mediator
namespaces oftype set namespace
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
source oftype set (ontology or goal or web-service or mediator)
target oftype set (ontology or goal or web-service or mediator)
mediation-service oftype (goal or ww-mediator)
entity oo-mediator subentity-of mediator
source oftype set (ontology or oo-mediator)
entity gg-mediator subentity-of mediator
used-mediators oftype set oo-mediator
source oftype set (goal or gg-mediator)
target oftype (goal or gg-mediator)
entity wg-mediator subentity-of mediator
used-mediators oftype set oo-mediator
source oftype (web-service or wg-mediator)
target oftype (goal or gg-mediator)
entity ww-mediator subentity-of mediator
used-mediators oftype set oo-mediator
source oftype (web-service or ww-mediator)
target oftype (web-service or ww-mediator)
entity web-service
namespaces oftype set namespace
non-functional-properties oftype ws-non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set oo-mediator
capability oftype capability
interfaces oftype set interface
entity capability
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set (oo-mediator or wg-mediator)
preconditions oftype set axiom-definition
assumptions oftype set axiom-definition
postconditions oftype set axiom-definition
effects oftype set axiom-definition
entity interface
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set oo-mediator
choreography oftype choreography
orchestration oftype orchestration
This Appendix describes the grammar for the Web Services Modeling Language (WSML). This language is meant for representing the concepts introduced in the Web Service Modeling Ontology (WSMO) in a human-readable way.
The language to write down this syntax is a variant of Extended Backus Nauer Form; a variant readable by ANTLR (Parr and Quong 1995). ANTLR is a tool that can construct recognisers, parsers and compilers from a grammar specification, it's functionality is (among others) similar to the well-known lex/yacc tools. Visit www.antlr.org for more information.
wsmoDefinition:
( nameSpaceDefinition
|
)
( ontologyDefinition
| webServiceDefinition
| goalDefinition
| mediatorDefinition
)* ;
nameSpaceDefinition:
( NAMESPACE
| NAMESPACEURI
)
( prefix )*
( TARGETNAMESPACE QNAME
|
) ;
ontologyDefinition:
ONTOLOGY QNAME
( nameSpaceDefinition
|
)
( nonFunctionalDefinition
|
)
( USEMEDIATOR QNAME ( COMMA QNAME )*
|
)
( conceptDefinition
| axiomDefinition
| instanceDefinition
| relationDefinition
| variableDefinition
| functionDefinition
)* ;
webServiceDefinition:
WEBSERVICE QNAME
( nameSpaceDefinition
|
)
( nonFunctionalDefinition
|
)
( USEMEDIATOR QNAME ( COMMA QNAME )*
|
)
( capabilityDefinition
|
)
( interfaceDefinition )* ;
goalDefinition:
GOAL QNAME
( nameSpaceDefinition
|
)
( nonFunctionalDefinition
|
)
( USEMEDIATOR QNAME ( COMMA QNAME )*
|
)
( ( POSTCONDITION
| EFFECT
)
axiomDefinition )+ ;
mediatorDefinition:
ooMediatorDefinition
| ggMediatorDefinition
| wgMediatorDefinition
| wwMediatorDefinition ;
prefix:
QNAME EQUAL QNAME ( COMMA QNAME )* ;
nonFunctionalDefinition:
NFP
( nonFunctionalBlock
| version
)*
ENDNFP ;
axiomDefinition:
AXIOM QNAME
( nonFunctionalDefinition
|
)
logicalExpression ;
ooMediatorDefinition:
OOMEDIATOR QNAME
( nameSpaceDefinition
|
)
( nonFunctionalDefinition
|
)
( SOURCE QNAME )* ( TARGET QNAME )*
( USESERVICE QNAME
|
) ;
ggMediatorDefinition:
GGMEDIATOR QNAME
( nameSpaceDefinition
|
)
( nonFunctionalDefinition
|
)
( SOURCE QNAME
|
)
( TARGET QNAME
|
)
( USEMEDIATOR QNAME ( COMMA QNAME )*
|
)
( REDUCTION axiomDefinition
|
) ;
wgMediatorDefinition:
WGMEDIATOR QNAME
( nameSpaceDefinition
|
)
( nonFunctionalDefinition
|
)
( SOURCE QNAME
|
)
( TARGET QNAME
|
)
( USEMEDIATOR QNAME ( COMMA QNAME )*
|
)
( REDUCTION axiomDefinition
|
) ;
wwMediatorDefinition:
WWMEDIATOR QNAME
( nameSpaceDefinition
|
)
( nonFunctionalDefinition
|
)
( SOURCE QNAME
|
)
( TARGET QNAME
|
)
( USEMEDIATOR QNAME ( COMMA QNAME )*
|
) ;
capabilityDefinition:
( USECAPABILITY QNAME )
| ( CAPABILITY QNAME
( nonFunctionalDefinition
|
)
( USEMEDIATOR QNAME ( COMMA QNAME )*
|
)
( ( PRECONDITION
| POSTCONDITION
| ASSUMPTION
| EFFECT
)
axiomDefinition )+ ) ;
interfaceDefinition:
( USEINTERFACE QNAME )
| ( INTERFACE QNAME
( nonFunctionalDefinition
|
)
( USEMEDIATOR QNAME ( COMMA QNAME )*
|
)
choreographyDefinition
( orchestrationDefinition
|
) ) ;
choreographyDefinition:
CHOREOGRAPHY PLACEHOLDER ;
orchestrationDefinition:
ORCHESTRATION PLACEHOLDER ;
conceptDefinition:
CONCEPT QNAME
( nonFunctionalDefinition
|
)
( SUBCONCEPT QNAME
|
)
( attributeDefinition )* ;
relationDefinition:
RELATION QNAME
( nonFunctionalDefinition
|
)
parameterDefinition ;
variableDefinition:
VARIABLE QNAME ( COMMA QNAME )* MEMBEROF NAME ;
functionDefinition:
FUNCTION QNAME
( nonFunctionalDefinition
|
)
( parameterDefinition )*
( rangeDefinition
|
) ;
attributeDefinition:
QNAME OFTYPE
( SET
|
)
QNAME ;
parameterDefinition:
PARAMETER QNAME OFTYPE QNAME ;
rangeDefinition:
RANGE QNAME OFTYPE QNAME ;
valueDefinition:
( HASVALUE value )
| ( HASVALUES value ( COMMA value )* ) ;
value:
literal
| QNAME ;
literal:
String ;
// At present logical expression are only represented as strings in the BNF grammar.
// The concrete grammar rules for the logical expressions are skipped in this version of
// the document for the sake of simplicity; instead we simply use strings as a data format
// for logial expressions. The corresponding rules will be integrated
// in the next version of this deliverable.
logicalExpression:
BEGINLOGIC String ENDLOGIC ;
nonFunctionalBlock:
QNAME
( QNAME
| literal
)
( COMMA
( QNAME
| literal
) )* ;
version:
VERSION
( QNAME
| literal
) ;
mSLComment : "comment:" ( ( '\n'
| '\r'
) )*
( '\n'
| '\r'
)
;
protected mNCBegin:
( mLowerCaseLetter
| mUnderscore
| mUpperCaseLetter
);
protected mLowerCaseLetter:
'a'..'z';
protected mUnderscore : '_';
protected mUpperCaseLetter:
'A'..'Z';
protected mNCRest:
( mNCBegin
| mPOINT
| mDash
| mHash
| mSlash
| mAmp
| mQuestion
| mDigit
| mTilde
| mSemiColon
);
protected mPOINT : '.';
protected mDash : '-';
protected mHash : '#';
protected mSlash : '/';
protected mAmp : '&';
protected mQuestion : '?';
protected mDigit : '0'..'9';
protected mTilde : '~';
protected mSemiColon : ';';
protected mNCName:
mNCBegin
( mNCRest
| mCOLON
)*;
mCOLON : ':';
mQNAME : mNCName;
protected mURICharacters:
mNCRest
| mEQUAL
| mCOLON
| '%';
mEQUAL : '=';
mEQUALQNAME:
mEQUAL mNCBegin ( mURICharacters )+;
mNAMESPACEURI:
mNAMESPACE ' ' mNCBegin ( mURICharacters )+;
mNAMESPACE : "namespace";
mCOMMA : ',';
mString : '"' ( ~'"' )* '"';
mTARGETNAMESPACE : "target-namespace";
mUSEMEDIATOR : "used-mediator";
mOOMEDIATOR : "oo-mediator";
mGGMEDIATOR : "gg-mediator";
mWGMEDIATOR : "wg-mediator";
mWWMEDIATOR : "ww-mediator";
mSOURCE : "source";
mTARGET : "target";
mUSESERVICE : "use-service";
mREDUCTION : "reduction";
mGOAL : "goal";
mWEBSERVICE : "webservice";
mUSECAPABILITY : "use-capability";
mCAPABILITY : "capability";
mPRECONDITION : "precondition";
mPOSTCONDITION : "postcondition";
mASSUMPTION : "assumption";
mEFFECT : "effect";
mUSEINTERFACE : "use-interface";
mINTERFACE : "interface";
mCHOREOGRAPHY : "choreography";
mORCHESTRATION : "orchestration";
mPLACEHOLDER : "***";
mONTOLOGY : "ontology";
mCONCEPT : "concept";
mSUBCONCEPT : "subconcept-of";
mOFTYPE : "oftype";
mSET : "set";
mINSTANCE : "instance";
mMEMBEROF : "member-of";
mHASVALUE : "hasvalue";
mHASVALUES : "hasvalues";
mRELATION : "relation";
mPARAMETER : "parameter";
mFUNCTION : "function";
mVARIABLE : "variable";
mMETHOD : "method";
mRANGE : "range";
mAXIOM : "axiom";
mBEGINLOGIC : "logical-expression";
mENDLOGIC : "end-logical-expression";
mVERSION : "version";
mNFP : "non-functional-properties";
mENDNFP : "end-non-functional-properties";
[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 were they are really profitable in. All other processes are
sourced out and consumed as eServices. They advertise their services in their
capability and choreography description and they advertise their needs in the
orchestration interfaces. This enables on-the-fly creation of virtual
enterprises in reaction to demands from the market place. Even in the
dinosaurian time of eCommerce where large companies still exist,
orchestration may be an important aspect. The
orchestration of a service may not be made public but may be
visible to the different departments of a large organization that compete for
delivering parts of the overall service. Notice that the actual business
intelligence of a service provider is still hidden. It is his capability to
provide a certain functionality with a chorography that is very different
from the sub services and their orchestration. The ability for a certain type
of process management (the overall functionality is decomposed differently in
the choreography and the orchestration) is 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 web
service provider.
$Date: 2004/07/21 19:30:08 $