Comparing Business Process Ontologies for Task Monitoring

Amina Annane, Mouna Kamel and Nathalie Aussenac-Gilles

IRIT - Paul Sabatier University, Toulouse, France

Keywords:

Business Process Monitoring, Business Process Modeling, Ontology, Industry 4.0.

Abstract:

Business process (BP) modelling is an active area of research due to its multiple applications. For systems that

support/monitor operators to perform their tasks (i.e., tasks of a given BP), a formal representation is essential.

Various BP ontologies are available to formally represent BP. In this paper, we review and compare a set of

nine BP ontologies according to their ability to represent process speciﬁcation and process execution in a ﬁne-

grained way to enable task monitoring. The comparison shows that, on the one hand, ontologies developed

from scratch establish a clear distinction between process speciﬁcation and process execution, but do not allow

to represent workﬂow constraints required for process execution. On the other hand, most of the ontologies,

that are ontological versions of existing BP modeling languages, focus only on process speciﬁcations but do

not represent process execution, or mix the representation of BP speciﬁcation and execution.

1 INTRODUCTION

A business process (BP) is a set of related tasks that

have to be performed in a speciﬁc order, by some or-

ganization units and actors, to reach well deﬁned busi-

ness goals (Dumas et al., 2013). To maintain a com-

petitive position, industrial companies look perma-

nently for improving their BPs. A research area has

emerged from this need, known as Business Process

Modeling (BPM) (van der Aalst, 2013). It aims at

providing models and tools to analyze, improve, sim-

ulate and automate business processes (BPs). Busi-

ness Process Models provide a more precise deﬁni-

tion of BPs by representing the enterprise activities

and work-ﬂows at an abstract level, including the de-

scription of the roles and responsibilities of its organi-

zation units for different tasks as well as task depen-

dencies and used resources (goods, data and knowl-

edge). In order to better evaluate BPs, and to assist

their execution and management, information tech-

nologies require formal representations of BP models.

More recently, the Industry 4.0 vision assumes an ef-

fective and high-quality communication between sys-

tems (interoperability), which also relies on a formal

representation of BPs (Vogel-Heuser and Hess, 2016).

In this context, ontologies, deﬁned as formal repre-

sentation of domain knowledge at a conceptual level,

are a good means to provide standard and formal rep-

resentations, and by this way, to reinforce interop-

erability and communication between systems (hu-

mans and machines) that use these BP models. More-

over, ontology formal languages allow to perform au-

tomatic reasoning on the knowledge that they repre-

sent. This capability contributes to check knowledge

integrity and consistency (Rospocher et al., 2014). A

deeper discussion about the beneﬁts of representing

BPs using ontologies is available in (Lautenbacher

et al., 2008).

Beyond BP description, another perspective can

be to check BP execution and to perform reasoning on

this execution, for instance to diagnose failures and to

capture recovery procedures. This requires additional

concepts that can keep track of each process run. In

this paper, we examine the needs to be satisﬁed by an

ontology that would support the execution of BPs and

keep track of their executions.

By deﬁnition, ontologies should be shared and

easily reusable models that facilitate knowledge mod-

elling and to increase model interoperability (R. Gru-

ber, 1995). So we examine the literature in order to

ﬁnd reusable ontologies that could contribute to de-

ﬁne a relevant BP ontology that would support the

representation of both process speciﬁcations and pro-

cess executions. We propose a review of nine of the

most popular BP ontologies, and we evaluate their

ability to explicitly represent BPs’ speciﬁcation and

their execution. The goal of this analysis is to guide

us in selecting the most relevant ontologies among the

existing ones.

This work is motivated by our participation in the

634

Annane, A., Kamel, M. and Aussenac-Gilles, N.

Comparing Business Process Ontologies for Task Monitoring.

DOI: 10.5220/0008978706340643

In Proceedings of the 12th International Conference on Agents and Artiﬁcial Intelligence (ICAART 2020) - Volume 2, pages 634-643

ISBN: 978-989-758-395-7; ISSN: 2184-433X

AVIREX project that ﬁts in Industry 4.0. AVIREX

partners aim at developing an intelligent virtual as-

sistant that should: (i) assist/monitor operators in the

step-by-step execution of BPs; (ii) answer the opera-

tor’s questions about the process execution; (iii) keep

all related details to process execution, included the

context in which an anomaly (i.e., unexpected event)

may occur (so as to support the diagnosis process);

(iv) save the solution if the operator succeeds in solv-

ing the anomaly. To accomplish its mission, the vir-

tual assistant relies on a formal and a ﬁne-grained rep-

resentation of the whole BP, hence the need for an

ontology that enables such a representation. Further-

more, the ontology should be generic to be speciﬁed

and instantiated with the BPs of any company. In the

two use cases given by the project industrial partner,

the BPs describe how to assemble electronic, digital

and physical components.

The following of the paper is organized as such:

Section 2 identiﬁes key concepts that should be cov-

ered by an ontology to represent BP execution and

speciﬁcation; they will serve as comparison criteria

of the nine studied ontologies sketched in Section 3.

From this comparison and requirements, we selected

several modelling options and discuss them in Section

4 before we conclude in Section 5.

2 REQUIREMENTS

We studied several knowledge sources: (i) research

papers and technical documents, and (ii) competency

questions, to identify the key concepts that should be

covered by a core BP ontology.

2.1 Knowledge Sources

Research Papers and Technical Documents: We

studied a set of research paper that we cite and dis-

cuss throughout this article. Moreover, we analyzed

two corpora provided by AVIREX industrial partners

with the help of their experts. One corpus includes

20 documents describing real BPs, and the other one

contains 28 documents describing anomalies (or feed-

back experiences) with/without their solutions.

We are interested in internal and executable BPs

of industrial companies. They are imperative pro-

cesses to be performed by human agents (i.e., oper-

ators). The role of the virtual assistant is to monitor

and support operators to improve their efﬁciency and

effectiveness when performing these processes.

Figure 1 shows a sub-process (made anonymous

for conﬁdentiality reasons) to give an idea of what a

BP looks like. As we can observe, the instructions ask

On the MMA station:

1. Execute the script MUXF.exe

2. Using the software SOFT, verify

whether the script execution has

generated an alarm

3. If the execution have generated an

alarm, note the error code

Figure 1: Excerpt of a real Business Process.

the operator to perform a set of speciﬁc activities (”ex-

ecute”, ”verify”, ”note”), on a speciﬁc place (”MMA

station”), in a sequential order. Moreover, some ac-

tivities are controlled by conditions (”if the execution

has generated an alarm”), and require some resources

(”the software SOFT”).

Competency Questions: Competency questions are

recognized to be a good means to identify ontology

speciﬁcations (Gr

uninger and Fox, 1995). Thanks to

our meetings with experts and related works (Hepp

and Roman, 2007), (Abdalla et al., 2014), we col-

lected a set of 26 competency questions: ”What are

the sub-activities of a given process?”, ”Which ac-

tivities must precede a given activity?”, ”Which re-

sources are required for/produced by a given task?”,

”Who can perform/has performed a given activity?”,

”What is the context (i.e., task\agent\resource\..) of

a given anomaly?”, etc.

2.2 Key Concepts

Based on the studied knowledge sources, we identi-

ﬁed the following key concepts:

Process Speciﬁcation refers to the model that de-

scribes the process and how it should be performed.

It includes the following items:

a. Activity Decomposition: Processes are complex

procedures that are usually decomposed into atomic

activities and complex activities (i.e., sub-processes).

b. Workﬂow: It speciﬁes the order (sequential or

parallel) in which the activities should be performed.

c. Preconditions/Postconditions (PP): Beginning

or ending some activities may be subject to condi-

tions. Preconditions control the beginning of activi-

ties, while Postconditions control their ending. Post-

conditions usually are the preconditions of the next

activities. PP depend on the availability of (i) data or

(ii) resources (agents, machines, raw materials, etc.),

(iii) the execution of other activities, (iv) time con-

straints, or (v) the occurrence of events. An Event

is something that ”happens” during process execution

e.g., a call phone or the arrival of an e-mail.

d. Place: It speciﬁes where an activity should be

performed: manufacturing facilities and the resources

located at each of them.

Comparing Business Process Ontologies for Task Monitoring

635

e. Anomaly: Unexpected values or/and errors

may occur during process execution, giving rise to an

anomaly to be tracked in the ontology. At the speciﬁ-

cation level, expected anomalies are represented with

their repair activities.

Process Execution is about representing the actual

execution of a given process speciﬁcation (or process

model), the activities actually performed, who (i.e.,

actual agent) performed them, and in which place.

It also represents the events that triggered the execu-

tion of activities, and the actual resources involved,

consumed or produced during this execution. Hu-

man agents may perform some activities that are not

speciﬁed in the process model and which it is essen-

tial to keep a trace of. A process speciﬁcation may

correspond to several executions. Process/Activity

execution is mainly characterized by different states

(e.g., ready, completed, aborted, ...) and time in-

tervals (i.e., execution-start-time and execution-end-

time). To help experts in diagnosing anomalies, ev-

ery piece of information related to the anomaly oc-

currence context should be saved. Moreover, if the

operator succeeds in solving it, the solution should

also be saved for re-use when the same anomaly ap-

pears again.

Organizational Model and Resources deﬁne the hi-

erarchy of professional roles and their relations, in

other words, it deﬁnes who is subordinated by whom

in the organization. This is important in validation

workﬂows for example. Since both activity speciﬁ-

cation and execution refer to resources, it is essential

to represent the different types of organizational re-

sources held by the enterprise, and that are involved

in BPs.

3 STUDIED BP ONTOLOGIES

In this section, we brieﬂy introduce a set of nine on-

tologies that deal with the semantic representation of

BPs. Here, we try to give the reader a clear idea about

the origin, the context of development, and the repre-

sentation of the key concepts. If some key concepts

(see Section 2) are not discussed for a given ontology,

it means that they are not covered by this ontology.

This is to avoid redundancy, and keep the overview of

each ontology short.

To select relevant ontologies, we searched the

Google Scholar database with various combinations

of the key words: ”ontology”, ”business process”,

”formal model”, ”formal representation”. The search

results were checked through a title and abstract

screening to identify relevant works. Only publica-

tions with a number of citations higher than 20 (see

Tab. 1), and that explicitly mention the development

of an ontology for representing BPs were considered

as relevant. We used the number of citations to as-

sess the popularity of ontologies. The search in the

database was aborted when we noticed a signiﬁcant

amount of repetitions and loss of precision. In addi-

tion, we performed a cross reference search. An on-

Table 1: Number of citations of the studied ontologies ac-

cording to google scholar.

Ontology Citations

EO 1353

PSL 210

COBRA 113

SMPO 104

IMAMO 23

Petri-Net ontology 109

EPC ontology 69

BPMN 2.0 ontology 70

BPMO ontology 65

tology is mainly composed of a set of concepts (i.e.,

class of things), a set of relations among these con-

cepts, and a set of axioms that are used to formalize

domain knowledge. For the sake of readability, we

use the SMALL CAPITAL LETTERS font when we re-

fer to the actual concepts of an ontology.

Among the studied ontologies, we distinguish

(i) ontologies developed from scratch, and (ii) ontolo-

gies that formalize BPM languages.

3.1 Ontologies Developed from Scratch

The Enterprise Ontology (EO). The enterprise on-

tology (Uschold et al., 1998) was developed within

the Enterprise Project that aimed at designing a mod-

eling framework that uses executable process models

to help users perform their tasks. EO is composed of

ﬁve sub-ontologies: (1) Meta-ontology and Time, (2)

Activities and processes, (3) Organization, (4) Strat-

egy, and (5) Marketing. In this paper, we consider

only the three ﬁrst sub-ontologies since they are re-

lated to the key concepts that we have identiﬁed.

The sub-ontology of activities and processes is

concerned with the representation of process speci-

ﬁcation and execution; the central concepts are AC-

TIVITY SPECIFICATION and ACTIVITY.

Process speciﬁcation is limited to the representa-

tion of the process decomposition, but the workﬂow

is not represented: neither concepts, nor relationships

are provided to represent the order in which the activ-

ities should be performed.

Organization sub-ontology is concerned with the

representation of agents (human or software), and

their organizational hierarchy.

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

636

Organization sub-ontology is linked to the activity

sub-ontology via CAPABILITIES and AUTHORITIES

concepts. On one hand, EO represents the capabilities

and authorities of each agent. On the other hand, it

represents the capabilities and authorities required for

performing each activity.

An ACTIVITY is an execution of an ACTIVITY

SPECIFICATION. It is performed by a DOER in a

given TIME INTERVAL. In EO, an ACTIVITY may

use/consume RESOURCES, be decomposed into SUB-

ACTIVITIES, have PRECONDITIONS and EFFECTS

(i.e., outcomes). EVENTS are considered as a speciﬁc

type of ACTIVITY.

EO is formalized in Ontolingua which is an old

formal language and is available at https://tinyurl.

com/y26su33t.

Process Speciﬁcation Language Ontology (PSL).

PSL (Gruninger and Menzel, 2003) is an ISO standard

for representing manufacturing processes (Pouchard

et al., 2005) that was created at the National Insti-

tute of Standards and Technology (NIST

). It was de-

signed to facilitate correct and complete exchange of

process information among manufacturing systems.

ACTIVITY concept denotes a speciﬁcation of an ac-

tivity. ACTIVITY-OCCURRENCE denotes the actual

execution of one ACTIVITY. Except the decompo-

sition of an activity into sub-activities, the repre-

sentation of process speciﬁcations is made by ap-

plying constraints on the instances of ACTIVITY-

OCCURRENCE (Gr

uninger, 2009). Indeed, using

PSL, it is not possible to deﬁne process speciﬁca-

tions (e.g., order constraints, events, activity precon-

ditions/postconditions) independently of process exe-

cution (i.e., activity occurrences).

PSL offers a set of concepts and relations to rep-

resent for a given activity-occurrence (i.e., at the ex-

ecution level) : sub-activity occurrences, beginning

and ending time, states, preconditions and postcon-

ditions, and the resources involved in its execution.

There is no elaborated representation of anomalies,

but the concept ATTEMPT (i.e., an activity occurrence

that has been interrupted for some reason) may be a

good starting point for adding an extension.

PSL is formalized in OWL and is available at

https://tinyurl.com/y4annulm. In (Gr

uninger, 2009),

the authors explain how to represent process speciﬁ-

cations using PSL with ﬁrst order logic sentences.

Core Ontology for Business pRocess Analysis (CO-

BRA). The SUPER (Semantics Utilized for Pro-

cess management within and between EnteRprises)

project

is a European research project aimed at deﬁn-

https://www.nist.gov/

https://cordis.europa.eu/project/rcn/105285/factsheet/

ing a set of ontologies for Semantic Business Process

Management (SBPM). In the context of this project,

Hepp et al. (Hepp and Roman, 2007) have proposed

eight ontologies (e.g., Upper-level Process Ontology

(UPO)) and clariﬁed their scopes with competency

questions. Unfortunately, we were not able to ac-

cess the SUPER ontologies except for COBRA and

BPMO. COBRA (Pedrinaci et al., 2008) is a core on-

tology that aimed at enhancing BP analysis. The core

concepts of COBRA are BUSINESS ACTIVITY and

BUSINESS ACTIVITY REALIZATION that represent

process speciﬁcation and process execution, respec-

tively. COBRA represents the composition of activ-

ities at the speciﬁcation and execution levels. Fur-

thermore, it reuses the time ontology

to represent the

beginning and ending time-points of BUSINESS AC-

TIVITY REALIZATIONS. A taxonomy of monitoring

events has been deﬁned to capture the different events

related to process execution. These events change

process or activity states (e.g., started, aborted, com-

pleted, etc.). However, at the speciﬁcation level,

events are not represented. COBRA allows to spec-

ify AGENTS or ROLES responsible for the execution

of each BUSINESS ACTIVITY, as well as the actual

AGENT that has performed a given BUSINESS AC-

TIVITY REALIZATION. Different relations are pro-

vided by COBRA to represent the resource/data re-

quirements and produced of a given BUSINESS AC-

TIVITY or BUSINESS ACTIVITY REALIZATION such

as uses, consumes, produces and provides. These rela-

tions link activities to PERSISTENT ENTITY that may

be a PHYSICAL ENTITY or a NON-PHYSICAL EN-

TITY. The categorization of these entities is inline

with top level ontologies such as DOLCE (Masolo

et al., 2003). COBRA has been formalized in OCML

but it has no accessible link.

Software Maintenance Project Ontologies

(SMPO). To decrease the efforts and costs of

the software maintenance projects, an extended

software engineering environment MANTIS has been

implemented including the semi-formal ontology

(SMPO) (Ruiz et al., 2003). This ontology deals

with the representation of the static and dynamic

aspects of software maintenance projects. SMPO is

composed of three sub-ontologies: (1) Maintenance,

(2) Workﬂow, and (3) Measurement. We do not

discuss the measurement ontology since it represents

metrics for assessing the quality of products and

processes, which is out the scope of this paper.

Maintenance sub-ontology (i.e., the static aspect

of the maintenance process) in turn includes four sub-

ontologies describing: (i) PRODUCT and their com-

position; (ii) AGENTs, their ROLEs and their orga-

https://www.w3.org/TR/owl-time/

Comparing Business Process Ontologies for Task Monitoring

637

nizational model; (iii) ACTIVITY, its sub-types (i.e.,

MAIN ACTIVITY, SUPPORT ACTIVITY, etc.), its in-

puts/outputs, and the used RESOURCEs; and (iv)

PROCESS ORGANIZATION allows to represent pro-

cedures (activity speciﬁcation) that may be used by

activities. The content of these procedures is not

represented. A maintenance Activity is triggered by

a MAINTENANCE REQUEST (i.e., an internal docu-

ment that describes the anomaly) communicated by

an AGENT. Then, the maintenance request is man-

ually studied by experts that produce an INVESTI-

GATION REPORT that points out the CAUSE of the

anomaly. The corrective actions are included in the

maintenance request report, but are not represented.

Workﬂow sub-ontology (i.e., the dynamic aspect)

deals with the representation of activity decomposi-

tion, temporal constraints between activities and their

execution order. It is surprising to observe that spec-

iﬁcations such as temporal constraints between activ-

ities are represented at the execution level and not

at the speciﬁcation level, in the process organization

sub-ontology. SMPO does not establish a clear dis-

tinction between process speciﬁcation and process ex-

ecution. The same concept ACTIVITY is used to rep-

resent both of them. Indeed, ACTIVITY is deﬁned

as the description of the work to be performed. At

the same time, it comprises the STATE attribute that

refers to execution states (e.g., not started, in execu-

tion, etc.). SMPO has been semi-formalized in UML.

Industrial MAintenance Management Ontology

(IMAMO). IMAMO (Karray et al., 2012) has been

developed within the scope of the SMAC (Semantic

MAintenance and lifeCycle) project in collaboration

between academic and industrial organizations from

France and Switzerland. The SMAC project aimed

at providing a semantic platform of industrial mainte-

nance ensuring the capitalization and reuse of knowl-

edge. Hence, it was essential to represent mainte-

nance process and its related concepts.

Process speciﬁcation is represented mainly with

the PROCESS PATTERN concept that is composed of

a set of STEPs. A process workﬂow is described

through several concepts (e.g., STEP, TRANSITION,

etc.) and relations (e.g., has ﬁrst step, next step, next

transition, etc.). For more details, see the processes

view in (Karray et al., 2012).

RESOURCEs are well covered in IMAMO since

they are the central element in an industrial main-

tenance process, especially material resources. In-

deed, many details about material resources are rep-

resented such as their composition, their functional

requirements, etc. In addition, IMAMO provides a

rich taxonomy of industrial resources. However, for a

given activity speciﬁcation (i.e., PROCESS PATTERN

or STEP), the required resources are not represented

except agents who should perform the activity.

Key concepts for process execution are PROCESS

and ACTIVITY. They are characterized by the at-

tribute ”State”, related to a PERIOD (start and end

dates), and an ACTOR who performs the activity. A

PROCESS refers to a PROCESS PATTERN and com-

posed of a set of ACTIVITY. An ACTIVITY is the exe-

cution either an ACTION or a STEP. ACTION denotes

a task speciﬁcation that aims at resolving a TROU-

BLE. TROUBLE concept refers to the Anomaly con-

cept. IMAMO represents different types of anoma-

lies, their causes, and the actions that may be per-

formed to resolve them. Only the events triggering

anomalies are represented.

IMAMO has been formalized in OWl and is ac-

cessible at https://tinyurl.com/yyxjsryp

3.2 Ontologies Developed from BP

Modeling Languages

A process modeling language provides appropriate

syntax and semantics to precisely specify BP require-

ments, in order to support automated process veri-

ﬁcation, validation, simulation and process automa-

tion (Lu and Sadiq, 2007). To take advantage of an

ontological representation of BPs, formal ontological

descriptions of some BP languages have been pro-

posed:

Petri-Net Ontology. In (Koschmider and Oberweis,

2005), the authors have proposed an ontology that

formalizes Petri-Net elements for BP representation.

Petri-Net is a mathematical and graphical modeling

language that is utilized for modelling workﬂows and

simulating/analyzing their enactments. A Petri-Net is

a directed graph that mainly consists of two different

nodes, PLACES and TRANSITIONS. PLACES repre-

sent states, while TRANSITIONS represent events and

activities. The abstract concept ”token” is used to

simulate the move of the execution ﬂow through the

process graph. It is possible to represent the different

workﬂow patterns (e.g., AND-Split, OR-Split, Loops,

etc.) (van der Aalst et al., 2003) with Petri-Net. Time

constraints, data and resource requirements are not

supported naively, but they may be represented with

additional or customized tokens (e.g., colored tokens)

(van der Aalst, 2015). Although this solution can be

handled by computers, it requires a high expertise and

generates complex Petri-Net graphs. Petri-Net on-

tology does not offer more elements, hence it offers

the same representation characteristics as Petri-Net.

Moreover, petri-Net ontology does not offer a vocab-

ulary for the domain of BP, which is a key element for

a BP ontology. This is explained by the fact that BP

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

638

representation is just an application for Petri-Nets. Its

strength is its mathematical model that has clear exe-

cution semantics. In addition, several process analysis

algorithms exist (e.g. detecting deadlocks, reachabil-

ity, etc.) and may be reused. The Petri-Net Ontology

has been formalized in OWL, but we were not able to

ﬁnd its OWL ﬁle.

Event-driven Process Chain (EPC) Ontology. EPC

has been developed in a joint effort between SAP

and

the Institute of Information Systems of Saarbr

ucken

in the context of the Architecture of Integrated In-

formation Systems (ARIS) framework (Keller et al.,

1992). EPC is a graphical BP modeling language;

its major strength is its simplicity and easy-to-

understand notation. Originally, EPC does not in-

clude a formal deﬁnition, but several works have pro-

posed formalized ontologies with or without exten-

sion over time (van der Aalst, 1999),(Thomas and

Fellmann, 2007). EPC has been developed to rep-

resent enterprise workﬂows. It has ﬁve key con-

cepts (Scheer et al., 2005): (i) FUNCTION that rep-

resents an activity speciﬁcation, (ii) EVENT to repre-

sent preconditions and post-conditions of FUNCTION,

(iii) CONTROL-FLOW that refers to a transition from

one EPC element to another, (iv) LOGICAL CONNEC-

TOR, such as OR, AND, and XOR, that connects at

least three FUNCTIONs, and ﬁnally (v) RESOURCE. A

LOGICAL CONNECTOR can either join or split FUNC-

TIONs. EPC does not support process execution. EPC

is formalized in OWL but it is not available.

Business Process Model and Notation (BPMN)

Ontology. BPMN is a standard

widely adopted by

companies that has been developed by the Object

Management Group (OMG)

. BPMN has two main

versions BPMN 1.0 and BPMN 2.0 (OMG, 2011).

The ﬁrst version has been published in 2008 while

the second one in 2011. An ontology has been de-

veloped from each version in (Rospocher et al., 2014)

and (Natschl

ager, 2011), respectively. In the follow-

ing, we consider only the BPMN 2.0 version since it

is the most recent and complete one. Indeed, it offers

an execution logic for its elements and a mapping to

the BP execution language (BPEL

)

BPMN meta-model offers a ﬁne grained represen-

tation of process speciﬁcation. A PROCESS is repre-

sented as a container that includes four types of el-

ements (or FLOW ELEMENTS): (i) ACTIVITY: an

Systems, Applications & Products in Data Processing

(SAP): a German multinational software corporation that

makes enterprise software to manage business operations

and customer relations.

https://www.iso.org/standard/62652.html

https://www.omg.org/about/index.htm

https://tinyurl.com/3xntz3

activity speciﬁcation that may be atomic (TASK) or

complex (SUB-PROCESS), (ii) EVENT: something

that happens, (iii) GATEWAY: a ﬂow control for

synchronization, and (iv) SEQUENCE FLOW: transi-

tions between the previous elements to complete the

representation of the workﬂow. Transitions may be

controlled with conditions. BPMN supports almost

all workﬂow patterns (e.g., Simple Merge, Exclusive

choice, loop) (van der Aalst et al., 2003), and repre-

sents advanced BP modeling paradigms like excep-

tion handling, transactions, and compensation. In ad-

dition, it allows to represent data requirements (i.e.,

DATA INPUT and DATA OUTPUT), and the agents or

roles that are responsible of a given activity. However,

it is not possible to deﬁne organizational or resource

models with BPMN.

BPMN offers speciﬁc events to deal with anoma-

lies such as the ERROR EVENT for interrupting errors

and ESCALATION EVENT for non interrupting errors.

In both cases, BPMN allows to represent the process

to be performed when these events occur.

Process execution is represented only through a

set of additional attributes for instances of process-

speciﬁcation concepts such as State (e.g., ”ready”,

”completed”, ”aborted”, etc.) for PROCESS, AC-

TUALOWNER – the actual actor that is performing

the activity – for ACTIVITY, etc. Thus, no ac-

tual distinction is made between process speciﬁca-

tion and process execution. Nevertheless, BPMN de-

ﬁnes the life-cycle model of activity instances, with

the events enabling transitions between them (OMG,

2011) (pp.428). To the best of our knowledge, the

OWL version of BPMN2.0 (Natschl

ager, 2011) is not

available to the community. However, BPMN meta-

model is available in BPMN speciﬁcation (a docu-

ment with more than 500 pages) as UML class dia-

grams (OMG, 2011). An XML version of this meta-

model is also available. However, BPMN speciﬁca-

tion includes a number of constraints (or speciﬁca-

tions) in natural language, that are represented neither

in the UML diagrams, nor in the XML ﬁle.

Business Process Modeling Ontology (BPMO).

BPMO was developed in the context of the SUPER

project to represent highlevel BP workﬂow models,

abstracting from existing BP notations and languages

(Cabral et al., 2009). BPMO supports only the rep-

resentation of process speciﬁcation. A PROCESS

has a WORKFLOW composed of WORKFLOW EL-

EMENTs: TASKs, EVENTs, BLOCK PATTERNS in-

spired from BPEL, and GRAPH PATTERNS inspired

from BPMN 1.0. BLOCK PATTERNS and GRAPH

PATTERNS are both control ﬂows representing work-

ﬂow decision points (van der Aalst et al., 2003).

Block-structured control ﬂows are deﬁned similar

Comparing Business Process Ontologies for Task Monitoring

639

to existing programming languages by using block-

structures such as ”if” or ”while”. Conversely, graph-

oriented language deﬁnes control ﬂows through ex-

plicit links between activities. For more details about

the difference between BP graphical and block lan-

guages, please refer to (Kopp et al., 2009). BPMO

has no graphical language of its own. BPMO is for-

malized in WSML-Flight which is an old formal lan-

guage. We did not ﬁnd an accessible link for BPMO.

Table 2 sums up the previous descriptions where

the symbols +, −, ≈ have the following meanings:

(i) +: the ontology supports the element represen-

tation, (ii) −: the ontology does not support the el-

ement representation, and (iii) ≈ : the key concept

is partially represented e.g., ≈ (agent) means among

resources only agents are represented. Furthermore,

for anomaly speciﬁcation, we used the ≈ symbol for

Petri-Net, EPC and BPMO because it is possible to

represent anomalies as events and activities, but there

is no speciﬁc concepts/relations for representing them

in these models. On the Data values line, ≈(as PP)

means that data values can be represented as precon-

ditions/ postconditions but not with a speciﬁc concept.

4 DISCUSSION

These ontologies and the project requirements guided

our modeling choices, in particular for the represen-

tation of process speciﬁcation and execution.

4.1 Process Speciﬁcation

As we can observe in Tab. 2, among the ontologies

developed from scratch, PSL is the one that covers

the most BP speciﬁcation elements. However, as ex-

plained earlier, in PSL, the deﬁnition of speciﬁcations

depends on the execution occurrences.

Ontologies obtained from existing BP languages

offer a richer representation of process speciﬁcations.

This may be explained by the maturity of BP lan-

guages and their evolution over the years, in particular

BPMN, the most recent and complete BP language.

Indeed, even if Petri-Net, EPC, BPMO, and BPMN

cover almost the same elements, BPMN stands out for

its expressiveness. Compared to Petri-Net and EPC,

BPMN offers much more concepts and relations to

represent the BP domain. For instance, while ”event”

is represented in EPC by a single general concept with

no formal semantic other than its annotation with a

term, BPMN offers a set of 48 concepts represent-

ing different event types with speciﬁc attributes and

clear semantics (e.g., timer event, start event, error

event, message event, etc.) that are classiﬁed into: (i)

catching/throwing events, and (ii) interrupting/non-

interrupting events.

4.2 Process Execution

Ontologies developed from scratch (except SMPO)

establish a clear distinction between process speciﬁ-

cation and process execution. As we can see in Tab 2,

the time perspective is covered by these ontologies,

which allows to keep trace of the different executions.

COBRA is distinguished by the ﬁne grained repre-

sentation of monitoring events, the different states

and possible transitions between them within the life-

cycle of processes/activities.

Ontologies extracted from BPM languages either

do not represent process execution such as EPC and

BPMO, or mix between process execution and pro-

cess speciﬁcation (i.e, no clear distinction) like Petri-

Net and BPMN. Indeed, Petri-Net execution con-

sists on the movement of the token over the net

(i.e., the graph representing the process). Hence,

the represented activities are considered as activity-

speciﬁcation and activity-execution at the same time.

The BPMN developers propose to instantiate the pro-

cess model than to add some attributes such as state

to the instances (activity instance, process instance,

etc.) without considering the time interval of any in-

stance. Process-speciﬁcation is an informational en-

tity that describes what and how to do, while process-

execution is a temporal entity that has a time interval

(start-date; end-date). Thus, we believe it is semanti-

cally more correct to differentiate these two concepts.

4.3 Vocabulary

One promising role of ontologies was to provide, for

each domain, a shared vocabulary with precise and

formal deﬁnitions that should improve the communi-

cation between different actors of these domains (ei-

ther humans or machines) (Gruber, 1991). However,

we observed a high terminological heterogeneity in

the studied ontologies. On the one hand, different

terms are used to label the same concepts. For in-

stance, the main concept denoting activity-execution

is labeled differently from one ontology to another:

(EO: ”Activity”), (PSL: ”Activity occurence”), (CO-

BRA: ”Process instance”), and (IMAMO: ”Process”).

Another example is the terms used to label the con-

cept representing the move of the execution ﬂow

from one element to another: (IMAMO: ”Tran-

sition”), (BPMN: ”Sequence ﬂow”), and (BPMO:

”Control ﬂow connector”), etc. On the other hand,

the same terms are used to label non-equivalent con-

cepts e.g., the term ”Process” is used to label activity-

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

640

Table 2: BP ontologies vs. key concepts.

Key concepts Comparison criteria

Ontologies from scratch Ontologies from BPM languages

EO PSL COBRA SMPO IMAMO Petri-Net EPC BPMN 2.0 BPMO

Speciﬁcation

Process decomposition + + + + + + + + +

workﬂow - ≈ - + + + + + +

PP - Data - ≈ + + - ≈ + + +

PP - Resource ≈(agent) ≈ + + ≈ (agent) ≈ + ≈ ( agent) -

PP - Activity dependency - ≈ - - + - - - -

PP - Time constraints - ≈ - - - ≈ + + +

PP - Event - ≈ - - - ≈ + + +

Anomaly description - - - - - ≈ ≈ + ≈

Anomaly solution - - - - - ≈ ≈ + ≈

Place - - - - - - - - -

Execution

Activities + + + + + - - ≈ -

Time + + + + + - - - -

State - + + + - + - + -

Events + + + - ≈ (anomaly) + - ≈ -

Data values ≈(as PP) + + + - ≈ - ≈ -

Involved resources + + + + ≈(agent) ≈ - ≈ (agent) -

Place - - - - - - - - -

Anomaly description - - - + + - - ≈ -

Anomaly solution - - - - + - - ≈ -

Organizational resources - - - - + - - - -

Organizational model + - - + - - - - -

Formal language Ontolingua OWL OCML UML OWL OWL OWL OWL/UML WSML

Accessibility of the formal version + + - - + - - -/+ -

Comparing Business Process Ontologies for Task Monitoring

641

speciﬁcation in COBRA, but activity-execution in

IMAMO. Such a high terminological heterogeneity

reﬂects the conceptual differences and makes it not

feasible to automatically align these ontologies us-

ing tools such as AML (Faria et al., 2013). Reusing

and combining these ontologies requires to manually

study the ontologies one by one in order to estab-

lish correspondences between equivalent/related con-

cepts. In the future, it would be interesting to deﬁne

a standard vocabulary that could be used as a pivot to

interconnect existing BP ontologies.

4.4 Synthesis

Based on the elements discussed previously, none of

the studied ontologies covers all the requirements of

the core ontology that we need, but as we may no-

tice they have common and complementary fragments

(see Tab.2). BPMN seems to be the most relevant

one for our project. In particular, because of its ex-

pressiveness that allows to capture the most of details

related to process speciﬁcation, which is essential in

our case since we aim at monitoring process execu-

tion step by step. Unfortunately, BPMN ontology is

not available. Hence, we will start by translating the

BPMN meta-model into an ontological model using

(OMG, 2011) and (Natschl

ager, 2011) .

Despite the richness of BPMN, it has some lim-

itations: (i) It does not represent the organizational

model and resources. Furthermore, it does not al-

low to specify the resource requirements (other than

agents) of an activity. (ii) There is no way to rep-

resent the place where the activities should be per-

formed (absent in all models). (iii) There is no ex-

plicit concept to represent process execution. To over-

come these limitations, we decided to reuse fragments

from the other ontologies such as the resource taxon-

omy of IMAMO, relations that represent the resource

requirements such as consumes, uses from COBRA

and the organizational model from EO (with the def-

inition of agent authorities and capabilities). Reusing

together BPMN and these fragments is harder than

expected due to (i) terminological heterogeneity and

differences in the formal languages, and (ii) the lack

of availability of the reused ontologies.

Furthermore, we will add concepts to represent

process execution such as ”Activity instance”, ”Pro-

cess instance” and ”time:interval” (from the Time on-

tology) as shown in Fig 2. This enrichment is inspired

from the COBRA ontology.

Figure 2: Example of enrichment with new concepts (those

with dashed line).

5 CONCLUSION

In this paper, we highlighted the main concepts that

should be covered by a BP core ontology, then we pre-

sented and compared nine popular business-process

ontologies. In particular, we focused on how these on-

tologies deal with the representation of process spec-

iﬁcation and process execution.

Regarding our project, BPMN seems the best can-

didate to start with. However, BPMN alone does not

cover all the requirements, which leads us to reuse

fragments from the other ontologies.

ACKNOWLEDGEMENTS

This work within the AVI-REX project is funded

by a grant from region Occitanie, the FEDER-FSE

Midi-Pyr

ees and Garonne 2014-2020 program un-

der the label 2017-AVI-REX-IRIT-READYNOV IN-

DUSTRIE DU FUTUR.

REFERENCES

Abdalla, A., Hu, Y., Carral, D., Li, N., and Janowicz, K.

(2014). An Ontology Design Pattern for Activity Rea-

ICAART 2020 - 12th International Conference on Agents and Artiﬁcial Intelligence

642

soning. In 5th WS on Ontology and Semantic Web

Patterns (WOP), pages 78–81, Riva del Garda, Italy.

Cabral, L., Norton, B., and Domingue, J. (2009). The busi-

ness process modelling ontology. In 4th Int. WS on

semantic business process management, pages 9–16.

Dumas, M., La Rosa, M., Mendling, J., and Reijers, H. A.

(2013). Introduction to Business Process Manage-

ment, pages 1–31.

Faria, D., Pesquita, C., Santos, E., Palmonari, M., Cruz,

I. F., and Couto, F. M. (2013). The agreementmak-

erlight ontology matching system. In On the Move

to Meaningful Internet Systems OTM, Graz, Austria,

pages 527–541.

Gruber, T. R. (1991). The role of common ontology in

achieving sharable, reusable knowledge bases. In 2nd

International Conference on Principles of Knowledge

Representation and Reasoning (KR). Cambridge, MA,

USA, pages 601–602.

uninger, M. (2009). Using the psl ontology. In Handbook

on Ontologies, pages 423–443. Springer.

uninger, M. and Fox, M. S. (1995). The Role of Compe-

tency Questions in Enterprise Engineering. In Bench-

marking Theory and practice, pages 22–31.

Gruninger, M. and Menzel, C. (2003). The process spec-

iﬁcation language (psl) theory and applications. AI

magazine, 24(3):63–74.

Hepp, M. and Roman, D. (2007). An ontology frame-

work for semantic business process management. In

8th Internationale Tagung Wirtschaftsinformatik (WI),

Karlsruhe, Germany, pages 423–440.

Karray, M. H., Chebel-Morello, B., and Zerhouni, N.

(2012). A formal ontology for industrial maintenance.

Applied ontology, 7(3):269–310.

Keller, G., N

uttgens, M., and Scheer, A. (1992). Semantis-

che prozeßmodellierung auf der grundlage ”ereignis-

gesteuerter prozeßketten (epk)”. Ver

o ffentlichungen

des Instituts f

ur Wirtschaftsinformatik, (89).

Kopp, O., Martin, D., Wutke, D., and Leymann, F. (2009).

The difference between graph-based and block-

structured business process modelling languages. En-

terprise Modelling and Information Systems Architec-

tures, 4(1):3–13.

Koschmider, A. and Oberweis, A. (2005). Ontology based

business process description. In The Open Interop

Workshop on Enterprise Modelling and Ontologies for

Interoperability, pages 321–333.

Lautenbacher, F., Bauer, B., and Seitz, C. (2008). Semantic

business process modeling - beneﬁts and capability.

In AI Meets Business Rules and Process Management,

2008 AAAI Spring Symposium, Technical Report SS-

08-01, Stanford, Cal., USA, pages 71–76.

Lu, R. and Sadiq, S. (2007). A Survey of Comparative Busi-

ness Process Modeling Approaches. In Business In-

formation Systems, pages 82–94.

Masolo, C., Borgo, S., Gangemini, A., Guarino, N., Oltra-

mari, A., and Schneider, L. (2003). The wonderweb

library of fundational ontologies and the DOLCE on-

tology. The WonderWeb Library of Fundational On-

tologies and the DOLCE ontology. WonderWeb Deliv-

erable D18, Final Report (vr. 1. 0.).

Natschl

ager, C. (2011). Towards a BPMN 2.0 ontology. In

3rd Int. WS on Business Process Modeling Notation,

pages 1–15, Lucerne, Switzerland.

OMG (2011). Business Process Modeling Notation, v2.0 -

Speciﬁcation. Technical report, Object Management

Group.

Pedrinaci, C., Domingue, J., and de Medeiros, A. K. A.

(2008). A core ontology for business process analysis.

In 5th European Semantic Web Conference, ESWC,

Tenerife, Canary Islands, Spain, pages 49–64.

Pouchard, L. C., Cutting-Decelle, A., Michel, J.-J., and

uninger, M. (2005). Iso 18629 psl: A standardised

language for specifying and exchanging process infor-

mation. IFAC Proceedings Volumes, 38(1):37–45.

R. Gruber, T. (1995). Toward principles for the design of

ontologies used for knowledge sharing? International

journal of human-computer studies, 43(5-6):907–928.

Rospocher, M., Ghidini, C., and Seraﬁni, L. (2014). An on-

tology for the Business Process Modelling Notation.

In 8th International Conference on Formal Ontology

in Information Systems (FOIS), pages 133–146.

Ruiz, F., Garcia, F., Piattini, M., and Polo, M. (2003). Envi-

ronment for managing software maintenance projects.

In Advances in software maintenance management:

technologies and solutions, pages 255–291.

Scheer, A.-W., Thomas, O., and Adam, O. (2005). Process

modeling using event-driven process chains. Process-

aware information systems, pages 119–145.

Thomas, O. and Fellmann, M. (2007). Semantic EPC: en-

hancing process modeling using ontology languages.

In WS on Semantic Business Process and Product

Lifecycle Management (SBPM), Innsbruck, Austria.

Uschold, M., King, M., Moralee, S., and Zorgios, Y. (1998).

The enterprise ontology. The knowledge engineering

review, 13(1):31–89.

van der Aalst, W. M. (1999). Formalization and veriﬁca-

tion of event-driven process chains. Information and

Software technology, 41(10):639–650.

van der Aalst, W. M. (2013). Business process manage-

ment: a comprehensive survey. ISRN Software Engi-

neering, 2013:1–37.

van der Aalst, W. M. P. (2015). Business process manage-

ment as the “killer app” for petri nets. Software &

Systems Modeling, 14(2):685–691.

van der Aalst, W. M. P., ter Hofstede, A. H. M., Kie-

puszewski, B., and Barros, A. P. (2003). Work-

ﬂow patterns. Distributed and Parallel Databases,

14(1):5–51.

Vogel-Heuser, B. and Hess, D. (2016). Guest Edito-

rial Industry 4.0 Prerequisites and Visions. IEEE

Transactions on Automation Science and Engineer-

ing, 13(2):411–413.

Comparing Business Process Ontologies for Task Monitoring

643