D1.

1 BPMO Requirements Analysis and Design

Zhixian Yan1 , Emilia Cimpian1 , Manuel Mazzara2 , Michal Zaremba1
1

Digital Enterprise Research Institute

Leopold F ranzens U niversit
at Innsbruck
Austria
{rstname.lastname}@deri.org
2

Distributed Systems Group

Inf ormation Systems Institute
V ienna U niversity of T echnology
Austria
{lastname}@infosys.tuwien.ac.at

Abstract
This deliverable is concerned with Semantic Business Process Management (abbreviated as SBPM), especially its cornerstone Business Process Modeling Ontology (BPMO).
Basically, the document focuses on the requirements analysis and design of BPMO, which
is considered as the semantic description framework for business process in the SemBiz
project. To determine the description requirements for business process management, we
analyze business use cases from the industrial partners and abstract a generalized process
scenario. For realizing the determined requirement list, we propose the comprehensive
BPMO framework, and nally make it feasible with the extension of the semantic Web
service description framework WSMO. Although the main framework for BPMO has been
determined, some details may be modied in the following period, based on the BPMO real
implementation with the use cases provided by the industrial partners.

List of Abbreviations
ARIS
ASM
BPEL
BPEL4WS
BPM
BPMI
BPML
BPMN
BPMO
BPO
BPQL
BPR
KIF
OWL
OWL-S
PSL
SBPM
SESA
SOA
SWSF
SWSI
SWSL
SWSO
UML
WfMC
WS-CDL
WSCI
WSCL
WSDL
WSMF
WSML
WSMO
WSMT
WSMX
YAWL

Architecture of Integrated Information Systems

Abstract State Machine
Business Process Execution Language
Business Process Execution Language for Web Services
Business Process Management
Business Process Modeling Initiative
Business Process Modeling Language
Business Process Modeling Notation
Business Process Modeling Ontology
Business Process Ontology
Business Process Query Language
Business Process Reengineering
Knowledge Interchange Format
Web Ontology Language
OWL for Services
Process Specification Language
Semantic Business Process Management
Semantically-Enabled Service-oriented Architecture
Service-Oriented Architecture
Semantic Web Services Framework
Semantic Web Services Initiative
Semantic Web Services Language
Semantic Web Services Ontology
Unified Modeling Language
Workflow Management Coalition
Web Service Choreography Description Language
Web Service Choreography Interface
Web Service Conversation Language
Web Service Description Language
Web Service Modeling Framework
Web Service Modeling Language
Web Service Modeling Ontology
Web Service Modeling Tool
Web Service Modeling eXecution environment
Yet Another Workflow Language

Contents
1

Introduction

1.1

Semantic Business Process Management . . . . . . . . . . . . . . . . . . . . .

1.2

Business Process Modeling Ontology . . . . . . . . . . . . . . . . . . . . . .

State-of-the-Art

2.1

Non-Semantic Process Modeling Approaches . . . . . . . . . . . . . . . . . .

2.1.1

Workow, Business Process Reengineering and Management . . . . . .

2.1.2

Web Services, Service-Oriented Architecture (SOA) . . . . . . . . . .

Semantic Process Modeling Approaches . . . . . . . . . . . . . . . . . . . . .

2.2.1

Semantically-Enhanced Workow Model . . . . . . . . . . . . . . . .

2.2.2

Semantic Business Process . . . . . . . . . . . . . . . . . . . . . . . .

2.2.3

Semantic Web Services, SESA . . . . . . . . . . . . . . . . . . . . . .

Academic Foundations of Process Modeling . . . . . . . . . . . . . . . . . . .

10

2.3.1

Petri Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.3.2

Abstract State Machine . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.3.3

Process Algebra, Pi-Calculus . . . . . . . . . . . . . . . . . . . . . . .

11

2.3.4

Temporal Logic, Transaction Logic . . . . . . . . . . . . . . . . . . .

11

2.3.5

AI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.2

2.3

Requirements Analysis for BPMO

13

3.1

Process Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.2

Process Description Requirements . . . . . . . . . . . . . . . . . . . . . . . .

14

3.2.1

Concepts Involved in Business Processes . . . . . . . . . . . . . . . .

14

3.2.2

Functional Requirements for Process Description . . . . . . . . . . . .

16

3.2.3

Nonfunctional Requirements for Process Description . . . . . . . . . .

17

BPMO Design

19

4.1

Why Semantic Web Service for BPMO . . . . . . . . . . . . . . . . . . . . .

19

4.2

Why WSMO for BPMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

4.3

How to Extend WSMO for BPMO . . . . . . . . . . . . . . . . . . . . . . . .

25

4.3.1

Extension Highlights . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.3.2

BPMO UML Diagram . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.3.3

BPMO Element Denition . . . . . . . . . . . . . . . . . . . . . . . .

26

Conclusions and Future Steps

30

Outline
This outline is intended to partially integrate the index, giving the reader some additional
information on the content of the sections in such a way he could read only those parts relevant
for his specic purposes.
In the rst section, a general introduction on Semantic Business Process Management (SBPM)
and its cornerstone Business Process Modeling Ontology (BPMO) is given. In the second
section, we provide an overview of the state of the art on business process modeling approaches
and their inuence on the emerging semantically-enhanced business process management.
With the analysis of considered approaches and business scenarios presented, the third section
determines the description requirements for SBPM. The extension of Web Service Modeling
Ontology (WSMO) to realize BPMO will be addressed in the last main section of this deliverable based on the requirements previously extracted. Finally, we add some conclusive remarks
and future directions.

1 Introduction
In this section, we give a general introduction for the context of the SemBiz project, especially
the main idea of Semantic Business Process Management and its cornerstone Business Process
Modeling Ontology.

1.1

Semantic Business Process Management

Business Process Management (BPM) refers to managing IT-supported business operations

from a business experts perspective rather than from a technical perspective. Numerous technologies and tool suites are providing BPM support, ranging from graphical workow design
tools to complex IT systems for automated execution support of business processes. However,
the degree of automation and support for the business experts perspective in existing BPM technologies is still very limited, which results in a gap between the business perspective and the
technical level for IT-supported business process execution. Therefore, in order to bridge the
gap between the business and the technical perspective, the SemBiz project (fully named Semantic Business Process Management for exible dynamic value chains) proposes Semantic
Business Process Management (SBPM), which enables BPM by business people rather than IT
experts and allows scaling up to a new level of complexity in querying, discovery and composition of processes. Figure 1 gives an intuitional demonstration of the bridging-gap role of
SBPM between business level and technical level [23]

Figure 1: Idea of Semantically Enabled Business Process Management

To really bridge the gap between business perspective and technical perspective, SBPM in
the SemBiz project has the following objectives:
develop an exhaustive semantic description framework for business processes that allows
BPM by business experts on a higher level of abstraction as well as support for automated
handling and execution of business processes on the technical level;
develop semantically enabled core facilities for novel aspects of BPM that can be supported by semantic descriptions, i.e.: browsing, editing, discovering, and composing semantically described business processes;
develop a prototypical tool suite that utilizes the techniques developed for semantically
enabled BPM and allows business experts to handle and manage business processes;
3

 test and evaluate the usability and applicability of the developed tools in a real world use
case scenario in the telecommunication sector.

1.2

Business Process Modeling Ontology

From the previous general introduction of SBPM, we can realize that the sematic description
for business processes plays a crucial role in the whole SBPM proposal. In the SemBiz project,
one of the three main objectives is to dene a semantic business process description framework,
named Business Process Modeling Ontology and abbreviated as BPMO. Basically, the BPMO
framework can be considered as the starting point and cornerstone for the SBPM vision.
The aim of BPMO is to dene a precise and sufcient semantic description model for business processes that encompasses business process description on a higher level of abstraction in
order to enable business level BPM facilities as well as connection to the technical implementation level for supporting automated execution of business processes. Ontologies shall be used as
the underlying data model in order to ensure semantic interoperability and advanced information processing, meaning that all element descriptions as well as all information interchanged
are based on ontologies. Besides an adequate semantic description model for business processes
themselves, additional constructs are required for the BPMO with respect to the business level
BPM facilities to be supported: Goals and Queries as the underlying notions for semantically
enabled querying, discovery, and composition of business processes, and Mediators for handling possibly occurring mismatches between business processes and other resources needed
for executing these. The detailed BPMO framework will be dened in the deliverable and improved in the future period. Basically, there are at least following four core tasks for the BPMO
framework:
determine requirements of semantic business process descriptions;
dene design strategies of BPMO;
determine specication languages for BPMO;
allow recursive denition and specication of the BPMO elements.

2 State-of-the-Art
In this section, we will briey survey the state of the art of process modeling technologies,
including both non-semantic and semantic relevant approaches. There are many approaches
supporting process modeling, referring to workow and Web services. Besides the relevant
industrial standards, we further provide some concentration on the academic foundations for
process modeling.
Although providing a state of the art analysis is not one of this deliverables objective, we
consider that getting familiar with the current approaches is one of the pre-requisites in providing
a solid, well-documented set of requirements.

2.1

Non-Semantic Process Modeling Approaches

The focuses of traditional process modeling are pervasively on providing graphic-based tools
to design processes, such as Unied Modeling Language (UML) diagram, Business Process
Modeling Notation (BPMN) and Event-driven Process Chains (EPCs). Besides the graphical
modeling tools, language-based process description is another main focus, and in particular,
modeling language Business Process Modeling Language (BPML), querying language (BPQL)
and executing language (BPEL).
The graphical process modeling can be traced back to workow, and then gradually evolve
into Business Process Reengineering (BPR) and Business Process Management (BPM); for the
description and execution of processes, several Web service approaches can be used as building
blocks, among which Business Process Execution Language for Web Services (BPEL4WS) is
one of the representatives. To fully support process interoperability, there are several studies
about web service cooperation, such as Web service choreography, orchestration and conversation.
2.1.1

Workow, Business Process Reengineering and Management

About process modeling, traditional workow technology has been researched for many years,
and gradually improved and evolved into business process reengineering and business process
management, which provides more powerful description capabilities and efcient process modeling and management strategies.
Workow
Workow [52] has a long research history, which can be traced back to some ofce automation systems developed in 1970s, such as the emergence of SCOOP1 (developed by Michael
Zisman) and OfceTalk2 (developed by Skip Ellis and Gary Nutt). In August 1993 the Workow Management Coalition (WfMC)3 was founded, aiming to standardize the process research,
including workow and BPM. Workow in WfMC is dened as:
1

http://scoop.cim.com.au/
http://www.joops.com/
3
http://www.wfmc.org/
2

The automation of a business process, in whole or part, during which documents,

information or tasks are passed from one participant to another for action, according to a set of procedural rules.
Furthermore, workow management systems are responsible for dening, executing and
monitoring the workow. The workow patterns can be used for the analysis, comparison and
reuse of workows. Aalst et al. have surveyed the patterns and assigned them to three categories
[51], i.e. control-ow patterns, data patterns and resource patterns.
Business Process Reengineering (BPR)
Different from workow, BPR is further concerned with automating and re-engineering
existing works, which was yielded from the claim in the Harvard Business Review by Michael
Hammer in 1990 [21]. The claim was about companies focusing issues, which are not to
make non-value adding works but to automate and re-engineer existing works. Therefore,
BPR is a management approach aiming at improvements by means of elevating efciency and
effectiveness of the processes that exist within and across organizations. Its a fundamental and
radical approach by either modifying or eliminating non-value adding activities. To achieve the
fully-edged automation vision, many existing workow techniques, especially process design,
can be reconsidered as the basis for process reengineering [25].
Business Process Management (BPM)
Besides process redesigning and automating, BPM is concerned with much more than workow and BPR, such as the efcient design, quality documentation and the effective change
management. Howard Smith called BPM the third wave [48], which is not business-process
reengineering, enterprise application integration, workow management or another packaged
application, but the synthesis and extension of all these technologies and techniques into a unied whole. Process modeling became more mature as the evolution from workow to BPM
took place. The main difference between them is their perspectives: workow is a purely technical perspective to model process ow, focusing on message sequences; whilst BPM pays
more attention on business perspective, to maximize enterprise efciency and agility. Besides
the documentation (or message)-centric capability of workow, BPM has a process-centric controlling layer, to support higher-level integrations. BPM encompasses a robust Workow, Enterprise Application Integration (EAI), B2B integration and concepts such as Business Process
Re-engineering (BPR), Business Process Automation (BPA) and Business Process Integration
(BPI). In a nutshell, BPM is business-driven covering more than a set of process related technologies.
2.1.2

Web Services, Service-Oriented Architecture (SOA)

Web service research also provides some process modeling supports, especially some grounding technologies. SOA further takes services as the building blocks for system integration
architecture for reusing and automating services in software engineering.

Web Services
A Web service is a service that is available over the web, supporting communication between
applications; the Web service technologies had signicantly boosted the Web to dynamic Web.
A commonly-recognized denition of Web services is: Web service is a platform-independent,
loosely coupled, self-contained web-enabled application, which is described, published, discovered, coordinated and congured using XML artifacts for the purpose of developing distributed
interoperable applications [14]. There are three cornerstones for attaining interaction between
different programs: Simple Object Access Protocol (SOAP), Web Service Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI). The three standards cornerstones are respectively taking charge of service communication protocol, service
description and service discovery.
For the process technologies like workow and BPM, Web services play a crucial role, especially in the nal process execution duration. Combined with Web services, BPM could become
a new breed of software automating processes both intra- and inter- enterprises. BPEL4WS
is a representative of such convergence, which becomes industrial and the de-facto standard for
business process execution. Thus, Web service can be seen as the building blocks for the process
technologies in current industrial and academic process world. Some existing works on service
interoperability, such as service coordination, service conversation and service composition, can
further demonstrate the building block role of Web services for the process technologies. To express it more clearly, we briey discuses the two kinds of service interoperation interfaces service orchestration and service choreography.
Orchestration provides a central process acting as the controller of several involved Web services, and describes how those Web services can interact with each other to attain a more comprehensive and integrated service [4]. As mentioned, BPEL4WS has emerged as the de-facto
standard to dene and manage business process activities and business interaction protocols for
collaborating Web services.
Choreography utilizes a set of message exchanging between the participating services to
consume a process [40]. There are several corresponding languages, such as Web Service
Choreography Language (WSCL)4 , Web Service Choreography Interface (WSCI)5 and Web
Service Choreography Description language (WS-CDL)6 .
Service-Oriented Architecture (SOA)
SOA is a next evolutionary step for companies and allows both internal and external system
integration as well as the exible reuse of application logic through the rearrangement of Web
services [37]. A common understanding of SOA is that it expresses a perspective of software
architecture that denes the use of loosely coupled software services to support the requirements
of the business processes and software users7 . With the combination of BPM, SOA can get a
more business-enhanced perspective along the technical lines, aiming at a perfect combination
for enterprise computing [1]. BPM without SOA is useful for building applications, but difcult
to extend to the enterprise; SOA without BPM is useful for creating reusable and consistent
services, but lacks the ability to turn those services into an agile, competitive enterprise [8].
4

http://www.w3.org/TR/wscl10/
http://www.w3.org/TR/wsci/
6
http://www.w3.org/TR/ws-cdl-10/
7
http://en.wikipedia.org/wiki/Service-oriented architecture
5

2.2

Semantic Process Modeling Approaches

Compared with so many non-semantic approaches for business processes, semantic process
methodologies are still in their infancy stage. In contrast to the previous section, we will discuss
the considered semantic approaches according to the reference division of workows, business
processes and Web services.
2.2.1

Semantically-Enhanced Workow Model

There is not much research on the semantically enhanced workow model. Most of the works
focus on the semantic description or ontology extension of workow. We will briey address
two distinguish research projects and the Process Specication Language (PSL).
The project m3pe8 is referring to workow ontology extension, the goal of which is workow interoperability: to understand, reason, and schedule workows in different languages [19].
To attain such goal, there are two basic steps: rst, to map from internal workow models to the
intermediary formal mode; then, to generate choreography interfaces. Recently, the researchers
on this project have further proposed m3po (multi meta-model process ontology) as the linking
ontology for internal and external business processes [20].
The NextGRID9 project, aims to develop the architecture for Next Generation Grids,
proposing a workow-centric Grid Virtual Infrastructure Model. Based on OWL-S, a new ontology OWL-WS (OWL for Workow and Services) is proposed to support semantic workow
and Web service description [7].
Besides those workow-based ontologies for individual projects, PSL [10] is intended to
be a commonly recognized process representation language that is pervasive to all business and
management applications, and powerful enough to represent the process in any given applications. To achieve this semantic interoperability, PSL acts as a modular, extensible rst-order
logic ontology capturing concept requirements and business process specication. The PSL
ontology can be described by KIF (Knowledge Interface Format)10 .
2.2.2

Semantic Business Process

To the best of our knowledge, there are two distinguished researches referring to semantic business process ontology.
The rst process ontology named BPO, from Karlsruhe AIFB11 , aims to enhance Petri-net
process model with semantic descriptions, which can further facilitate process composition,
simulation and validation [29]. Processes modeled by Petri-Net and represented in the OWL
language, together with the background ontology modeled in UML and translated into OWL,
can be semantically aligned to support (semi-)automatic interconnectivity and reduce the communication efforts [13].
The second process ontology called BPMO, a more comprehensive exisiting one, is the
considering ontology to realize SBPM, which combines semantic Web service technologies
8

http://www.m3pe.org/
http://www.nextgrid.org/
10
http://logic.stanford.edu/kif/dpans.html
11
http://www.aifb.uni-karlsruhe.de/Publikationen/Forschungsgebiete/viewForschungsgebietenglish?fgebiet id=124
9

(WSMO in particular) and BPM methodologies (especially ARIS12 - Architecture of Integrated

Information Systems) [23]. Through the analysis of relevant competency questions, the BPMO
ontology framework proposes a set of ontologies and formalisms, involving basic ontology UPO
(Upper-Level-Ontology) and three primary extension ones (sEPC Ontology, sBPMN Ontology
and sBPEL Ontology)[22] [24].
2.2.3

Semantic Web Services, SESA

Semantic Web services technology acts as an integrated approach combining semantic Web and
Web service, further realizing the vision of the next generation of Web [43]. This new Web
will be enhanced in both semantic and behavior level, and will achieve more intelligent and
automatic service. There are many considerable researches towards semantic Web services, and
we will briey review the following four representatives.
WSMF: WSMO/WSML/WSMX
Web Service Modeling Framework (WSMF) was provided as a fully-edged framework to
model semantic Web services [17]. To attain full potential of the web, from a collection of information into a distributed device of computation, WSMF gives two main principles (maximal
de-coupling complemented by scalable mediation service) and four elements (ontology, goal,
Web service and mediator) to model any aspects related with the services denition and usage.
To nally enable the framework, a set of corresponding technologies has been developed, such
as the modeling ontology WSMO 13 [45], the description language WSML 14 [16], and the
execution environment WSMX 15 [35].
OWL-S
Web Ontology Language for Web Services (OWL-S), part of the DAML Program16 , species a set of ontologies based on OWL to describe different aspects of a semantic Web service
[3]. There are three core ontologies, i.e. service prole, service model and grounding. Service
prole presents what a service does; service model describes how a service works ; service
grounding supports how to access it via detailed specications of message formats, protocols
and so forth (normally expressed in WSDL). All the three ontologies are linked to the top-level
concept Service, which serves as an organization point of reference for declaring Web services;
the properties presents, describedBy, and supports of Service link to the above three core
ontologies respectively.
SWSF
Semantic Web Services Framework (SWSF) is a specication produced by the SWSL
Committee17 of the Semantic Web Service Initiative (SWSI). SWSF has its own conceptual
model Semantic Web Service Ontology (SWSO) and relevant language Semantic Web Service
12

http://www.pera.net/Methodologies/ARIS/ARIS Paper by Ted Williams.html

http://www.wsmo.org/
14
http://www.wsmo.org/wsml/
15
http://www.wsmx.org/
16
http://www.daml.org/
17
http://www.daml.org/services/swsl/
13

Language (SWSL). SWSO has been inuenced by OWL-S and adopts its three ontologies, i.e.
service prole, model and grounding. The difference and the key contribution of SWSO are its
rich behavioral process model, based on PSL. With such extensions, SWSO can support more
powerful descriptions and reasoning on Web services. SWSL has two sub-sets, SWSL-FOL
and SWSL-Rules, supporting rst-order-logic and logic programming respectively [5].
WSDL-S
Web Service Description Language - Semantics (WSDL-S), developed by the Meteor-S
group at the LSDIS Lab 18 , proposes a mechanism to augment WSDL with semantics, in particular focusing on the services functional descriptions. Based on the WSDL, WSDL-S has the
advantage of attaining semantics building on existing Web services; in the meantime, it does not
dictate a specic language for semantic description [6].

2.3

Academic Foundations of Process Modeling

During the previous section, we have discussed many different considered approaches and relevant standards for process modeling, including both graphic-modeling tools and language-based
descriptions, considering non-semantic as well as semantic approaches. Besides industrialcentric approaches, there are some formal techniques as the result of academic contribution.
In this section, we provide a concise introduction of those formal approaches and their relations to process modeling. For more detailed information, please refer to the related references
afterward.
2.3.1

Petri Net

Petri net, introduced by Carl Adam Petri in 1962 in his PhD thesis, is a promising tool for
describing and studying systems that are characterized as being concurrent, asynchronous, distributed, parallel, nondeterministic, and/or stochastic [36]. Formally, a Petri net is a directed
bipartite graph with nodes (places and transitions) and arcs, which provides formal semantics
for further process analysis. In addition to the three basic elements (i.e. places, transitions, and
arcs) on classic Petri Nets, there are many extensions to get more powerful description capability, like supporting color, time, hierarchy etc.
Due to the formal foundation for concurrency modeling, Petri nets are suitable for modeling,
simulating and analyzing business processes. On particular, its rather straightforward to model
workow using Petri nets, and many research activities are focusing on this. Among those
researches, tasks are modeled by transitions, conditions are modeled by places, and cases are
modeled by tokens. Furthermore, many analysis techniques can be utilized in the analysis and
validation of processes. As discussed in Section 2.2.2, Petri net model is represented in the
OWL language to realize semantic business process ontology called BPO.
2.3.2

Abstract State Machine

Abstract State Machine, ASM for short, provides means to describe systems in an unambiguous
way using a semantically well founded mathematical notation. The core constituents are the
18

http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/

10

notation, the ground model technique and the renement principle [18]. There are two main
categories in ASM, namely, Basic ASM and Multi-Agent ASM. Based on the minimality of
modeling primitive, the maximality of modeling expressive, and the formality, ASM has been
chosen as the underlying model for modeling WSMO interface, especially service choreography.
2.3.3

Process Algebra, Pi-Calculus

Process algebras, also called process calculi, are a family of approaches to formally model concurrent systems. Upon those models, it is possible to describe the interactions, communications
and synchronizations between processes [9]. With the development of process algebra, many
detailed algebras appear, such as CCS (Calculus of Communicating System), CSP (Communicating Sequential Processes) and ACP (the Algebra of Communicating Processes). The most
recent addition to the process algebras family is pi-calculus, which was invented by Robin Milner as a formal language for concurrent computational processes. The pi-calculus provides a
framework for the representation, simulation, analysis and verication of mobile communication systems [47].
Recent results have shown that the pi-calculus is well suited for modeling classical workows, also known as service orchestrations, as well as service choreographies that together form
a core foundation of future BPM [41] [46]. While most recent standards like BPEL, BPMN, or
WS-CDL only tackle the problem from a practical side, a formal foundation for BPM is still
missing. Pi-calculus has its own advantages to take charge of this role, as described in [32].
2.3.4

Temporal Logic, Transaction Logic

Some logic-based formalizations can also be used for process modeling, such as Temporal Logic
and Transaction Logic.
Temporal logic has been broadly used as a general logic for representing and reasoning about
temporal information. Basically, temporal logic extends classical logic with modal operators
denoting a temporal modier, such as the necessity operator and the possibility operator [34].
Temporal logic is also a formal approach for process modeling. For example, we can model
tasks in a process as: not executing, executing, done, aborted, and committed; events in a process
can be modeled as forcible, rejected and delayable. Additionally, temporal logic can be used for
process mining and verication [50].
Transaction Logic was developed by Anthony J. Bonner and Michael Kifer. It is an extension of predicate logic that accounts for state changes in databases and logic programs. Several
variants of transaction logic have been developed, which differentiate themselves by the expressive power and computational complexity of the reasoning tasks [11]. Some approaches propose
using transaction logic for modeling, executing and reasoning on workows (or processes), especially one of the extensions called currency transaction logic [27] [12].
2.3.5

AI Model

In [30], the authors present a formal framework for the representation of enterprise knowledge
with business processes. The framework is largely based on AI and its concepts (objectives and

11

goals, roles and actors, actions and processes, responsibilities and constraints) allowing business
analysts to capture enterprise knowledge in an intuitive and formal way.
An agent-based infrastructure for managing business processes was provided in [26],
demonstrating the key technologies of negotiating, service providing, autonomous agents, and
further applying them in the British Telecom business process.
In addition to those generalized AI methodologies, there are some detailed algorithms for
process management, such as case-based reasoning for workow model [33] and AI planning
for Web service composition [28]. Considering some formalization as the pre-requisites (such
as the planning domain, initial world, goals etc.), service composition can benet from several
planning paradigms, such as state-based planning, graph-based planning, partial order renement, planning as satisablity, and planning as logic programming [28].

12

3 Requirements Analysis for BPMO

Considering the different process modeling approaches discussed in the state of the art, in this
section, we will focus on the requirement analysis for semantic business process description
BPMO, and in particular the extension mechanisms of WSMO to realize BPMO.

3.1

Process Scenario

For the requirement analysis for BPMO we have to consider not only the current state of the art
in process representation, but also to analyze process use cases in the some real-world applications. HANIVAL19 and eTel20 are the two industrial partners in the SemBiz project. HANIVAL
proposes an application scenario for business process within its own order-billing and provisioning system for the chillydomains platform; eTel provides the Product Ordering use-case
21 . They both use popular graphic modeling techniques, like EPC or BPMN, to describe their
detailed process scenario. From these two scenarios we abstract the generalized scenario for
business process (shown in Figure 2). We can use this abstract scenario to analyze and derive the description requirements for semantic business processes, and nally develop BPMO
(Business Process Modeling Ontology).
As shown in Figure 2, the main and nal aim of the scenario is to achieve a given business
goal. Firstly, the system tries to nd the exact matching process for such a goal, and execute it
directly if exists. However, it is frequent that no such exact-matching business process exists for
the given goal. In this case, we have to decompose the goal into sub-goals, and query relevant
business processes for each sub-goal. We can loop this query procedure, until we reach an
indecomposable goal/sub-goal. If there are still no matching processes for this goal, we will
create a new process for the indecomposable goal, or adapt/modify existing processes. Finally,
according to the certain business logic and relevant business rules, we compose the relevant
business processes and invoke them at a certain sequence to achieve the whole business goal
given before.
Although the above process scenario is abstract and simplied, many process description
requirements can be extracted. For process description requirements, we have the following two
obvious questions:
How to describe the business process to improve the soundness and efciency of process
discovery, composition and nally invocation?
How to describe the business goal, business rules and business logic to assist the invocation of business process?
More inward and detailed requirements will be discussed in the next section.
19

http://www.hanival.net/
http://www.etel.at/
21
As we are still in an early phase of the project we consider these small application scenarios as our starting point,
but more complex scenarios will be analyzed as soon as they become available
20

13

Figure 2: Generalized Use Case Scenario for Business Processes

3.2

Process Description Requirements

By analyzing the real-world process use cases and the abstract process scenario, we will derive
the description requirements for the business processes modeling. Firstly, the involved concepts
will be overviewed and summarized; secondly, the functional description requirements will
be discussed; last but not least, some non-functional requirements for business processes are
proposed.
3.2.1

Concepts Involved in Business Processes

Requirement Engineering is a branch of software engineering which has many arbitrary techniques to elicit the requirements before the system development [38]. The commonly recognized
rst step is trying to dene system boundaries, stakeholders, goals, and tasks etc. Hereby, to determine the process descriptions requirements more completely, we apply relevant requirement
14

engineering techniques. We overview all the involved concepts in the whole business process
scenario, summarize them and provide relevant classication.
From the real-world use cases and the abstract scenario mentioned above, there are several
concepts involved: business goal, business rules, business process and business data. Basically,
most information can be classied into two categories, i.e. business-related and process-related,
which are consistent with the two questions in Section 3.1.
Business-Related Concepts:
business goal: the nal business objectives;
business rule (also called business logic): business rules are abstractions of the policies
and practices of a business organization, which affect the execution path for inter- or
intra- business processes; business rules can evaluate the data provided by the process
and control the basis for change in (business processes) ows;
business roles: to nally achieve the business goal, peoples (organization in enterprises),
hardware (equipments or machines), or software (application programs) are involved in
the process execution, taking some responsibilities in executing the process;
business data: a lot of information is exchanged during the process scenario and relevant
models are needed to describe them; generally, business data include business messages,
relevant events and time records, and all relevant document resources involved in the
whole business process lifecycle can be classied into and modeled with such concept.
Process-Related Concepts:
process component: the core element during the whole process scenario; the process can
be seen as a map of ow controls, which may be an un-dividable atomic activity or an
integrated one involving many sub-business processes/activities, decisions and loops;
process interaction: interaction is unavoidable during the process execution; we can distinguish between two possible interaction modes: one is with business-related concepts
such as user interaction, and the other is with other business processes such as process
composition. For the sake of simplicity, we call the former interaction process interface
and the later one process interoperation
Basically, a fully-edged description meta-model should be provided, which ought to consider all the involved concepts, namely business goal, business role, business rule, business data,
process component and process interaction. We can infer the following main requirements referring to the involved concepts. To make the requirements more clear, we make the requirements
list and mark them with certain serial numbers. The following R1 and R2 will mainly focus on
the related concepts description requirements for the business process.

15

R1: The business-related concepts should be clear and concisely represented

As mentioned, there are four main concepts referring to the business, i.e. business goal,
business rule, business role, and business data. Accordingly, there are four sub-requirements to
concisely represent those business-related concepts.
R1.1: Representation of the business goal;
the nal aim for the execution of business processes.
R1.2: Representation of the business rules;
the business logic inuencing the process execution, especially to make choices and provide
a logic sequential for process execution.
R1.3: Representation of the business role;
organization ontology, involving people, software, hardware.
R1.4: Representation of the business data;
all the relevant data involved in the whole life cycle of business process, such as documentation, messages, events.
R2: The process-related concepts should be clear and concisely represented.
There are two main process-related concepts, i.e. the process itself and the process interaction.
R2.1: Representation of the business process as a (or part of a) process component
We can classify business process as according to the granularity in the two categories. The
rst one consists of atomic processes, i.e processes that can not be divided; the second category
consists of processes composed by other processes involving certain logical constructs such as
sequential, parallel, choice, loop, split, join etc. Furthermore, we can build upon those logic
constructs for business processes referring to the workow patterns, especially control-ow
based patterns.
R2.2: Representation of the interaction requirements for business processes
There are two kinds of interactions: one is between business process and the involving business role; the other is between processes themselves. The former can be compared to Web
service choreography, considering process interface interaction to invoke the process and attain
the goal from the process execution; the later can be compared to Web service orchestration,
considering process functionality composition to achieve integrated business processes. This
distinction is rather important only if we consider that a domain expert (human user) is going to be involved in the process execution. However, if we consider the automatic execution of
processes, it is not important who is actually interacting with the process, but only how the interaction takes place, and from this point of view the business process execution is different from
the semantic Web service execution, and overall its description can be considered equivalent
with the description of a semantic Web service choreography.
3.2.2

Functional Requirements for Process Description

According to the denitions in requirement engineering, functional requirements specify specic behaviors of a system, involving the internal work on the software to nally realize the use
16

case [2]. With the above two kinds of concepts involved in the process scenario, most functional
requirements of process description can be determined and specied.
Taking the above concepts description requirements (R1 and R2) as the footstone, further
functional requirements are needed to describe the specic behavior of business processes. From
the business process use cases and abstract scenarios mentioned in section 3.1, there are three
main functional behaviors during the life cycle of business process, i.e. process discovery,
process composition and process invocation. Therefore, we will analyze the functional requirements for business process management according to this classication.
Process Discovery, Process Composition, Process Invocation:
R3: Functional descriptions needed for process discovery have to be included in process
specication
To query the matched processes for the goal/sub-goal, a certain match model between the
goal and the process is required. Basically the input/output parameters of the process are needed
to match the processes and the goal. On the meanwhile, a certain query language is needed to
match processes and goals.
R3.1: Representation of the process query language
R3.2: Representation of matching between business goals
R3.3: Representation of matching between business process and business goal
R3.4: Representation of legacy process (how to re-describe existing processes modeled by
traditional methods, like EPC, BPMN etc.)
R4: Functional descriptions needed for process composition have to be included in process specication
To match a complex goal, the relevant processes ought to be integrated together according
to certain logic, such as concurrency, sequence or loop etc. Many workow patterns and other
composition techniques can be rened for process composition.
R4.1: Representation of composition language, referring to R2.1integrated process
R5: Functional descriptions needed for process execution have to be included in process
specication
To nally achieve the business goal, processes should be invoked with certain grounding
technology. For example, Web services can be considered as the building blocks for nal process
execution. Therefore, Web services should be wrapped and further described as the process
activities.
R5.1: Representation of grounding language, referring to BPEL4WS
3.2.3

Nonfunctional Requirements for Process Description

In addition to the functional requirements, there are also some non-functional requirements
playing important roles in software engineering. Typical non-functional requirements are some

17

specic criteria used to evaluate the quality of the system, such as the reliability, scalability, and
costs [15] [49].
To completely realize the business process, there are also some non-functional information
needed to be modeled, such as process quality and process compensation (the error port, the
substitute for traditional ACID transaction, security, and reputation etc).
R6: Nonfunctional descriptions referring to the process quality have to be modeled
R7: Nonfunctional descriptions referring to the process security, robustness, and compensation have to be modeled
There are broad description requirements for complete process modeling during the whole
process life cycle. In a nutshell, there are three main description requirements for BPMO,
i.e. the concepts involved in the business process life cycle, the functional requirements for
business process, and the non-functional requirements with additional process information to
assist successful business goal achievement.

18

4 BPMO Design
This section presents the initial design for Business Process Modeling Ontology. It starts with
an argumentation for using semantics for modeling business processes, and a justication for
choosing WSMO as the starting point for BPMO. It continues by presenting the relevant WSMO
concepts for BPMO, and by proposing several adjustments and modications that would allow
the business process modeling.

4.1

Why Semantic Web Service for BPMO

With the survey on the various process modeling approaches and the analysis of the process description requirements discussed above, we argue for the importance of Web services to nally
achieve automatic process. In detailed, the Web service technologies can be considered as the
building blocks for business process, and in particular the nal process execution. The objective involving semantics in Web services is to enable automatic service discovery, composition,
invocation, interoperation etc. In order to fulll this objective, in [31] the authors provide a set
of requirements for semantic Web services. Generally, business processes have similar requirements for automatic process discovery, composition, invocation, and monitoring. Therefore,
semantic Web services specication can be rened and enhanced for business processes, and
nally realize a semantic framework to describe business processes.

4.2

Why WSMO for BPMO

As discussed in Section 2.2.3, there are many existing semantic Web services approaches. However, we chose to use WSMO as the starting point for various reasons:
it is currently (one of) the most complete and consistent ontology for all semantic Web
services related aspects. WSMO consists of four main modeling elements, as presented
further in this section; the WSMO Web Service description constitutes the starting point
for process representation.
the representation language used by WSMO (WSML) allows the modeling of both semantic Web service capability and behavior, and from our initial investigations it can also
be used for representing any process related aspects. WSML is based on different logical formalisms, namely, Description Logics, First-Order Logic and Logic Programming,
and consists of a number of variants based on these different logical formalisms, namely
WSML-Core, WSML-DL, WSML-Flight, WSML-Rule and WSML-Full. For the rst
version of BMPO we will use the WSML-Core variant as the simplicity for the implementation, which corresponds with the intersection of Description Logic and Horn Logic
(without function symbols and without equality), extended with datatype support in order
to be useful in practical applications.
there exist already a reference implementation for WSMO, namely WSMX, which provides a set of decoupled components with different functionalities, like discovery, mediation or invocation of SWS; WSMX can be considered our starting point in modeling the
BPMO Suite.
19

In the next subsection we will provide a brief overview of the Web Service Modeling Ontology.
WSMO top Level Elements
Based on WSMF, WSMO proposes an overall framework for semantic Web services description considering four top level elements, involving Ontologies, Web services, Mediators
and Goals (a graphical representation of the WSMO top level elements shown in Figure 3):
Ontologies provide the terminology used by other WSMO elements to describe the relevant aspects of the domains of discourse.
Goals express the objectives that a client wants to achieve by invoking a Web service.
Web Services describe the computational entity providing access to services that provide
some value in a domain. These descriptions comprise the capabilities, interfaces and
internal working of the Web service.
Mediators resolve the possible heterogeneity problems between the other elements.

Figure 3: WSMO four top level elements

WSMO refers to the set of concepts it denes as elements. The general denition of an element is given in Listing 1. For presenting the following detailed WSMO elements denition, we
use the semantic Web service modeling language WSML, which provides the human readable
syntax.

Listing 1: WSMO Element Denition

C l a s s wsmoElement
hasAnnotation type a n n o t a t i o n

Annotations are entities used in dening the WSMO elements. The set recommended by
WSMO consists of most of the elements from [53], such as contributor, creator, date, description, identier, language, publisher, source, title, etc.
Ontologies
Ontologies provide the terminology used by other WSMO elements to describe the relevant
aspects of the domains of discourse. Listing 2 depicts the WSMO denition of an ontology.
20

Listing 2: WSMO Ontology Denition

C l a s s o n t o l o g y subC l a s s wsmoElement
importsOntology type ontology
usesMediator type ooMediator
hasConcept type concept
h a s R e l a t i o n type r e l a t i o n
hasFunction type f u n c t i o n
h a s I n s t a n c e type i n s t a n c e
h a s R e l a t i o n I n s t a n c e type r e l a t i o n I n s t a n c e
hasAxiom t y p e axiom

As ontologies can become quite complex, WSMO offers support for modularization. As
such, an ontology can import another ontology as long as no heterogeneity conicts need to
be solved. If heterogeneity problems exists, an ooMediator can be used (more about WSMO
mediators can be found subsequently) to perform an alignment of the imported ontology.
In WSMO concepts represent the basic elements of the ontologies. A concept (Listing 3)
can contain attributes with names and types and it could be a sub-concept of other concepts (the
isA relation).

Listing 3: Concept Denition

C l a s s c o n c e p t subC l a s s wsmoElement
hasSuperConcept type concept
h a s A t t r i b u t e type a t t r i b u t e
h a s D e f i n i t i o n t y p e l o g i c a l E x p r e s s i o n m u l t i p l i c i t y = s i n g l e v a l u e d

The attributes are dened as shown in Listing 4 and they can be lled at instance level.
The denition is a logical expression that can be used to formally describe the semantics of
the concept, i.e. the logical expression denes or restricts the extension (the instances) of this
concept.

Listing 4: Attribute Denition

C l a s s a t t r i b u t e subC l a s s wsmoElement
hasRange type c o n c e p t
m u l t i p l i c i t y = s i n g l e v a l u e d

In WSMO relations can be dened to model relationships between concepts, and by this
between their instances (Listing 5). A relation can be dened as being a sub-relation of one or
more relations, as having a given set of parameters and as being rened by a logical expression.

Listing 5: Relation Denition

C l a s s r e l a t i o n subC l a s s wsmoElement
h a s S u p e r R e l a t i o n type r e l a t i o n
hasParameter type parameter
h a s D e f i n i t i o n t y p e l o g i c a l E x p r e s s i o n m u l t i p l i c i t y = s i n g l e v a l u e d

Accordingly, a parameter denition is given in Listing 6.

21

Listing 6: Parameter Denition

C l a s s p a r a m e t e r subC l a s s wsmoElement
hasDomain t y p e c o n c e p t m u l t i p l i c i t y = s i n g l e v a l u e d

An instances of a WSMO concept has the form dened in Listing 7 where an attribute values
represents the value associated with a concepts attribute in the instance. The attribute values
(Listing 8) have to be dened in respect with the type declaration in the concept denition.

Listing 7: Instance Denition

C l a s s i n s t a n c e subC l a s s wsmoElement
hasType type c o n c e p t
h a s A t t r i b u t e V a l u e s type a t t r i b u t e V a l u e

Listing 8: Attribute Value Denition

C l a s s a t t r i b u t e V a l u e subC l a s s wsmoElement
h a s A t t r i b u t e t y p e a t t r i b u t e m u l t i p l i c i t y = s i n g l e v a l u e d
h a s V a l u e t y p e { i n s t a n c e , l i t e r a l , anonymousId }

Similarly, one can dene relation instances and parameters values, respectively (see Listing
9 and Listing 10).

Listing 9: Relation Instance Denition

C l a s s r e l a t i o n I n s t a n c e subC l a s s wsmoElement
hasType type r e l a t i o n
hasParameterValue type parameterValue

Listing 10: Parameter Value Denition

C l a s s p a r a m e t e r V a l u e subC l a s s wsmoElement
h a s P a r a m e t e r t y p e p a r a m e t e r m u l t i p l i c i t y = s i n g l e v a l u e d
h a s V a l u e t y p e { i n s t a n c e , l i t e r a l , anonymousId }
m u l t i p l i c i t y = s i n g l e v a l u e d

The elements presented before correspond into the language to the so called conceptual syntax. Additionally, one can rene its ontology by using axioms, which can constrain or logically
dene the various aspects of the ontology (see Listing 11).

Listing 11: Axiom Denition

C l a s s axiom subC l a s s wsmoElement

h a s D e f i n i t i o n type l o g i c a l E x p r e s s i o n

The logical expressions are used in the WSMO model to capture specic nuances of meaning of modeling elements or their constituent parts in a formal and unambiguous way. More
details about the syntax of the formal language used for specifying the logical expressions can
be found in [44] while the semantics of this language is given in [16].
22

Web service
A Web Service description in WSMO is a description of both the functionality of the Web
service (as a capability) and its behavior (as an interface). Additionally, the description of the
Web service can also refer to a set of non-functional properties, to the set of ontologies modeling
the elements used in this descriptions (i.e. imported ontologies) and to the set of mediators the
service is referring to in order to address the heterogeneity problems (see Listing 12).

Listing 12: Web Service Description Denition

C l a s s w e b S e r v i c e subC l a s s wsmoElement
importsOntology type ontology
u s e s M e d i a t o r t y p e { o o M e d i a t o r , wwMediator }
h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y
h a s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e v a l u e d
h a s I n t e r f a c e type i n t e r f a c e

Listing 13 denes the class used to describe the Web service specic non-functional properties. WSMO does not pose restrictions of how the non-functional properties have to be encoded by logical expressions but such non-functional properties could include cost-related and
charging-related properties of a Web service [39], or properties like like accuracy, networkrelated QoS, performance, reliability, robustness, scalability, security, etc [42].

Listing 13: Non-Functional Properties Denition

C l a s s n o n F u n c t i o n a l P r o p e r t y subC l a s s wsmoElement
h a s D e f i n i t i o n type l o g i c a l E x p r e s s i o n

The capability of a Web service is dened in terms of preconditions, assumptions, postcondition and effects (Listing 14). The preconditions and assumptions dene the information space
of the Web service and the state of the world, respectively, before execution while the postconditions and effects the information space of the Web service and of the world, respectively, after
the execution of the services.

Listing 14: Capability Denition

C l a s s c a p a b i l i t y subC l a s s wsmoElement
importsOntology type ontology
u s e s M e d i a t o r type { ooMediator , wgMediator }
h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y
h a s S h a r e d V a r i a b l e s type s h a r e d V a r i a b l e s
h a s P r e c o n d i t i o n t y p e axiom
h a s A s s u m p t i o n t y p e axiom
h a s P o s t c o n d i t i o n t y p e axiom
h a s E f f e c t t y p e axiom

The importsOntology, usesMediator and hasNonFunctionalProperties have the same meaning as in the case of the Web service descriptions. The shared variables represent variables that

23

are shared between the preconditions, assumptions, postconditions and effects22 .

The Web service interface is described in terms of the choreography and orchestration (Listing 15). The choreography of the service species how the requester should interact with the
service while the orchestration species how the service achieves its functionality by invoking
other services.
Listing 15: Interface Denition

C l a s s i n t e r f a c e subC l a s s wsmoElement
importsOntology type ontology
usesMediator type ooMediator
h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y
hasChoreography type choreography
h a s O r c h e s t r a t i o n type o r c h e s t r a t i o n

Goals
The Goal description (Listing 16) is similar with a Web Service description (WSMO treats
both the requestor and the provider of a goal as equal partners), containing a description of the
required capability (what the service should offer) and of the required interface (how the service
should be accessed).
Listing 16: Goal Denition

C l a s s g o a l subC l a s s wsmoElement
importsOntology type ontology
usesMediator type { ooMediator , ggMediator }
h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y
r e q u e s t s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e v a l u e d
r e q u e s t s I n t e r f a c e type i n t e r f a c e

Having similar descriptions for the services and the service request facilitate the Web services discovery by a potential client, the selection of the most appropriate service for a certain
task, the actual invocation of a service and the composition of multiple services for accomplishing a common task.
Mediators
The WSMO mediators are mechanisms for getting different systems to work together, to
agree on the format of messages exchanged and protocols/processes used. WSMO denes mediators (see Listing 17) between two ontologies (ooMediators), two services (wwMediators),
two goals (ggMediators) and a requestor and a provider of a service (wgMediators).
22
If ?v1,...,?vn are the shared variables dened in a capability, and pre(?v1,...,?vn),
ass(?v1,...,?vn), post(?v1,...,?vn) and eff(?v1,...,?vn) are used to denote the formulae dened by the preconditions, assumptions, postconditions, and effects respectively, then the following holds:

forAll

?v1,...,?vn (pre(?v1,...,?vn) and ass(?v1,...,?vn)

implies post(?v1,...,?vn) and eff(?v1,...,?vn)).

24

Listing 17: WSMO Mediators Denition

C l a s s m e d i a t o r subC l a s s wsmoElement
importsOntology type ontology
h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y
hasSource type { ontology , goal , webService , mediator }
h a s T a r g e t type { ontology , goal , webService , mediator }
h a s M e d i a t i o n S e r v i c e t y p e { g o a l , w e b S e r v i c e , wwMediator }
C l a s s o o M e d i a t o r subC l a s s m e d i a t o r
hasSource type { ontology , ooMediator }
C l a s s g g M e d i a t o r subC l a s s m e d i a t o r
usesMediator type ooMediator
hasSource type { goal , ggMediator }
hasTarget type { goal , ggMediator }
C l a s s w g M e d i a t o r subC l a s s m e d i a t o r
usesMediator type ooMediator
h a s S o u r c e t y p e { w e b S e r v i c e , g o a l , wgMediator , g g M e d i a t o r }
h a s T a r g e t type { webService , goal , ggMediator , wgMediator }
C l a s s wwMediator subC l a s s m e d i a t o r
usesMediator type ooMediator
h a s S o u r c e t y p e { w e b S e r v i c e , wwMediator }
h a s T a r g e t t y p e { w e b S e r v i c e , wwMediator }

4.3

How to Extend WSMO for BPMO

Starting with WSMO, we will provide some modication and extension for modeling business
process.
4.3.1

Extension Highlights

In this section, we will present the main extension strategies of WSMO for BPMO, involving
the similar and the distinguished characteristics of BPMO. Generally, there are the following
extension highlights:
The four main high-level elements in WSMO, i.e. ontology, Web service, goal, mediator,
can be signicantly reused in BPMO, respectively as ontology, business process, business
goal, and mediator.
For BPMO ontology, the WSMO ontology denition provides almost the concept needed
in representing a process. The distinguish point hereby is that we should emphasis the detailed concepts involving in the business process scenario, involving business rule, business role, and business data, in consistent with the description requirements R1.2, R1.3,
and R1.4.
The BPMO business process is similar with WSMO Web service; one difference is that
we accept only one type of mediators, the ontology-to-ontology mediator; another main
difference is we use execution instead of interface for business process. The main reason
is that, in the business processes environment, we are more concerned with how the process is actually executed, and not with how it can be invoked or with how it can orchestrate
other services. These operations are going to be handled by specialized components in
the BPM Suite [54].

25

 For BPMO business goal, like WSMO goal, BPMO uses it to express the business objectives that can be achieved by executing business processes. Unlike the WSMO goals, the
BPMO goals do not have a dedicated interface, as the requester is not aware of how the
process is executed.
For BPMO mediator, unlike WSMO, BPMO does not consider the need of mediating between any two entities. Only ontology-to-ontology mediator is considered in the Sembiz
project.
Different from Non-functional-properties in WSMO, which acts as special properties together with the four elements, BPMO provides a more separate mode for NFP according
to the more complex non-functional requirements.
4.3.2

BPMO UML Diagram

To make the framework clearer and provide a basis for the BPMO implementation, we propose
a comprehensive UML diagram involving all the BPMO elements, as shown in Figure 4. The
current diagram is still in its infancy, and will be improved and rened in our future works.

Figure 4: BPMO Elements UML Diagram

Basically, there are ve core elements inheriting from the fundamental element BPMOElement, which can be inherited from WSMOElement. Therefore, all the existing description properties in WSMO can be reused in the BPMO framework.
4.3.3

BPMO Element Denition

As mentioned, BPMO can be inherited from WSMO as reusing many existing features from
semantic Web service description (see Listing 18).

Listing 18: BPMO element Denition

C l a s s bpmoElement subC l a s s wsmoElement

26

Ontology
Like the role of ontology in WSMO, for BPM we need the support of ontologies for modeling all the concepts needed in representing a process. For now, the WSMO ontologies provide
almost all the modeling elements BPMO need. However, what we want to emphasis here is the
business-related concepts involved in the business process scenario (see Listing 19).

Listing 19: BPMO ontology Denition

C l a s s o n t o l o g y subC l a s s bpmoElement
importsOntology type ontology
usesMediator type ooMediator
hasConcept type concept
h a s R e l a t i o n type r e l a t i o n
hasFunction type f u n c t i o n
h a s I n s t a n c e type i n s t a n c e
h a s R e l a t i o n I n s t a n c e type r e l a t i o n I n s t a n c e
hasAxiom t y p e axiom
C l a s s b u s i n e s s R u l e subC l a s s o n t o l o g y
/ / e x p r e s s e d a s axiom o r f u n c t i o n
/ / e x p r e s s e d a s ASM r u l e s
C l a s s b u s i n e s s R o l e subC l a s s o n t o l o g y
/ / s p e c i f i c b u s i n e s s o r g a n i z a t i o n o n t o l o g y , r o l e s and t a s k s
C l a s s b u s i n e s s D a t a subC l a s s o n t o l o g y
/ / s p e c i f i c b u s i n e s s data ( messages , documents , e v e n t s , time , )
/ / and l o g i n f o r m a t i o n i n v o l v e d i n t h e w h o l e BPM l i f e c y c l e

Business Processes
The denition of a business process is very similar with the denition of Web Services, from
the Web Service modeling Ontology, and is presented in List(see Listing 20).

Listing 20: BPMO businessProcess Denition

C l a s s b u s i n e s s P r o c e s s subC l a s s bpmoElement
importsOntology type ontology
usesMediator type ooMediator
h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y
h a s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e v a l u e d
hasExecution type e x e c u t i o n
C l a s s c a p a b i l i t y subC l a s s bpmoElement
importsOntology type ontology
usesMediator type ooMediator
h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y
h a s S h a r e d V a r i a b l e s type s h a r e d V a r i a b l e s
h a s P r e c o n d i t i o n t y p e axiom
h a s A s s u m p t i o n t y p e axiom
h a s P o s t c o n d i t i o n t y p e axiom
h a s E f f e c t t y p e axiom
C l a s s e x e c u t i o n subC l a s s bpmoElement
h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t i e s
h a s S t a t e S i g n a t u r e type s t a t e S i g n a t u r e
h a s S t a t e type s t a t e
h a s T r a n s i t i o n R u l e s type t r a n s i t i o n R u l e s

27

Non-Functional Properties
Non-functional properties needed for the Business Process modeling additionally include In
WSMO, non-functional issues usually are modeled with the four elements as special properties.
For BPMO, according to the more complex non-functional requirements, relevant information
needs to be modeled in more separate mode. There are four major non-functional issues that
should be emphasized in process modeling. Process compensation should be considered as
the substitution of the ACID transaction requirement in traditional database systems; QoS of
process can make high-quality process available; security is always the primary precondition for
the business community; process logs are the valuable information sources to support process
monitoring and process mining, and the process improvement nally (see Listing 21).
Listing 21: BPMO nonFunctionalProperties Denition

C l a s s n o n F u n c t i o n a l P r o p e r t i e s subC l a s s bpmoElement
h a s C o n t r i b u t o r t y p e dc : c o n t r i b u t o r
h a s C o v e r a g e t y p e dc : c o v e r a g e
h a s C r e a t o r t y p e dc : c r e a t o r
h a s D a t e t y p e dc : d a t e
h a s D e s c r i p t i o n t y p e dc : d e s c r i p t i o n
h a s F o r m a t t y p e dc : f o r m a t
h a s I d e n t i f i e r t y p e dc : i d e n t i f i e r
h a s L a n g u a g e t y p e dc : l a n g u a g e
hasOwner t y p e owner
h a s P u b l i s h e r t y p e dc : p u b l i s h e r
h a s R e l a t i o n t y p e dc : r e l a t i o n
h a s R i g h t s t y p e dc : r i g h t s
h a s S o u r c e t y p e dc : s o u r c e
h a s S u b j e c t t y p e dc : s u b j e c t
h a s T i t l e t y p e dc : t i t l e
h a s T y p e t y p e dc : t y p e
hasVersion type v e r s i o

hasCompensation type Compensation

h a s Q u a l i t y type Q u a l i t y
h a s S e c u r i t y type S e c u r i t y
hasLog t y p e Log

Business Goal
Like goals in WSMO, BPMO uses goals to express the business objectives that can be
achieved by executing business processes. Goals can be considered as specic business processes that would potentially satisfy the user desires. Unlike the WSMO goals, the Business
goals do not have a dedicated interface - we care only what the requirement is in terms of the
required functionality and not in terms of the required behavior (or in other words, the requester
is not interested in how the process is executed, see Listing 22).

Listing 22: BPMO businessGoal Denition

C l a s s b u s i n e s s G o a l subC l a s s bpmoElement
usesMediator type ooMediator
h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y
h a s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e v a l u e d

28

Mediator
We acknowledge the importance of mediators in a semantic environment, as dened by
Web Service Modeling Ontology, but unlike WSMO we do not consider the need of mediating
between any two entities. The ontologies used for modeling different processes or process
requests may differ, so we adopt the WSMO denition of ooMediator (see Listing 23). However,
the other three types of WSMo mediators are not beeded for BPMO, their functionality being
covered by several components from BPM Suite [48]

Listing 23: BPMO mediator Denition

C l a s s m e d i a t o r subC l a s s bpmoElement
importsOntology type ontology
h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y
hasSource type { ontology }
hasTarget type { ontology }
h a s M e d i a t i o n S e r v i c e type { goal , p r o c e s s }

29

5 Conclusions and Future Steps

At the beginning of this deliverable, we briey overview the state of the art of process modeling approaches, including non-semantic and semantic ones, and considering both industrial
standards and formal theoretical foundations. After the survey, together with the starting point
of business process real use cases and abstracted scenarios, we determine the description requirements of semantic business process. Finally, we present the feasible WSMO extension
to design BPMO, aiming at the achievement of comprehensive description framework for the
above determined semantic description requirements.
The next steps will be the detailed design of all the BPMO elements for the actual implementation. As previously stated in this document, we will reuse already existing WSMO framework
and its description language WSML, adapting them to suit the business process scenario in the
SemBiz project.

References
[1] Business process management on an soa foundation, a unied framework for process design and deployment. http://www.tibco.com/resources/solutions/soa/bpm-soa.pdf.
[2] Functional requirement. http://en.wikipedia.org/wiki/Functional requirements.
[3] Owl-s 1.2 release. Available from http://www.daml.org/services/owl-s/1.0/.
[4] Web service choreography. http://citeseer.ist.psu.edu/kobayashi03typebased.html, 2002.
[5] Semantic web service framework, swsf version 1.0.
http://www.daml.org/services/swsf/1.0/, 2005.

SWSF Available from

[6] R. Akkiraju, J. Farrell, J. Miller, M. Nagarajan, M. Schmidt, A. Sheth, and

K. Verma.
Web service semantics - wsdl-s.
Technical note Available from
http://lsdis.cs.uga.edu/library/download/WSDL-S-V1.html, April 2005.
[7] S. Beco, B. Cantalupo, L. Giammarino, N. Matskanis, and M. Surridge. Owl-ws: A workow ontology for dynamic grid service composition. In E-SCIENCE 05: Proceedings
of the First International Conference on e-Science and Grid Computing, pages 148155,
Washington, DC, USA, 2005. IEEE Computer Society.
[8] G. K. Behara.
Bpm and soa:
A strategic alliance.
BPTrends,
http://devresource.hp.com/drc/technical white papers/WSOrch/WSOrchestration.pdf,
May 2006.
[9] J. Bergstra, A. Ponse, and S. Smolka. Handbook of Process Algebra. Elsevier Science
Inc., 2001.
[10] C. Bock and M. Gruninger. Psl: A semantic domain for ow models. Software and Systems
Modeling Journal, pages 209231, 2005.
[11] A. J. Bonner and M. Kifer. Transaction logic programming. In International Conference
on Logic Programming, pages 257279, 1993.

[12] A. J. Bonner and M. Kifer. Concurrency and communication in transaction logic. In Joint
International Conference and Symposium on Logic Programming, pages 142156, 1996.
[13] S. Brockmans, M. Ehrig, A. Koschmider, A. Oberweis, and R. Studer. Semantic alignment
of business processes. In ICEIS (3), pages 191196, 2006.
[14] E. Cerami. Web Services Essentials, Distributed Applications with XML-RPC, SOAP,
UDDI and WSDL. OReilly, 2002.
[15] L. Chung, B. A. Nixon, and E. Yu. Non-Functional Requirements in Software Engineering.
Springer, 1999.
[16] J. de Bruijn.
D16 the wsml specication.
http://www.wsmo.org/TR/d16/, February 2005.

WSMO Deliverable available from

[17] D. Fensel and C. Bussler. The web service modeling framework wsmf. Electronic Commerce Research and Applications, pages 209231, 2002.
[18] E. Groger and R. Stark. Abstract State Machine - A Method for High-Level System Design
and Analysis. Springer, 2002.
[19] A. Haller and E. Oren. m3pl: A work-ows ontology extension to extract choreography
interfaces. In In Proceedings of the Workshop on Semantics for Business Process Management Workshop at ESWC2006, Budva, Montenegro, 2006.
[20] A. Haller, E. Oren, and P. Kotinurmi. m3po: An ontology to relate choreography models to workow models. In In Proceedings of the International Conference on Services
Computing (SCC 2006), Chicago, Illinois, 2006.
[21] M. Hammer. Re-engineering work: Dont automate, obliterate. Harvard Business Review,
pages 104112, 1990.
[22] M. Hepp. Super deliverable1.1 process modeling ontology and mapping to wsmo.
http://www.ip-super.org/, 2006.
[23] M. Hepp, F. Leymann, J. Domingue, A. Wahler, and D. Fensel. Semantic business process
management: A vision towards using semantic web services for business process management. In IEEE International Conference on e-Business Engineering (ICEBE 2005), pages
535540, Beijing, China, October 2005.
[24] M. Hepp, F. Leymann, J. Domingue, A. Wahler, and D. Fensel. An ontology framework
for semantic business process management. In Proceedings of Wirtschaftsinformatik 2007,
Karlsruhe, Germany, February 2007.
[25] Z. Irani, V. Hlupic, and G. Giaglis. Business process re-engineering: A modeling perspective. International Journal of Flexible Manufacturing Systems, 12(4):247252, 2000.
[26] N. Jennings, P.Faratin, M. Johnson, T. Norman, P.OBrien, and M. Wiegand. Agent-based
business process management. International Journal of Cooperative Information Systems,
5(2&3):105130, 1996.

31

[27] M. Kifer. Transaction logic for the busy workow professional, 1996.
[28] M. Kifer. Web service composition as ai planning - a survey, 2005.
[29] A. Koschmider and A. Oberweis. Modeling semantic business process models. AIFBKarlsruhe, 2006.
[30] M. Koubarakis and D. Plexousakis. Business process modeling and design: Ai models and
methodology, 1999.
[31] R. Lara, H. Lausen, S. Arroyo, J. de Bruijn, and D. Fensel. Semantic web services: Description requirements and current technologies. In In International Workshop on Electronic Commerce, Agents, and Semantic Web Services, September 2003.
[32] R. Lucchi and M. Mazzara. A pi-calculus based semantics for ws-bpel. Journal of Logic
and Algebraic Programming.
[33] T. Madhusudan, J. L. Zhao, and B. Marshall. A case-based reasoning framework for
workow model management. Data Knowledge Engineering, 50(1):87115, 2004.
[34] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems: Specication. Springer, 1991.
[35] A. Mocan, M. Moran, E. Cimpian, and M. Zaremba. Filling the gap - extending service
oriented architectures with semantics. In EEE International Conference on e-Business
Engineering 2006 (ICEBE 2006), pages 594601, Shanghai, China, October 2006.
[36] T. Murata. Petri nets: Properties, analysis and applications. In roceedings of the IEEE,
Vol. 77, No. 4, pages 541580, April 1989.
[37] E. Newcomer and G. Lomow. Understanding SOA with Web Services. Addison Wesley
Professional, December 2004.
[38] B. Nuseibeh and S. Easterbrook. Requirements engineering: a roadmap. In ICSE 00:
Proceedings of the Conference on The Future of Software Engineering, pages 3546, New
York, NY, USA, 2000. ACM Press.
[39] J. OSullivan, D. Edmond, and A. T. Hofstede. Whats in a service? towards accurate
description of non-functional service properties. Distributed Parallel Databases, 12(23):117133, 2002.
[40] C. Peltz and H. Packard. Web service orchestration, a review of emerging technologies, tools, and standards. http://devresource.hp.com/drc/technical white papers/WSOrch/
WSOrchestration.pdf, January 2003.
[41] F. Puhlmann and M. Weske. Using the i-calculus for formalizing workow patterns. In
Business Process Management, pages 153168, 2005.
[42] S.
Rajesh
and
D.
Arulazi.
Quality
of
service
for
web
services-demystication,
limitations,
and
best
practices.
See
http://www.developer.com/services/article.php/2027911, March
2003.
32

[43] D. Roman, J. de Bruijn, A. Mocan, I. Toma, H. Lausen, J. Kopecky, C. Bussler, D. Fensel,

J. Domingue, S. Galizia, and L. Cabral. Semantic Web Technologies, trends and research
in ontology-based systems, chapter Semantic Web Service - Approaches and Perspectives.
WILEY, 2006.
[44] D. Roman, H. Lausen, and U. K. (eds.).
D2v1.3 Web Service Modeling Ontology (WSMO).
Technical report,
WSMO Final Draft,
http://www.wsmo.org/TR/d2/v1.3/, October 2006.
[45] D. Roman, H. Lausen, and U. Keller. D2v1.3. web service modeling ontology (wsmo).
WSMO Deliverable available from http://www.wsmo.org/TR/d2/v1.3/, Octomber 2006.
[46] S. Ross-Talbot.
Web services choreography and
http://www.daml.org/services/swsl/materials/WS-CDL.pdf, 2004.

process

algebra.

[47] D. Sangiorgi and D. Walker. The Pi-calculus - A Theory of Mobile Processes. Cambridge
University Press, 2004.
[48] H. Smith and P. Fingar. Business Process Management: The Third Wave. Meghan-Kiffer
Press, Tampa, FL, USA, 2002.
[49] I. Toma and D. Foxvog. D28.4v0.1 non-functional properties in web services. WSMO
Deliverable, available from http://www.wsmo.org/TR/d28/d28.4/v0.1/, October 2006.
[50] W. van der Aalst, H. de Beer, and B. F. van Dongen. Process mining and verication of
properties: An approach based on temporal logic. In OTM Conferences (1), pages 130
147, 2005.
[51] W. van der Aalst, A. ter Hofstede, B.Kiepuszewski, and A.P.Barros. Workow patterns.
Distrib. Parallel Databases, 14(1):551, 2003.
[52] W. van der Aalst and K. van Hee. Workow Management: Models, Methods, and Systems.
MIT Press, 2002.
[53] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf. RFC 2413 - Dublin Core Metadata for
Resource Discovery, September 1998.
[54] Z. Yan, E. Cimpian, M. Mazzara, and M. Zaremba. D3.1 sembiz bpmsuite requirements
analysis and design. SemBiz Deliverable, February 2007.

33