This document is also available in non-normative PDF version.
Copyright © 2004 DERI®, All Rights
Reserved. DERI liability,
trademark, document use, and software licensing rules apply.
This document presents an ontology called Web Service Modeling Ontology (WSMO) for describing various aspects related to Semantic Web Service. Having the Web Service Modeling Framework (WSMF) [Fensel & Bussler, 2002] as a starting point, we refine this framework and develop a formal ontology and a formal language.
The WSMF [Fensel & Bussler, 2002] consists of four different main elements (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 interoperability problem.
| Figure 1. The main elements of WSMF |
 |
Section 2 presents golbal issues related to the elements that are considered in the ontology. Following the philosophy of WSMF, we further refine 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 intentions.
WSM0 distinguishes 3 kinds of identifiers: URI references, Literals and Anonymous Ids, this general idea is lent from the RDF concepts [Manoler & Miller, 2004]:
_#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 and 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 streetname
"hitchhikerstreet" and a streetnumber "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).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 are defined globally, meaning that they can be used
for all the modeling elements of WSMO Standard. They consist of the Dublin Core Metadata Element
Set [Weibel et al.] plus the version
element. We do not enforce restrictions on the range value type, but in some
cases provide additional recommendations:
concept non-functional-properties
dc:title oftype dc:title
dc:creator oftype set dc:creator
dc:subject oftype set dc:subject
dc:description oftype set dc:description
dc:publisher oftype set dc:publisher
dc:contributor oftype set dc:contributor
dc:date oftype dc:date
dc:type oftype set dc:type
dc:format oftype set dc:format
dc:identifier oftype dc:identifier
dc:source oftype set dc:source
dc:language oftype set dc:language
dc:relation oftype set dc:relation
dc:coverage oftype set dc:coverage
dc:rights oftype set dc:rights
version oftype version
|
dc:title will be
a name by which the element is formally known.dc:creator include a person, an
organization, or a service. 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. 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. Typically, the name of a
dc:contributor should be used to indicate the entity.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):
concept non-functional-properties
performance oftype performance
reliability oftype reliability
security oftype security
scalability oftype scalability
robustness oftype robustness
accuracy oftype accuracy
transactional oftype transactional
trust oftype trust
financial oftype financial
networkRelatedQoS oftype networkRelatedQoS
|
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.
In principle, an ontology constitutes of four main building blocks:
concepts, relations, axioms and
instances. An ontology is defined as follows [1]:
concept ontology
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set oo-mediator
concept-defintions oftype set concept-definition
relation-defintions oftype set relation-definition
function-defintions oftype set function-definition
instance-defintions oftype set instance-defintion
variable-defintions oftype set variable-defintion
axiom-defintions oftype set axiom-definition
|
non functional properties of an ontology consist of
the core properties described in Section 2.2.1.Import ontologies allow a
modular approach for ontology design, this simplified statement can be
used as long no conflicts need to be resolved, a
oo-mediator needs to be used.oo-mediator) when an alignment of the imported ontology
is necessary.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 so-called "is_a"-relation. When describing the semantics of concepts within some ontology, we favor a uniform and rather general approach: we consider the semantics to be captured by means of a logical expression.
Such modeling styles are commonly used in many Description Logics [Baader et al., 2003] and can be found in widely-used ontology languages like OWL [Dean et al., 2004] as well.
Hence, we extract the following abstract description for concepts:
concept concept-definition subconcept-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.attributes that represent named slots for data
values and 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.
concept attribute-definition subconcept-of axiom-definition
range oftype axiom-definition
|
Relations are used in order to model interdependencies
between several concepts (respectively instances of these concepts).
concept relation-definition subconcept-of axiom-definition
parameters oftype set parameter-definition
|
concept parameter-definition subconcept-of axiom-defintion
domain oftype axiom-definition
|
parameters), where the range specifies the
return value.
concept function-defintion subconcept-of axiom-definition
range oftype axiom-definition
parameters oftype set parameter-definition
|
instances
defined for some concept. Therefore we have to reflect the
“instance_of”-relation that can be given within an
ontology specification.
concept instance-definition oftype axiom-definition
instance-of oftype set concept-definition
attribute-values oftype set attribute-value-definition
|
concept attribute-value-definition sobconcept-of axiom-definition
value oftype axiom-definition
|
Instances may as well be defined by a link to an instance store, that means there is no necessity to define all the instances in the way presented above, but to allow to make a reference to a database containing the information. This database should be associated with a namespace and connected via a Mediator, such that a build-in relation can be used within that namespace to retrieve instances.
concept retrieve
restriction oftype logical-expression
instance oftype set logical-expression
|
concept-defintion, leading to the retrieval of
all instances of this particular concept.restriction.concept variable-definition subconcept-of axiom-definition
restriction oftype set concept-defintion
|
Restriction that that limits the possible values
of the variable to instances of the concept defined in this
restriction.axiom-definition is considered to be a logical
expression.
concept axiom-definition
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.2.1.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:
concept goal
non-functional-properties oftype non-functional-properties
used-mediators oftype set (oo-mediator or gg-mediator)
post-conditions oftype set axiomDefintion
effects oftype set axiomDefinition
|
non functional properties of a goal consist of the
core properties described in the Section 2.2.1
(where, in this case, an element in the core properties is equivalent
to a goal).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 :
Figure 3 below illustrates the relation between different types of mediators, goals, web services and ontologies.
| Figure 3. Illustration of mediators in WSMO |
 |
The mediator is defined as follows:
concept mediator
non-functional-properties oftype non-functional-properties
source-component oftype set (ontology or goal or service or mediator)
target-component oftype set (ontology or goal or service or mediator)
mediation-service oftype (goal or ww-mediator)
concept oo-mediator subconcept-of mediator
source-component oftype set (ontology or oo-mediator)
concept ggMediator subconcept-of mediator
sourceComponents oftype set (goal or gg-mediator)
targetComponent oftype (goal or gg-mediator)
usedMediators oftype set oo-mediator
concept wgMediator subconcept-of mediator
sourceComponent oftype (service or wg-mediator)
concept targetComponent oftype (goal or wg-mediator)
usedMediators oftype set oo-mediator
reduction oftype axiomDefinition
concept wwMediator subconcept-of mediator
sourceComponent oftype (webService or ww-mediator)
targetComponent oftype (webService or ww-mediator)
usedMediators oftype set oo-mediator
|
mediation service points to a goal that declarative
describes the mapping or to a wwMediator that links to a web service [2] that actually implements the mapping.In this section we identify the concepts needed for describing various
aspects of a web service. From a complexity point of view of the description
of a web service, the following properties of a web service are considered:
non functional properties, used mediators,
capability and interfaces.
concept service
non-functional-properties oftype non-functional-properties
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.2.2.capability of a web service is described in Section 6.1.interfaces of a web service are described in Section 6.2.The grounding of a web service (i.e. the mapping from the abstract specification to a concrete specification of the elements that describe a web service, which are required for interacting with the service) will be specified in the choreography and orchestration, as they are the only elements where grounding is needed.
A capability defines the web service by means of its
functionality.
concept capability
non-functional-properties oftype non-functional-properties
usedMediators oftype set (ooMediator or wgMediator)
preconditions oftype set axiomDefinition
postconditions oftype set axiomDefinition
assumptions oftype set axiomDefinition
effects oftype set axiomDefinition
|
non functional properties of a capability consist of
the core properties described in the Section 2.2.1
(where, in this case, an element in the core properties is equivalent
to a capability).Pre-conditions in WSMO describe what a web service
expects for enabling it to provide its service. They define conditions
over the input.Post-conditions in WSMO describe what a web service
returns in response to its input. They define the relation between the
input and the output.Assumptions are similar to pre-conditions, however, also
reference aspects of the state of the world beyond the actual
input.Effects describe the state of the world after the
execution of the service.The purpose of defining again pre-conditions, post-conditions, assumptions, effects, non functional properties and used mediators in the service capability is to have self-contained web service descriptions, that can be referred or not to the defined goals.
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)With this distinction we provide different decompositions of
process/capabilities to the top (service requester) and to the bottom (other
service providers). 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:
concept interface
non-functional-properties oftype non-functional-properties
usedMediators oftype set ooMediator
choreography oftype choreography
orchestration oftype orchestration
|
non functional properties of an interface consist of
the core properties described in the Section
2.2.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 [3] 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.
The choreography in WSMO is further defined in Deliverable 14: Choreography in
WSMO.
The orchestration in WSMO is further defined in Deliverable 15: Orchestration in
WSMO.
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).
[Baader et al., 2003] F. Baader, D. Calvanese, and D. McGuinness: The Description Logic Handbook, Cambridge University Press, 2003.
[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, 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/.
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[Fowler, 2003] M. Fowler: UML Distilled: A Brief Guide to the Standard Object Modeling Language, Addison-Wesley, 3rd edition, 2003.
[Gruber, 1993] T. Gruber: A translation approach to portable ontology specifications,Knowledge Acquisition, 5:199-220, 1993.
[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.
[Manoler &Miller, 2004]F. Manola, E. Miller: RDF Primer, W3C Recommendation 10 February 2004, available at http://www.w3.org/TR/2004/REC-rdf-primer-20040210/.
[Oren et al, 2004] Oren, E. (Ed.): BNF grammar for WSML language., WSMO Deliverable D16.1 v0.2, Working Draft 12 June 2004 avaliable at: http://www.wsmo.org/2004/d16/d16.1/v0.2/20040612/.
[Parr & Quong] Parr, T.J. and R.W. Quong: ANTLR: A predicated-LL(k) parser generator. Software, Practice and Experience, 25(7), pp. 789-810, Jul 1995.
[Rajesh & Arulazi, 2003] S. Rajesh and D. Arulazi: Quality of Service for Web Services-Demystification, Limitations, and Best Practices, March 2003. (See http://www.developer.com/services/article.php/2027911.)
[Rumbaugh et al., 1998] J. Rumbaugh, I. Jacobson, and G. Booch: The Unified Modeling Language Reference Manual, Object Technology Series, Addison-Wesley, 1998.
[Stollberg et al., 2004] M.Stollberg, H. Lausen, A. Polleres, E. Lara (Eds.): WSMO Use Case Modeling and Testing, WSMO Working Draft, 28 June 2004, available at: http://www.wsmo.org/2004/d3/d3.2/v0.1/20040628/.
[Weibel et al. 1998] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf: RFC 2413 - Dublin Core Metadata for Resource Discovery, September 1998.
[Yang and Kifer, 2003] G. Yang, 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, Esperonto, and h-TechSight; 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 working group for their advice and input into this document.
concept non-functional-properties
dc:title oftype dc:title
dc:creator oftype set dc:creator
dc:subject oftype set dc:subject
dc:description oftype set dc:description
dc:publisher oftype set dc:publisher
dc:contributor oftype set dc:contributor
dc:date oftype dc:date
dc:type oftype set dc:type
dc:format oftype set dc:format
dc:identifier oftype dc:identifier
dc:source oftype set dc:source
dc:language oftype set dc:language
dc:relation oftype set dc:relation
dc:coverage oftype set dc:coverage
dc:rights oftype set dc:rights
version oftype version
concept non-functional-properties
performance oftype performance
reliability oftype reliability
security oftype security
scalability oftype scalability
robustness oftype robustness
accuracy oftype accuracy
transactional oftype transactional
trust oftype trust
financial oftype financial
networkRelatedQoS oftype networkRelatedQoS
concept ontology
non-functional-properties oftype non-functional-properties
import-ontologies oftype set ontology
used-mediators oftype set oo-mediator
concept-defintions oftype set concept-definition
relation-defintions oftype set relation-definition
function-defintions oftype set function-definition
instance-defintions oftype set instance-defintion
variable-defintions oftype set variable-defintion
axiom-defintions oftype set axiom-definition
concept concept-definition subconcept-of axiom-definition
super-concepts oftype set concept-definition
attributes oftype set attribute-defintion
concept attribute-definition subconcept-of axiom-definition
range oftype axiom-definition
concept relation-definition subconcept-of axiom-definition
parameters oftype set parameter-definition
concept parameter-definition subconcept-of axiom-defintion
domain oftype axiom-definition
concept function-defintion subconcept-of axiom-definition
range oftype axiom-definition
parameters oftype set parameter-definition
concept instance-definition oftype axiom-definition
instance-of oftype set concept-definition
attribute-values oftype set attribute-value-definition
concept attribute-value-definition sobconcept-of axiom-definition
value oftype axiom-definition
concept retrieve
restriction oftype logical-expression
instance oftype set logical-expression
concept variable-definition subconcept-of axiom-definition
restriction oftype set concept-defintion
concept axiom-definition
non-functional-properties oftype non-functional-properties
defined-by oftype logical-expression
concept goal
non-functional-properties oftype non-functional-properties
used-mediators oftype set (oo-mediator or gg-mediator)
post-conditions oftype set axiomDefintion
effects oftype set axiomDefinition
This Apendix describes the grammar for the Web Services Modelling Language (WSML). This language is meant for representing the concepts introduced in the Web Service Modelling Ontology (WSMO) in a human-readable way.
This document specifies unambiguously the syntax for WSML. The semantics of WSML will be described in other documents, yet to be written. 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.
As this is a draft version, certain issues have not yet been resolved. Some of these issues come from the fact that WSMO is also work in progress, so not all concepts have been defined completely yet; some of these issues are not related to WSMO as such, but are modelling decisions regarding only the language syntax. For completeness, we will name these outstanding issues explicitly:
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 EQUALURI ( COMMA QNAME EQUALURI )*
;
nonFunctionalDefinition
: NFP ( oneOrMoreQNAMES )*
( VERSION
( QNAME
| literal
)
|
)
;
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 )* ( methodDefinition )*
;
instanceDefinition
: INSTANCE QNAME MEMBEROF QNAME ( QNAME valueDefinition )*
;
relationDefinition
: RELATION QNAME
( nonFunctionalDefinition
|
)
parameterDefinition
;
variableDefinition
: VARIABLE QNAME ( COMMA QNAME )* MEMBEROF NAME
;
functionDefinition
: FUNCTION QNAME
( nonFunctionalDefinition
|
)
( parameterDefinition )*
( rangeDefinition
|
)
;
attributeDefinition
: QNAME OFTYPE
( SET
|
)
QNAME
;
methodDefinition
: METHOD
( nonFunctionalDefinition
|
)
( parameterDefinition )*
( rangeDefinition
|
)
;
parameterDefinition
: PARAMETER QNAME OFTYPE QNAME
;
rangeDefinition
: RANGE QNAME OFTYPE QNAME
;
valueDefinition
: ( HASVALUE value )
| ( HASVALUES value ( COMMA value )* )
;
value
: literal
| QNAME
;
literal
: String
;
logicalExpression
: BEGINLOGIC String ENDLOGIC
;
oneOrMoreQNAMES
: QNAME
( QNAME
| literal
)
( COMMA
( QNAME
| literal
) )*
;
mWS
: ( ' '
| '\n'
| '\t'
| '\r'
)+
;
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 POINT : '.' ;
protected Dash : '-' ;
protected Hash : '#' ;
protected Slash : '/' ;
protected Amp : '&' ;
protected Question : '?' ;
protected Digit : '0'..'9' ;
protected Tilde : '~' ;
protected SemiColon : ';' ;
protected NCName :
NCBegin
( NCRest
| COLON
)*
;
COLON : ':' ;
QNAME
: NCName ;
protected URICharacters
: NCRest
| EQUAL
| COLON
| '%'
;
EQUAL : '=' ;
EQUALURI
: EQUAL ( ' ' )* NCBegin ( URICharacters )+
;
NAMESPACEURI
: NAMESPACE ( ' ' )* NCBegin ( URICharacters )+
;
NAMESPACE : "namespace" ;
COMMA : ',' ;
String : '"' ( ~'"' )* '"' ;
TARGETNAMESPACE : "target-namespace" ;
USEMEDIATOR : "used-mediator" ;
OOMEDIATOR : "oo-mediator" ;
GGMEDIATOR : "gg-mediator" ;
WGMEDIATOR : "wg-mediator" ;
WWMEDIATOR : "ww-mediator" ;
SOURCE : "source" ;
TARGET : "target" ;
USESERVICE : "use-service" ;
REDUCTION : "reduction" ;
GOAL : "goal" ;
WEBSERVICE : "webservice" ;
USECAPABILITY : "use-capability" ;
CAPABILITY : "capability" ;
PRECONDITION : "precondition" ;
POSTCONDITION : "postcondition" ;
ASSUMPTION : "assumption" ;
EFFECT : "effect" ;
USEINTERFACE : "use-interface" ;
INTERFACE : "interface" ;
CHOREOGRAPHY : "choreography" ;
ORCHESTRATION : "orchestration" ;
PLACEHOLDER : "***" ;
ONTOLOGY : "ontology" ;
CONCEPT : "concept" ;
SUBCONCEPT : "subconcept-of" ;
OFTYPE : "oftype" ;
SET : "set" ;
INSTANCE : "instance" ;
MEMBEROF : "member-of" ;
HASVALUE : "hasvalue" ;
HASVALUES : "hasvalues" ;
RELATION : "relation" ;
PARAMETER : "parameter" ;
FUNCTION : "function" ;
VARIABLE : "variable" ;
METHOD : "method" ;
RANGE : "range" ;
AXIOM : "axiom" ;
BEGINLOGIC : "logical-expression" ;
ENDLOGIC : "end-logical-expression" ;
VERSION : "version" ;
NFP : "non-functional-properties" ;
[1] Such an ontology actually represents a metaontology.
[2] Notice that the capability of this web service will also provide a declarative description of this mapping; however, in addition a link to an implementation of the mapping is provided, too.
[3] 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 he
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: Friday 09 July 2004 - 13:07:53$