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) [Fensel & Bussler, 2002] 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, goal repositories that define the problems that should be solved by web services, web services descriptions that define various aspects of a web service and mediators which bypass 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). Section 7 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].
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 3 kinds of identifiers: URI references, Literals and Anonymous Ids; this general idea is taken from the RDF concepts [Manoler & Miller, 2004]:
<, > 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.11)._#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 afore mentioned paper [Yang & Kifer, 2003].
Non functional properties are defined as a set of tuples, where each tuple consists of a property and its value constraint. We classify non functional properties in two categories: core properties and web service specific properties.
The core properties 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:
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 consensual real world semantics intended by humans with computers. 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 consensual terminology by providing concepts and relationships among the set of concepts. In order to capture semantic properties of relations and concepts, an ontology generally also provides a set of axioms, which means expressions in some logical framework. An ontology is defined as follows:
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
|
They define prefixes for elements defined in the ontology.
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 consensual 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-definition subentity-of axiom-definition
super-concepts oftype set concept-definition
attributes oftype set attribute-defintion
|
super-concepts for some concept. In particular, being a
subconcept of some other concept 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.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-definition subentity-of axiom-definition
range oftype axiom-definition
|
Relations are used in order to model interdependencies
between several concepts (respectively instances of these concepts).
entity relation-definition subentity-of axiom-definition
parameters oftype set parameter-definition
|
entity parameter-definition subentity-of axiom-definition
domain oftype axiom-definition
|
A function symbol is a special relation, with a unary range and a n-ary
domain (parameters), where the range specifies the return
value.
entity function-defintion subentity-of axiom-definition
range oftype axiom-definition
parameters oftype set parameter-definition
|
Instances are defined by a link to an instance store. This instance store (i.e. a database, a flat text file, etc.) should be associated with a namespace and connected via an ooMediator, such that a build-in relation can be used within that namespace to retrieve instances.
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].
Variables itself are identified with URIs, they are declared and typed globally, however their scope is always locally (within one logical-expression). Additional type restrictions (e.g. within the scope of a logical-expression) are interpreted as conjunction, such that a type can be refined but never broadened.
entity variable-definition subentity-of axiom-definition
restriction oftype set concept-definition
|
Restriction limits the possible values of the variable
to instances of the concept defined in this restriction, as it is done
in sorted logic [Enderton, 1972].An axiom-definition is considered to be a logical expression
together with its non functional properties.
entity
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.Most elements in the WSMO Ontology model are entities derived from
axiom-definition.
As the major component of axiom-definition, logical
expressions are used almost everywhere in the WSMO Ontology 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 brief
description of the formal language that is used for specifying
logical-expressions.
The language define here basically is a first-order language, similar to First-order Logics [Enderton, 1972] and Frame Logic (F-Logic, resp.) [Kifer et al., 1995]. That means basically, that we allow variables to be used in formal statements that represent individuals of some domain (or universe, resp.) and provide the means to represent computations within the domain by means of terms (using function symbols and variables). In particular, we exploit the advanced object-oriented modeling constructs of F-Logic and reflect these constructs in our language.
Following common practice in the definition of logical languages, in particular First-order Logic and F-Logic, 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 formulaes or F-molecules, resp.).
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.
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.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).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.
Note: The definition covers the usual case of variables as well since the set of variable symbols Var is a subset of URI.
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 logical-expression in L(V) 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 logical expression in L(V) .true and false are logical expression in
L(V) .P, T are terms in Term(V), then
P oftypeT is a logical expression in
L(V) .P, T1,...,Tn,(1<=n) are
terms in Term(V), then P oftypeset
(T1,...Tn) is a logical expression in L(V).O, T are terms in Term(V), then
O memberOfT is a logical expression in
L(V).C1,C2 are terms in Term(V), then
C1 subConceptOfC2 is a logical
expression in L(V).O, V are terms in Term(V), then
O hasValueV is a logical expression in
L(V).O, V1,...,Vn (1<= n) are
terms in Term(V), then OhasValues
{V1,...,Vn} is a logical expression in L(V).L is a logical expression in L(V) , then
not L is a logical expression.L1 and L2 are logical expressions in
L(V) and op is one of the junctors in
{or,and,not,<-,->,
<->}, then L1 op L2is a logical expression.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 expression.The logical expressions defined in the first part of the bulleted list is commonly called atomic logical expressions or atomic formulae.
Notational conventions: There is a precedence order
defined for the logical junctors 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 form 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.
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
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 (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.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. The constraints refer to the input values of a service.Post-conditions in WSMO describe the states of the
information space that will be reached by executing the service. In
particular, they describe what a web service returns in response to its
input and define the relation between the input and the output of a
service execution.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. In fact,
assumptions are similar to pre-conditions, however, they also reference
aspects of the state of the world beyond the actual input.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.
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 other documents, and consists of work to be done for the future.
[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/.
[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.
[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, 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: Wednesday 21 July 2004 - 00:15:11$