ARTICLE IN PRESS

Contents lists available at ScienceDirect

Information Systems

Information Systems 35 (2010) 496–504

0306-43

doi:10.1

� Tel.

E-m

journal homepage: www.elsevier.com/locate/infosys

Semantic reengineering of business processes

Violeta Damjanovic �

Salzburg Research Forschungsgesellschaft, Knowledge based IS, Jakob Haringer Strasse 5-II, 5020 Salzburg, Austria

a r t i c l e i n f o

Keywords:

Business process modelling

Model transformations

Process algebra

Model-driven architecture

79/$ - see front matter & 2009 Elsevier B.V. A

016/j.is.2009.06.003

: +43 699 10955020.

ail address: violeta.damjanovic@salzburgresea

a b s t r a c t

This paper discusses transforming ontological models into non-ontological models of

business processes, when the process of articulating different data models is known as

reengineering domains. As a crucial factor in achieving interoperability and semantic

reengineering of the domains with the different levels of semantic representation

(expressiveness), we point out the role of foundational ontology that serves to enable

global meaning of the process knowledge and that is, in this paper, additionally

connected with the process theory (process algebra). The main focus of the process

theory is on the system that interacts with one another, such as the business processes,

whereas the main idea of semantic reengineering is transforming ontological models

into the semantic business processes that can be (semi-)automatically executed via a

workflow engine. Therefore, as a promising solution in achieving interoperability

between the real enterprise needs and the business process models, we involve the

Pi-Calculus as a process theory to provide semantics between the ontological models

based on the DOLCE Description and Situation (D&S) Plan and Tasks Ontology (DDPO)

and the business process models that are expressed in Business Process Execution

Language (BPEL).

& 2009 Elsevier B.V. All rights reserved.

1. Introduction

The future business process domains will be certainlygrounded in ontological knowledge with the ability toreuse existing knowledge, articulate the new businessprocesses based on them and provide ontological explica-tion of activities, steps and procedures involved increating software solutions for the business processes.In this paper, we use the DOLCE Description and Situation(D&S) Plan and Tasks Ontology (DDPO) model as asemantic data model to help us get a good understandingof the task and plan models and provide implicit rules forconcepts that explain behaviour as well as structure ofboth executable and abstract business processes. In otherwords, we use the main DDPO ontological concepts such

ll rights reserved.

rch.at

as non-physical, social, non-agentive [1] for representingthe process knowledge.

Nowadays, for the sake of combining the ontologicalresources with the non-ontological resources such asbusiness processes, new tools and methods to supportprocess knowledge creation are needed. Hence, wepropose semantic reengineering of the ontological knowl-edge domains to semantically support (semi-)automaticcreation of business processes via process knowledgethat is additionally expressed in the form of Pi-Calculus.Our approach also builds on related work in this areaconnecting ontologies and business processes, such as [2]that describes an ontology for executable businessprocesses using the formalism of the Web ServiceModelling Language (WSML); [3] that proposes a set ofontologies and formalisms, and defines the scope of theseontologies by giving competency questions that is acommon approach in the ontology engineering; [4] thatexplores the behavioural aspects of Web services and

ARTICLE IN PRESS

V. Damjanovic / Information Systems 35 (2010) 496–504 497

proposes using Description Logics (DL) for their formali-zation.

As the main motivation of this paper, we address theproblem of exchanging the information between thesemantic data models (based on the DDPO and expressedin Web Ontology Language (OWL)) and the real businessmodels (expressed in Business Process ExecutionLanguage (BPEL)). The business processes from thedomain of mechatronic engineering are chosen to ex-plicate the main challenges in semantic reengineering ofbusiness processes.

Table 1The syntax of the DDPO theoretical model: basic concepts and relations

[6].

Syntax of the DDPO theoreticalmodel

Semantics

Plan(x)-Description(x) Plan is a description of x

Plan(x)-(t. Task(t) 4Uses(x,t) y that uses at least one task ty

Plan(x)-(c. ((AgentiveRole(c)

3Figure (c)) 4Uses(x,c)

y and at least one agentive role c

or Figure cy

Plan(x)-(g. Goal(g)

4ProperPart(x,g)

y and that has at least one goal g

as a proper part

Subplan(x) ¼ df Plan(x) 4(y.

Plan(y) 4ProperPart(y,x)

A subplan x can have varied

proper parts, including other

plans y

Goal(x) ¼ df Desire(x) 4(p.

Plan(p) 4A goal x is defined as a desire that

is a proper part of a plan p

ProperPart(p,x)

PlanExecution(x) ¼ df

Situation(x) 4(y. Plan(y) 4P-

SAT(x,y)

Plan execution (execution of a

plan x) is defined as a situation

that proactively satisfy a plan y

(P-SAT)

GoalSituation(x) ¼ df

Situation(x) 4(y. Goal(y)

4SAT(x,y)

A goal situation x is defined as a

situation that satisfy a goal y

GoalSituation(x)-8y,p,s. (Goal(y)

4SAT(x,y) 4Plan(p)

4ProperPart(p,y) 4P-SAT(s,p))-

:ProperPart(s,x)

A goal situation x is not a proper

part of the execution of a plan x

Precondition(p,s)-Plan(p)

4Situation(s)

A precondition for a plan p can be

defined as a relation between a

situation s and a plan p, implying

that for all plan executions of

that plan to occur, a situation

should preliminary satisfy some

description

Precondition(p,s)-8s1.

(PlanExecution(s1) 4P-

SAT(s1,p))-((d � SAT(s,d)

4Precedes(s,s1))

Postcondition(p,s)-Plan(x)

4Situation(s)

A postcondition for a plan p can

be defined as a relation between

a situation s and a plan p,

implying that after plan

executions of that plan to occur, a

situation should satisfy some

description

Postcondition(p,s)-8s1.

(PlanExecution(s1) 4P-

SAT(s1,p))-((d � SAT(s,d)

4Precedes(s1,s))

2. Description of a business process domain

Mechatronic engineering is one of the most recentbranches of engineering, which has increasing impact onmany sectors of the economy and on the society overall[5]. The mechatronic engineering processes cover aninterdisciplinary combination of different domains com-prising of mechanical engineering, electrical engineering,and software engineering. Each domain covers a specificmechatronic field, while the intersection of knowledgemodels between these different engineering domains isconnected through the mechatronic processes. The abilityto integrate various mechatronic knowledge models andto articulate business processes based on them are centralkey to effectively manipulating knowledge resources.Hence, the DOLCE foundational ontology has been chosenas the working hypothesis from which the modellingof the mechatronic domain and process ontologiesstarted [5].

The DOLCE ontology aims at capturing the maincognitive categories, such as endurants and perdurants,underlying existing ontologies and human commonsensethat appears even in the domain of mechatronics.The main difference between endurants and perdurants isrelated to their behaviour in time, e.g. endurants canchange in time, while perdurants cannot. Furthermore, theDDPO module specialises the concepts and relationsdefined in DOLCE, and extends Descriptions and Situations(D&S) module that involves a representation language forthe tasks and processes [6]. In this paper, the ability totransform the DDPO theoretical model into the BPELbusiness processes is represented as an essential tasktowards semantically meaningful business process execu-tion via the BPEL workflow engine. As BPEL is notequipped with the formal semantics, exchanging theinformation between semantics and non-semantics datamodels needs a mechanism that is able to couple semanticexpressions of the DDPO process models with thebusiness process models. Therefore, we have involvedthe Pi-Calculus process algebra to provide accuratetransformations between the different levels of semanticexpressiveness of ontological models (expressed in OWLand based on the DDPO) and business process models(expressed in BPEL). In this way, different levels ofsemantic expressiveness enable the original semanticdefinitions to take a part of the business processesimplementation, and to reduce the possible mistakes insemantic interpretation of the different domains.

Here, we represent a business process trinity mechan-ism that translates semantic expressions of the DDPOtheoretical models into the Pi-Calculus and additionallyprovides the underlying semantics for the BPEL executableprocesses.

3. Business process trinity: DDPO, Pi-Calculus, BPEL

In this section, a brief description of the followingthree elements of the business process trinity mechanismis given: (a) the syntax and semantics of the DDPOtheoretical model, (b) the Pi-Calculus syntax and opera-tional semantics, and (c) the syntax and semantics of theBPEL executable processes.

3.1. DDPO

The purpose of the DDPO is to specify DOLCE plans atthe abstract level by using First Order Logic (FOL).

ARTICLE IN PRESS

V. Damjanovic / Information Systems 35 (2010) 496–504498

Additionally, we employ the DDPO to provide automaticand semantically meaningful usage of knowledge thatdescribes tasks, description, and situation in which theprocesses can be applied [7]. We suggest reading [6] toprovide deeper insight into the DDPO formal character-ization.

The syntax and the semantics of the selectedconcepts and relations of the DDPO theoreticalmodel are represented in Table 1, whereas the syntaxof the selected DDPO tasks is explained separatelyin Table 2.

The purpose of the DDPO tasks is to describethe type of actions, theirs sequencing and the controlsperformed on them [6]. The DDPO tasks can becomplex and ordered, and their behaviour servesas the main point used to describe the businessprocesses and to align the knowledge models to the DDPOconcepts.

Table 2The syntax of the DDPO tasks (according to [6]).

Syntax of DDPO tasks Sem

Task(x) ¼ df Course(x) 4 y,z. Plan(y) 4 Defines(y,x) 4((IntentionalAgentiveRole(z) 3IntentionalFigure(z)) 4 Uses(y,z) 4DesireTowards(z,x)

A t

int

att

ComplexTask(x) ¼ df Task(x) 4 y,z. Task(y) 4 Task(z) 4 yaz 4Component(x,y) 4 Component(x,z)

A c

z) a

SequentialTask(x) ¼ df Complex Task(x) 4 (y,z. (Component(x,y) 4Component(x,z) 4yaz) 4 (Successor(y,z) 3 Successor(z,y))) 4 (:w.

Component(x,w) 4 ControlTask(w))

A s

rela

any

HybridTask(x) ¼ df ComplexTask(x) 4 y,z. Component(x,y) 4Component(x,z) 4 yaz 4 ControlTask(y) 4 ActionTask(z)

A h

tas

ElementaryTask(x) ¼ df :y. Component(x,y) 4 Task(y) An

ActionTask(x) ¼ df :y. Sequences(x,y) 4 PlanningActivity(y) An

pla

ControlTask(x) ¼ df Task(x) 4 (y. Sequences(x,y)-PlanningActivity(y)) 4z. Task(z) 4 DirectSuccessor(x,z)

A c

act

LoopTask(x) ¼ df ControlTask(x) 4 y,z,w,P. Task(y) 4 Action(z) 4Action(w) 4 zaw 4 DirectSuccessor(x,y) 4 Sequences(y,z) 4Sequences(y,w) 4MinimalCommonType(z,w,P)

A l

tas

min

CyclicalTask(x) ¼ df ComplexTask(x) 4 y,z,w. LoopTask(y) 4DirectSuccessor(y,x) 4 CaseTask(z) 4 DirectSuccessor(z,y)

4Component(x,z) 4 DeliberationTask(w) 4 DirectSuccessor(z,w)

4Component(x,w) 4ExitCondition(y,w)

A c

tas

exi

the

delExitCondition(x,y)-LoopTask(x) 4 DeliberationTask(y)

BranchingTask(x) ¼ df ControlTask(x) 4 y,z. Task(y) 4 Task(z) 4 yaz 4DirectSuccessor(x,y) 4 DirectSuccessor(x,z)

A b

tas

AlternateTask(x) ¼ df CaseTask(x) 4 y,z. DeliberationTask(y) 4DeliberationTask(z) 4 yaz 4 DirectSuccessor(x,y) 4 DirectSuccessor(x,z)

4:w. way 4 waz 4 DeliberationTask(w) 4DirectSuccessor(x,w)

An

del

ConcurrencyTask(x) ¼ df BranchingTask(x) 4 y,z. Task(y) 4 Task(z) 4 yaz

4DirectSuccessor(x,y) 4 DirectSuccessor(x,z) 4 e1,e2. (Perdurant(e1) 4Perdurant(e2) 4e1ae2 4 Sequences(y,e1) 4Sequences(z,e2)) -

Overlaps(e1,e2)

A c

exe

per

one

exeConcurrencyTask(x) - y. SynchroTask(y)

ParallelTask(x) ¼ df ConcurrencyTask(x) 4 y,z. Task(y) 4 Task(z) 4 yaz 4DirectSuccessor(x,y) 4 DirectSuccessor(x,z) 4e1,e2. (Perdurant(e1) 4Perdurant(e2) 4 e1ae2 4 Sequences(y,e1) 4 Sequences(z,e2))-

Coincides(e1,e2)

A p

tas

BeginningTask(x) ¼ df ControlTask(x) 4 y,p. (Task(y) 4 Plan(p) 4Component(p,x) 4 Component(p,y) 4 xay)-Successor(x,y)

A b

tas

EndingTask(x) ¼ df ControlTask(x) 4 p:y. (Task(y) 4 Plan(y) 4Component(p,x) 4 Component(p,y) 4 xay)-Successor(y,x)

An

defi

MaximalTask(x) ¼ df ComplexTask(x) 4 y. (Task(y) 4 Component(p,y)) -

Part(x,y)

A m

in a

3.2. Pi-Calculus

The Pi-Calculus process algebra represents the form ofmathematical formalisms for describing and analyzing theproperties of concurrent computation [8]. It is distin-guished from the other process algebras (e.g. Calculus forCommunicating Systems (CCS), Communicating Sequen-tial Processes (CSP), and Algebra of CommunicatingProcesses (ACP)) in terms of mobility. Mobility is acharacteristic of all the processes that refers to the wayin which processes evolve as they execute [8].

Each process consists of one or more actions, whichcan be arranged sequentially, in parallel or conditionalpaths, or recursively [9]. An action is the sending orreceiving of information on a channel. According to thePi-Calculus convention, when one process sends informa-tion to another, it includes the name of the channel to beused in response to changing conditions. The channels can

antics

ask x is defined (df) as a course x in which a plan y has at least one

entional agentive role z or one intentional figure z and uses a desire

itude towards task x

omplex task x is defined as a task that has at least two other tasks (y and

s components

equential task x is defined as a complex task that includes a successor

tion among any two component tasks (y and z) and does not contain

control task w

ybrid task x is defined as a complex task that has at least one control

k y and one action task z as a component

elementary task x is defined by an atomic task y

action task x is defined as an elementary task that sequences non-

nning activities y

ontrol task x is defined as an elementary task that sequences a planning

ivity y. It has at least one direct successor task z

oop task x is defined as a control task that has as successor y an action

k that sequences at least two distinct activities (z and w) sharing a

imal common set of properties

yclical task x is defined as a complex task that is controlled by a loop

k y and has a case task z as a component. The case task z specifies the

t condition(s) of the cyclical task indirectly w, while a loop task specifies

exit condition. The exit condition can be used to state what

iberation task y causes to exit the cycle

ranching task x is defined as a control task that articulates a complex

k into an ordered set of tasks

alternate task x is defined as a case task branching to exactly two

iberation tasks (z and w)

oncurrency task x is defined as a task branched to a set of tasks

cutable concurrently, which means that no deliberation task is

formed in order to choose among them. A concurrency task has at least

successor synchronization task, which is aimed at waiting for the

cution of all tasks direct successor to the concurrent one

arallel task x is defined as a concurrent task branching to at least two

ks (y and z) that sequence temporally coinciding perdurants (e1 and e2)

eginning task x is defined as a control task that is the predecessor of all

ks defined in the plan p

ending task x is defined as a control task that has no successor tasks

ned in the plan y

aximal task x is defined as a complex task that has all the tasks defined

plan as components y

ARTICLE IN PRESS

V. Damjanovic / Information Systems 35 (2010) 496–504 499

act both as transmission medium and as transmitted data[10]. The communication is done on complementarychannels (input and output). The contents of messagesare also channels.

The core syntax of the Pi-Calculus processes, accordingto [8], is shown in Table 3.

In the Pi-Calculus, processes are written using theformal model shown in Fig. 1 [9]: The process definitionpart of the Pi-Calculus formal model explains that everyidentifier A is associated with a process definition of theform A(x1,y,xk) ¼ P. Summation offers a choice of thesummands expressing sequential behaviour of the processP. Parallel composition allows all components to proceedexpressing concurrent behaviour of the process P. Finally,process expression defines a local channel name x to beused within the process P implementing process encap-sulation.

A system described using the Pi-Calculus can evolve indifferent ways depending on the interactions amongprocesses. The laws which govern the static relationsbetween processes are known as the static structural

congruence, while the laws that rule their interactionrepresent the reduction relations (the operational seman-tics) [8]. The semantics of the Pi-Calculus consists of boththe structural congruence and the reduction relations.

Today, there are three major areas that aredirectly impacted by using the Pi-Calculus such as thefollowing [8]:

�

TabThe

P::

0

jxðu

jxhu

|(x)

|P1|

jP

i

|if (

|if (

j! � x

Pi-Calculus is implemented in the Erlang language,which is the primary language for programmingtelephone networks;

� Pi-Calculus is implemented in LOTOS, which has

become an ISO standard used widely by NASA for thevery complex and delicate temporal reasoning pro-blems in their space missions; and

le 3core syntax of the Pi-Calculus process P.

¼

(nil)

Þ (input: receiving u along channel x)

i (output: sending u along channel x)

P (restriction : referring to encapsulation)

P2 (parallel composition : referring to concurrency)

xiðuÞ � Pi (alternative composition: referring to sum; sequence)

x ¼ y) then P1 (conditional: referring to match)

xay) then P2 (conditional: referring to mismatch)

ðuÞ � P (replication)

Fig. 1. The Pi-Calculus

�

Pi-Calculus provides the theoretical underpinnings formost of the major Business Process Modelling (BPM)standards. That represents approach to formal seman-tics that makes the description of all constructs of abusiness model and offers a good basis for validationand reasoning about the business processes.

3.3. BPEL

BPEL enables realization of Service Oriented Architec-ture (SOA) through composition, coordination, andorchestration of Web services [11]. It represents a work-flow-based language that describes sophisticated businessprocesses that orchestrate Web services. As an orchestra-tion language, it supports activities for communicatingwith other Web services, as well as handling workflowsemantics. The core syntax of the BPEL processes [11] isshown in Table 4.

BPEL syntax is defined by a BPEL XML Schema (XMLS),which describes the following kind of BPEL activities:

(a)

form

TablThe

B:: ¼

emp

|invo

|invo

|rece

|repl

|thro

|com

|sequ

|flow

|pick

|swit

|scop

Basic activities: throw, assign, wait, empty, compen-sate, terminate;

(b)

Partner activities: receive, reply, invoke; and (c) Structured activities: sequence, switch, while, pick, and

flow.

BPEL uses all of these constructs for describing thebehaviour of the business processes (Web services).Additionally, they are described using Web ServiceDefinition Language (WSDL) interface definitions thatdefine available functions and the mechanism by whichBPEL processes can be accessed, e.g. Web services are

al model.

e 4core syntax of the BPEL process B.

ty (empty)

ke(x, i, o) (synchronous invocation (request-reply))

ke(x, i) (asynchronous invocation (one-way))

ive(x, i) (receive)

y(x, o) (reply)

w(f, o) (throw)

pensate(z, o ) (compensate)

ence(A, A0) (sequence)

(A, A0) (parallel)

((x, i1, A), (x, i2, A)) (alternative)

ch(x ¼ x0) A; A0 (conditional)

ez(A, Se, Sf, A0) (scope)

ARTICLE IN PRESS

V. Damjanovic / Information Systems 35 (2010) 496–504500

defined using the following elements [12]:

(a)

types, which provides datatype definitions used todescribe the messages exchanged;

(b)

message, which represents an abstract definition ofthe data being transmitted;

(c)

portType, which is a set of abstract operations. Eachoperation refers to an input message and outputmessages;

(d)

binding, which specifies concrete protocol and dataformat specifications for the operations and messagesdefined by a particular portType;

(e)

port, which specifies an address for a binding, thusdefining a single communication endpoint; and

(f)

service, which is used to aggregate a set of related ports.

Implementing a BPEL process by describing it in the BPELfile is not enough to make this business process executable.Certain rules and mapping formalisms between semanticallydescribed knowledge, on the one hand, and BPEL and WSDLdefinitions, on the other hand, must be defined in order toenable semantically meaningful execution of the businessprocesses. However, as both BPEL and WSDL cannot expresssemantic description of business processes, neither providewell-defined semantics for automated composition andexecution of business process [11], we continue lookingfurther into the appropriate formalisms able to semanticallyarticulate execution of the business processes.

4. Semantic business process transformation scenario

The BPEL defines two kinds of processes [13]:

(a)

executable processes that can be executed by the BPELworkflow engine; and

(b)

abstract processes (business protocols) that explainmessage exchange patterns.

Fig. 2. The semantic business proc

The BPEL executable processes describe the controlflow for orchestrating data sources (e.g. *.bpel file) and the

interfaces to external data sources (e.g. *.wsdl file),whereas BPEL abstract processes are not executable andcould be used just to guide executable processes.

In order to implement the business process trinitymechanism that translates semantic expressions of theDDPO models (expressed as an *.owl file) into thePi-Calculus that additionally gives the semantics for BPELexecutable business processes (*.bpel and *.wsdl file), weapply a rule-based approach to Web service orchestrationand choreography. The proposed solution is based onModel-Driven Architecture (MDA) [14] that enablesdefining models at various levels of abstraction anddeveloping appropriate transformations between thesemodels. The transformation models conform to both thetransformation metamodels that define the model trans-formation semantics and the meta-metamodel [15]. Themetamodels are specified using Meta-Object Facility(MOF), which is a modelling language for expressing arange of information models and modelling systems [16].The MOF metadata architecture is used as a four layerframework, which includes the following layers shown inFig. 2:

�

ess

the MOF data layer (M0) that refers to the informationthat we wish to describe;

� the MOF model layer (M1) that contains the definition

of the required structures;

� the MOF metamodel layer (M2) that defines the terms

in which the model is expressed; and

� the MOF meta-metamodel layer (M3) that defines the

terms used to specify metamodels. It is the languagefor defining different kinds of metadata.

Each model from the M1 layer conforms to anappropriate metamodel from the M2 layer. At the same

transformation scenario.

ARTICLE IN PRESS

V. Damjanovic / Information Systems 35 (2010) 496–504 501

time, all MOF layers can belong to the different TechnicalSpaces (TSs) that according to Object Management Group(OMG) definition represent ‘‘a working context with a setof associated concepts, body of knowledge, tools, requiredskills, and possibilities.’’ As it is shown in Fig. 2, the M2and M3 layers belong to the MOF TS, whereas the M1 layerinvolves the Semantic Web TS, MOF TS and XML TS.The exchanging model between different TSs requiresthe transformation models to be defined. At the sametime, performing model transformation cannot always bedone in just one step. For example, in the Semantic WebTS (Fig. 2), the knowledge about mechatronic businessprocesses is expressed through the DDPO model and usesOWL RDF/XML presentation syntax (an *.owl file). In orderto enable communication between the Semantic Web TSand MOF TS, we transform *.owl file into an equivalent*.ecore (ECore) file, which is expressed using OWL RDF/XMI exchange syntax XML Metadata Interchange (XMI)that is an interchange format used for serialization ofmodels of other languages (metamodels). In the next step,we use the Atlas Transformation Language (ATL) engine[15] for specifying and implementing the relevant trans-formation rules between OWL RDF/XMI and Pi-Calculus/XMI metamodel definitions. The resulting Pi-Calculus/XMIconstructs are further transformed into both BPEL/XMIand WSDL/XMI metamodel definitions for which wedefine the following two transformation models: thePI2BPEL and the PI2WSDL. As the main results ofperforming the proposed transformation models, weobtain the BPEL and the WSDL files represented in XMIinterchange format. Finally, we transform the resultingBPEL/XMI and WSDL/XMI files into appropriate BPEL andWSDL files that belong to the XML TS and are executablevia the BPEL workflow engine.

For the sake of simplifying the transformationmodel (Fig. 2), we represent all three TSs (Semantic

Fig. 3. The ‘‘Semantic-Rule-Action’’ sens

Fig. 4. Mapping from the OWL DDPO-based Ele

Web, MOF and XML TS) by using the following notions(see Fig. 3):

(a)

e of

ment

a semantic sense;

(b) a rule (causal) sense; and (c) an action sense of the semantic business process

transformation scenario.

The semantic sense of the transformation scenarioinvolves the DDPO-based OWL RDF/XML file in whichthe ontology-based knowledge about mechatronic busi-ness processes is defined. The rule (causal) sense of thetransformation scenario consists of the transformationmodels that are applied to OWL RDF/XMI file andtransformed into the BPEL and WSDL exchange syntax.Finally, the action sense of the scenario transforms theBPEL and WSDL exchange syntax into the BPEL and WSDLpresentation syntax that gives ability to (semi-)automaticexecution of the semantic business processes.

A collection of transformation rules have been appliedto enable mapping from the OWL–DL metamodel into theBPEL and WSDL metamodel classes. An example ofmapping from the OWL Class, which is interpreted bythe DDPO Elementary task, into the Pi-Calculus Operator

metamodel class, and then, into the BPEL Throw and WSDLmetamodel classes, is shown in Fig. 4. For each task fromthe DDPO theoretical model we have found an appropriateactivity from the category of the BPEL activities, the BPELPartner activities, and the BPEL Structured activities.Comparing the syntax requirements of the DDPO tasksand BPEL activities, we define the transformation rules.For example, mapping from the OWL Class, that isadditionally aligned to the DDPO theoretical model (DDPO

Elementary task), into the Pi-Calculus Operator metamodelclass requires various constructs of the DDPO theoretical

the transformation scenario.

ary task into the BPEL Throw activity.

ARTICLE IN PRESS

V. Damjanovic / Information Systems 35 (2010) 496–504502

model to be considered. An example of such mapping isexplained in more detail in the following section. For adetailed example of a mechatronic use case in which wehave applied the proposed semantic business processtransformation scenario, we refer the reader to [17].

4.1. An example of mapping the DDPO Elementary task into

the Pi-Calculus Operator class

Semantically meaningful execution of the businessprocesses requires structured collaboration, orchestration,and choreography of particular business processes, theirsactivities and tasks. In this section, we describe a way ofestablishing the semantic relations between the DDPOOWL-based constructs and the BPEL processes throughthe Pi-Calculus metamodel. As an example, we show thesyntax of the DDPO ElementaryTask that is represented inTable 5.

The following are the steps that enable transformationof the DPPO Elementary task into the Pi-Calculus Operator

class [7]. First, we transform the syntax of the DDPOElementaryTask into the graphical representation thatinvolve appropriate workflow pattern (e.g. parallel split),which is shown in Fig. 5. Then, we define the Pi-Calculusbased semantics of the DDPO ElementaryTask, which isrepresented by the definitions (1)–(3). The DDPO Elemen-

tary task (that is defined by map relation in (3)) is anatomic task (defined by atom relation in (2)), with nocomponents (defined by no_com relation in (1)).

Componentðx; yÞ �!no_com

comðx; yÞno_com � tComponentðx;yÞ � Componentðx; yÞ0

(1)

Table 5Syntax of the DDPO Elementary task (according to [6]).

DDPO tasks Semantics

ElementaryTask(x) ¼ df :y.

Component(x,y) 4 Task(y)

An elementary task x is defined as

an atomic task y

Component(x,y) ¼ df

ProperPart(x,y) 4d,z,w.

Description(d) 4Role(z) 4Role(w)

4Uses(d,z) 4Uses(d,w)

4Selects(z,x) 4Selects(w,y)

A component relation is defined as a

proper part relation qualified by a

description d in which the proper

parts (z and w) are involved

Task(x) ¼ df Course(x) 4 y,z.

Plan(y) 4 Defines(y,x) 4((IntentionalAgentiveRole(z)

3IntentionalFigure(z)) 4 Uses(y,z)

4 DesireTowards(z,x)

A task x is defined (df) as a course x

in which a plan y has at least one

intentional agentive role z or one

intentional figure z and uses a desire

attitude towards task x

Fig. 5. A graphical representation of the DDPO Elementary task.

TaskðyÞ�!atom

elðyÞ � tTaskðyÞ � TaskðyÞ0 (2)

elementary TaskðxÞ�!map

t�elementary TaskðxÞ � ðcomðx; yÞ � 0jelðyÞ � 0Þ

(3)

In the next step, the syntax of the DDPO Component

relation is given in the form of a graphical representationthat involves both the sequence and the parallel splitworkflow patterns (shown in Fig. 6) [7]. Starting fromFig. 6, the Pi-Calculus based semantics of the DDPOComponent is defined and represented by the definitions(4)–(8). The DDPO Component relation (that is defined bymap relation in (8)) is described as a proper part (definedby pp relation in (4)), which is further qualified bydescription (defined by dsc relation in (5)) in which theproper part z (defined by z relation in (6)) and the properpart w (defined by w relation in (7)) are involved.

proper Partðx; yÞ�!pp

tproper Partðx;yÞ � ðppðx; yÞ � 0jppðy; xÞ � 0Þ

(4)

DescriptionðdÞ�!dsc tdescription � d1 � 0 (5)

RoleðzÞ�!z trole � z1 � 0 (6)

RoleðwÞ�!w trole �w1 � 0 (7)

Componentðx; yÞ�!map

tproperPartðx;yÞ � ppðx; yÞ

� 0jd1 � tcomponentðx;yÞ � Componentðx; yÞ0

jz1 � tcomponentðx;yÞ � Componentðx; yÞ0jw1

� tcomponentðx;yÞ � Componentðx; yÞ0 (8)

Finally, the syntax of the DDPO Task is given in the formof a graphical representation that involves both thesequence and the multi merge workflow patterns (shownin Fig. 7). Based on Fig. 7, the semantics of the DDPO Task

is described by the definitions (9)–(14). The DDPO Task

(that is defined by map relation in (9)) is a course (that isfurther defined by cur relation in (10)) in which a plan

Fig. 6. A graphical representation of the DDPO Component.

ARTICLE IN PRESS

V. Damjanovic / Information Systems 35 (2010) 496–504 503

(defined by pl relation in (11)) has at least one intentionalagentive role z (defined by ag_role relation in (12)) or oneintentional figure z (defined by fig. relation in (13)) anduses a desire attitude z, which describes the intentionalagentive role and/or the intentional figure towards task x

(defined by map relation in (14)).

TaskðxÞ�!tsk ttask � c � 0 (9)

CourseðxÞ�!cur

c � tcourse � CourseðxÞ0 (10)

Fig. 7. A graphical representa

Table 6The metamodel-based transformation rules.

DDPO OWL

metamodel

class

Pi-Calculus

metamodel class

BPEL

metamodel

Explanation of

Plan OWL

ontology

Pi-Calculus process BPEL process DDPO Plan is a

and has at leas

used for repres

Process represe

process that is

Goal OWL

statement

Pi-Calculus agent-

activity

BPEL

partnerlink

Each DDPO Plan

descriptions as

could be furthe

Activity describ

define different

Elementary

task

OWL class Pi-Calculus operator BPEL throw;

BPEL empty.

DDPO Elementa

the same time,

describe the ag

process needs t

of a ‘‘no-op’’ in

concurrent acti

Branching

task

OWL class Pi-Calculus operator BPEL sequence DDPO Branching

of tasks. The BP

sequentially, in

Parallel task Intersection Pi-Calculus parallel

composition

BPEL pick DDPO Parallel t

temporally coin

of the processe

execution. It is

occurrence of o

event that occu

activity to perf

Alternate

task

OWL

unionof

Pi-Calculus

alternative

composition

BPEL pick DDPO Alternate

UnionOf statem

class extension

extensions of t

Hybrid task OWL class Pi-Calculus operator BPEL receive,

BPEL reply

DDPO Hybrid ta

as a componen

wait for a matc

process to send

The combinatio

the WSDL port

Ending task OWL class Pi-Calculus operator BPEL

terminate

DDPO Ending ta

the BPEL Termin

business proce

PlanðyÞ�!map

tplan � p � 0 (11)

IntentAgent RoleðzÞ �!ag_role

tIntentAgent Role � i � 0 (12)

Intent FigureðzÞ�!fig

tIntent Figure � i � 0 (13)

PlanðyÞ�!map

!i � tplan � PlanðyÞ0 ¼ !i � usesðy; zÞ � PlanðyÞ0j!i

� desire Towardsðx; zÞ � PlanðyÞ0 (14)

tion of the DDPO Task.

transformation

description that uses at least one task, at least one agentive role or figure,

t one goal as a proper part [6]. Pi-Calculus Process is a central class that is

enting the interaction and communication among processes, while BPEL

nts a central class that is used for explaining the nature of the BPEL

implicitly connected with the DDPO Plan description.

has a goal as a proper part, and can also have regulations and other

proper parts. We transform the DDPO Goal to OWL Statement in a way that

r expressed by Pi-Calculus Agent Activity class. The Pi-Calculus Agent

es the resource allocation strategy, while the BPEL PartnerLink is used to

relationships to partners.

ry task represents an atomic task that is transformed into OWL Class. At

Pi-Calculus Operator class consists of a set of operators that are used to

ents and processes. BPEL Throw activity can be used when a business

o signal an internal fault explicitly. BPEL Empty construct allows insertion

struction into a business process that is useful e.g. for synchronization of

vities.

task is a control task that articulates a complex task into an ordered set

EL Sequence activity contains one or more activities that are performed

the order in which they are listed within the BPEL /sequenceS element.

ask is a concurrent task branching to at least two tasks that sequence

ciding perdurants [6]. OWL Intersection class links a parallel composition

s with the rest of the processes that participate in business process

analogous to logical conjunction. The BPEL Pick activity awaits the

ne of a set of events and then performs the activity associated with the

rred. If more than one of the events occurs, then the selection of the

orm depends on which event occurred first.

task is a case task branching to exactly two deliberation tasks. OWL

ent is analogous to logical disjunction. It describes a class for which the

contains those individuals that occur in at least one of the class

he class descriptions in the list.

sk is a complex task that has at least one control task and one action task

t. The /receiveS construct allows the business process to do a blocking

hing message to arrive. The /replyS construct allows the business

a message in reply to a message that was received through /receiveS.

n of a /receiveS and a /replyS forms a request-response operation on

Type for the process.

sk is a control task that has no successor tasks defined in the plan, while

ate activity can be used to immediately terminate the behaviour of a

ss instance within which the terminate activity is performed.

ARTICLE IN PRESS

Table 7OWL metamodel classes currently without interpretation in the Pi-

Calculus metamodel.

AllValuesFromRestriction, SomeValuesFromRestriction

CardinalityRestriction, MaxCardinalityRestriction,

MinCardinalityRestriction

OWLAnnotationProperty, OWLOntologyProperty, Property,

FunctionalProperty, OWLObjectProperty, InverseFunctionalProperty,

SymmetricProperty, TransitiveProperty

V. Damjanovic / Information Systems 35 (2010) 496–504504

4.2. The semantic business process transformation rules

The following are the guiding transformation rules thatrelate between the DDPO constructs expressed inOWL–DL, the Pi-Calculus, and the BPEL metamodelelements. The metamodel based transformational rulesare explained in Table 6. There are a plenty of OWLmetamodel classes that currently do not have theirinterpretation in Pi-Calculus operational semantics, whichare shown in Table 7. For example, the impossibility toexpress the cardinality restrictions defined in OWL modelstrains to the problem of constraining the number ofvalues of a particular property, or the most importantproblem of expressing OWL properties that can lead to theloss of connections between e.g. instances of two classes,or instances of classes and RDF literals. Therefore, thefurther improvements of the semantic business processtrinity mechanism that is proposed in this paper shouldextend the existing set of the transformation rules tocover the rest of the OWL–DL metamodel constructs.We are particularly interested in extending Pi-Calculusmetamodel to cover OWL cardinality restrictions and bothOWL datatype and OWL object properties.

5. Conclusions

This paper discusses the use of the MDA and MOFapproaches as the mechanisms for semantic reengineer-ing of the ontological knowledge domains in order tosupport (semi-)automatic business process execution.Additionally, the paper represents the process knowledgeexpressed in the form of a Pi-Calculus process theory thatserves as a formalism to provide semantics between thedifferent levels of semantic expressiveness of ontologicaldata models and non-ontological business processmodels. Recently, the Pi-Calculus and its variants likeSpi-Calculus, Ambient calculus, etc., have found practicalapplications in a wide number of domains: from crypto-graphic protocols like ProVerif [18], Cryptyc,1 to thetheoretical basis of the BPML and XLANG [19], molecularbiology [20], LOTOS [21] and many more. A particularinterest of the Pi-Calculus is taken in getting a formalfoundation to the model and reasoning about the differentcollaboration techniques such as orchestration and chor-eography of the business processes. The interestingcases of using the Pi-Calculus are those that meetrequirements for the design of self-adaptive and self-

1 http://www.cryptyc.org/.

organizing systems that consider implementation ofprobabilistic algorithms to enable a random choice, aswell as asynchronous manifestation of processes thatoccur randomly in dynamic and distributed architectures.Therefore, we have found the Pi-Calculus process algebrato be the most convenient formalism to express the realnature of the business processes taking place in theSemantic Web environment. At the same time, we haveinvolved the DDPO theoretical model to provide semanti-cally meaningful usage of knowledge that describes thetasks, as well as the descriptions and situations in whichthe business processes can be applied.

References

[1] C. Masolo, S. Borgo, A. Gangemi, N. Guarino, Ontology Library,WonderWeb Del. D18, 2004.

[2] J. Nitzsche, D. Wutke, T. Van Lessen, An ontology for executablebusiness processes, in: M. Hepp, K. Hinkelmann, D. Karagiannis,R. Klein, N. Stojanovic (Eds.), Semantic Business Process and ProductLifecycle Management. Proceedings of the Workshop SBPM 2007,Innsbruck, CEUR Workshop Proceedings, ISSN 1613-0073, 2007.

[3] M. Hepp, D. Roman, An Ontology Framework for Semantic BusinessProcess Management, in: Proceedings of the Eighth InternationalConference Wirtschaftsinformatik, Germany, 2007.

[4] M. Fronk, J. Lemcke, Expressing Semantic Web Service Behaviorusing Description Logics, in: Proceedings of the ESWC 2006Workshop on SBPM 2006, Montenegro, 2006.

[5] V. Damjanovic, W. Behrendt, M. Ploßnig, M. Holzapfel, DevelopingOntologies for Collaborative Engineering in Mechatronics, in:Proceedings of the Fourth European Semantic Web Conference,ESWC 2007, Austria, 2007, pp. 190–204.

[6] A. Gangemi, S. Borgo, C. Catenacci, J. Lehmann, Task taxonomies forknowledge content, Metokis Deliverable (2004) D07.

[7] V. Damjanovic, DOLCE and Pi-Calculus Rendezvous Semantics forBusiness Processes, in: Proceedings of the First International Work-shop on Knowledge Reuse and Re-engineering over the SemanticWeb (KRRSW 2008), at ESWC 2008, Tenerife, Canary Islands, 2008.

[8] J. Parrow, An introduction to the Pi-Calculus, in: J.A. Bergstra,A. Ponse, S.A. Smolka (Eds.), Handbook of Process Algebra, Elsevier,Amsterdam, 2001, pp. 479–543.

[9] M. Havey, Essential Business Process Modelling: Best Practices forBuilding Process-Oriented Workflow Applications, O’Reilly, 2005.

[10] H. Smith, P. Fingar, Workflow is just a Pi Process, 2003. Online.Available at: /http://www.fairdene.com/picalculus/workflow-is-just-a-pi-process.pdfS.

[11] R. Lucchi, M. Mazzara, A Pi-Calculus based semantics for WS-BPEL,Journal of Logic and Algebraic Programming (JLAP) 70 (2006)96–118.

[12] Web Service Description Language (WSDL) 1.1, W3C Note, 2001.Online. Available at: /http://www.w3.org/TR/wsdlS.

[13] Business Process Execution Language for Web Services, ver. 1.1.2003. Online. Available at: /http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdfS.

[14] J. Miller, J. Mukerji: MDA Guide Version 1.0.1, OMG Document,2003. Online. Available at: /www.omg.org/docs/omg/03-06-01.pdfS.

[15] ATLAS Group, ATL User Manual, 2006.[16] OMG MOF V13: Meta-Object Facility (MOF) Specification, March 2000.[17] V. Damjanovic, M. Plossnig, Bridging the gap between different

levels of business process modelling, in: Proceedings of theInternational Conference on Collaborative Mechatronic Engineer-ing, ICCME 2009, Salzburg, Austria, May 25–26, 2009.

[18] B. Blanchet, A. Chaudhuri, Automated Formal Analysis of a Protocolfor Secure File Sharing on Untrusted Storage, in: IEEE Symposiumon Security and Privacy, USA, 2008, pp. 417–431.

[19] BPEL4WS, A convergence path toward a standard BPM Stack,BPMI.org Position Paper, 2002.

[20] R. Aviv, W. Silverman, E.Y. Shapiro, Representation and simulationof biochemical processes using the pi-calculus process algebra,Pacific Symposium on Biocomputing 1 (2001) 459–470.

[21] E. Brinksma, International Standard ISO 8807:1989, Informationprocessing systems—Open Systems Interconnection-LOTOS—Aformal description technique based on the temporal ordering ofobservational behaviour.