Open Research Online
The Open University’s repository of research publications
and other research outputs
The business process modelling ontology
Conference or Workshop Item
How to cite:
Cabral, Liliana; Norton, Barry and Domingue, John (2009). The business process modelling ontology. In: 4th
International Workshop on Semantic Business Process Management (SBPM 2009), Workshop at ESWC 2009, 1 Jun
2009, Crete, Greece.
For guidance on citations see FAQs.
c
2009 The Author
Version: Accepted Manuscript
Link(s) to article on publisher’s website:
http://dx.doi.org/doi:10.1145/1944968.1944971
http://sbpm2009.fzi.de/
Copyright and Moral Rights for the articles on this site are retained by the individual authors and/or other copyright
owners. For more information on Open Research Online’s data policy on reuse of materials please consult the policies
page.
oro.open.ac.uk
The Business Process Modelling Ontology
Liliana Cabral
KMi, The Open University
Milton Keynes, UK
+44 1908 653800
l.s.cabral@open.ac.uk
Barry Norton
KMi, The Open University
Milton Keynes, UK
+44 1908 653800
b.j.norton@open.ac.uk
John Domingue
KMi, The Open University
Milton Keynes, UK
+44 1908 653800
j.b.domingue@open.ac.uk
ABSTRACT
In this paper we describe the Business Process Modelling
Ontology (BPMO), which is part of an approach to modelling
business processes at the semantic level, integrating knowledge
about the organisational context, workflow activities and
Semantic Web Services. We harness knowledge representation
and reasoning techniques so that business process workflows can:
be exposed and shared through semantic descriptions; refer to
semantically annotated data and services; incorporate
heterogeneous data though semantic mappings; and be queried
using a reasoner or inference engine. In this paper we describe our
approach and evaluate BPMO through a use case.
Categories and Subject Descriptors
I.2.4 [Knowledge Representation Formalisms and Methods]:
Representations. F.3.2 [Semantics of Programming
Languages]:
Process models.
General Terms
Design, Standardization, Management, Languages.
Keywords
Semantic Business Process Modelling, Semantic Interoperability,
Ontology, Workflow Management.
1. INTRODUCTION
Business organisations today need agility and flexibility to deal
with highly dynamic environments, providing ever-changing
services and products as well as in interacting with diverse
customers and partners. A significant problem in the area of
Business Process Management (BPM) lies in bridging between
the organisational context, the diverse process workflow
notations, and the executable services that fulfill process
activities, by which business analysts would like to understand,
maintain and adapt their business processes.
Currently, business analysts use process modelling notations such
as BPMN [11] and EPC [14] to define business process models as
part of tool suites for BPM. These notations are useful at the
business level, but alone they provide no inference reasoning over
business processes. For example, BPMN tools are rich in control-
flow constructs, but the graphical elements contain only limited
textual information with no formal semantics. Some EPC-based
tools such as ARIS [14] on the other hand, provide integration of
different views (e.g. organisation, data and control) and levels
(e.g. requirements and implementation); however mediating
between these views and levels is a very complex task due to the
variety of underlying representations. In addition, it is very
difficult to use these notations to automatically query the business
context or draw relations between existing processes or services.
In this paper we present the Business Process Modelling
Ontology
1
(BPMO), which plays a key role in solving the
problem above, by enabling the semantic annotation of high-level
business process models, which we assume can be fulfilled by
Web services. This work is part of the SUPER project
2
, which in
particular provides a set of integrated ontologies for facilitating
Semantic Business Process Management [6].
The rest of this paper is structured as follows. Section 2 describes
the BPMO approach. Section 3 describes the main concepts of
BPMO. Section 4 illustrates the use of BPMO and shows results
through a use case. Section 5 presents our conclusions and related
work.
2. APPROACH OVERVIEW
The Business Process Modelling Ontology (BPMO) is part of an
approach to modelling business processes at the semantic level,
integrating knowledge about the organisational context, workflow
activities and Semantic Web Services. This approach provides
support for various BPM activities, from modelling and querying
to execution and analysis; regardless of specific notations in a
manner which crosses domains and organisational boundaries. We
harness a number of knowledge representation and reasoning
techniques so that business process workflows can: be exposed
and shared through semantic descriptions; refer to semantically
annotated business data and services; incorporate heterogeneous
data though semantic mappings; and be queried using a reasoner
or inference engine. We argue therefore, that BPMO enables
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
1
http://www.ip-super.org/ontologies/process/bpmo/v2.0.1#bpmo
2
Semantics Utilised for Process Management within and between
Enterprises (http://www.ip-super.org)
seamless interoperation, querying, sharing, mediation and
translation of business processes.
Within our approach, a business analyst can draw a business
process diagram with a tool that automatically generates BPMO
instances (see example in Section 3), or he can use translators that
will transform specific notations from and to BPMO. BPMO can
thus be viewed as a bridging ontology enabling the annotation of
business processes workflows extended with organisational
context and automated translation between an open-ended set of
existing notations and languages.
As we will show in the rest of the paper, the BPMO model
captures domain independent organisational aspects, control-flow
features of notations such as BPMN, via a number of workflow
patterns as in [1], process interaction features from BPEL
3
, and
finally service description and invocation features from Semantic
Web Services (SWS) [4]. BPMO builds on the formalization of
Business Process Diagrams as presented in [12], and as such is
oriented towards the production of well-formed workflow models,
where graphs decompose unambiguously into sub-graphs that
start and end with compatible constructs.
More specifically, in the SUPER project we provide ontologies
for standards such as BPMN, EPC and BPEL (see [2], [5], [10])
as well as corresponding translators to BPMO. In addition, it is
possible for business analysts to create alternative organisational
ontologies to define BPMO process organisational attributes. This
is done via UPO
4
(Upper-level Process Ontology), an ontology
defining high-level business process concepts, which are shared
by all ontologies in SUPER.
A BPMO diagram can be defined using the WSMO Studio BPMO
Modeller tool
5
, which automatically generates instances of BPMO
in WSML [16]. More precisely, we use WSML-Flight, which
adds F-Logic like features to the WSML core, directly supporting
WSMO Web Service descriptions [4]. WSML- Flight also allows
us to apply data mappings (via rule-type axioms) directly in the
ontology language without having to rely on a hybrid approach of
a separate rule language. BPMO and the related ontologies
mentioned above are publicly available at the SUPER website
(http://www.ip-super.org/ontologies).
3. BPMO DESCRIPTION
BPMO is a representation for high-level business process
workflow models, abstracting from existing business process
notations. Nevertheless, the workflow elements of a BPMO
process diagram comply with a corresponding subset of BPMN
control-flow elements and are informed by, and named according
to Workflow Patterns [1]. Moreover, BPMO concepts related to
interaction activities (e.g. Send, Receive) have a number of
attributes that correspond to BPEL constructs.
Basically, a BPMO process description captures the business
context of the modelled process and contains the process
workflow, which represents the behaviour of the process (through
control-flow and data-flow constructs) and process activities
(through Tasks). The main BPMO process elements are structured
as follows (see Table 1):
3
http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf
4
http://www.ip-super.org/ontologies/process/upo/v2.0.1#upo
5
http://www.wsmostudio.org/
• Workflow – The business process container for Workflow
Elements. The initial Workflow Element may be a
StartEvent or a block pattern, commonly a Sequence or
ParallelSplit Synchronise. If the StartEvent is present,
subsequent elements will be linked in graph style by
Controlflow Connectors. If the Workflow Element is a
Sequence, a sequence flow is implicit between the contained
elements. If the Workflow Element is
ParallelSplitSynchronise, a parallel flow is implicit.
• Workflow Elements – These are general elements that
belong to a business process workflow, including Processes,
Tasks, Events, block patterns and graph patterns;
• Block Patterns – These are structured or pattern-based
control-flow elements representing workflow decision points
(gateways), including Sequence, ParallelSplitSynchronise,
ExclusiveChoiceMerge, DeferredChoiceMerge, While,
Repeat, and so on.
• Graph patterns – These are link based control-flow elements
representing workflow decision points (gateways), including
ParallelSplit, ExclusiveChoice, DeferredChoice,
SimpleMerge, Synchronise, and so on.
As can be seen, BPMO combines features of block-oriented and
graph-oriented workflow models. The main purpose of block
patterns is to explicitly represent structured elements and
workflow patterns that can be used to facilitate process
verification and the translation to notations in the execution level.
The BPMO design enforces well formed diagrams, via graph
patterns and structures, but further restrictions can be easily
provided via axioms.
Table 1 Description of main BPMO Process Elements
BPMO Element Description
StartEvent An event signalling the start of a process
TimerEvent An event signalling that a specific time has been
reached
ErrorEvent An event signalling that an error has occurred
EndEvent An event signalling the end of a process
Task An atomic activity within a Process.
Goal Task
A Task with an attached Semantic Capability, used
for invoking SWS goals
Send A Task for sending messages. Provides a semantic
description of the requested capability.
Receive A Task for receiving messages. Provides a semantic
description of the provided capability.
ReceiveMessageEvent A Receive task associated with an event (which may
resolve choices, see DeferredChoice).
Mediation Task A Task for dataflow and data mediation
Sequence An ordered set of activities (also a linked list) with an
implicit sequence flow (Block pattern)
ParallelSplit A gateway (or decision point) for creating concurrent
branches
Synchronisation A gateway for synchronizing concurrent branches
ParallelSplitSynchronis
e
ParallelSplit with an implicit Synchronisation (Block
pattern)
ExclusiveChoice A decision gateway for selecting one out of a set of
mutually exclusive alternative branches based on
BPMO Element Description
data. One of the branches may be default.
ExclusiveChoiceMerge Exclusive Choice with an implicit Simple Merge
(Block pattern )
DeferredChoice A decision gateway for selecting one out of a set of
mutually exclusive alternative branches based on
external event
DeferredChoiceMerge Deferred Choice with an implicit Simple Merge
(Block pattern)
SimpleMerge Gateway for joining a set of mutually exclusive
alternative branches into one branch
MultipleChoice A decision gateway for selecting many out of a set of
alternative branches into several parallel branches
based on data. One of the branches may be default.
MultipleMerge Unsynchronised convergence of two or more distinct
branches
MultipleChoiceMerge Multiple Choice with an implicit Multiple Merge
(Block pattern)
MultipleMergeSynchro
nise
Synchronised convergence of two or more distinct
branches
Repeat A structured loop where the condition is evaluated
after the body of the loop is executed
While A structured loop where the condition is evaluated
before the body of the loop is executed
We will discuss next the use of a number of key BPMO concepts,
which are defined in WSML, including Process, Business
Activity, Task (Send, Receive, GoalTask), SemanticCapability,
MediationTask and DataMediator.
The Process concept (shown in Listing 1) defines several
organisational attributes, by inheriting from BusinessActivity,
according to the types BusinessDomain, BusinessFunction,
BusinessStrategy, BusinessPolicy, BusinessProcessMetrics,
BusinessProcessGoal and BusinessResource. These business-level
concepts (attribute types) are primarily defined in external
ontologies, which model a specific business domain and
organisation. These ontologies are linked to the BPMO process by
subclassing the UPO concept (note that upo# is the prefix for the
UPO namespace). As a result, we enable the querying of
processes against organisational aspects by business analysts (see
example in the next section). The Process itself can also have a
corresponding Web Service description (hasWSDescription
attribute). In addition, the Process concept defines the process
workflow (attribute hasWorkflow). The concept Workflow defines
the first element of the workflow (hasFirstWorkflowElement).
The workflow is modelled with Workflow Elements contained in
or following (via connectors) the first element.
Listing 1. Process and Business Activity Concepts
Concept BusinessActivity subConceptOf
upo#BusinessActivity
hasName ofType (0 1) _string
hasDescription ofType (0 1) _string
hasNonFunctionalProperties ofType (0 1)
BusinessActivityNonFunctionalProperties
hasBusinessDomain ofType upo#BusinessDomain
hasBusinessFunction ofType upo#BusinessFunction
hasBusinessStrategy ofType upo#BusinessStrategy
hasBusinessPolicy ofType upo#BusinessPolicy
hasBusinessProcessMetrics ofType
upo#BusinessProcessMetrics
hasBusinessProcessGoal ofType upo#BusinessProcessGoal
hasBusinessResource ofType upo#Resource
concept Process subConceptOf {BusinessActivity,
upo#BusinessProcessModel}
hasWSDescription ofType(0 1) SemanticCapability
hasWorkflow ofType (0 1) Workflow
concept Workflow subConceptOf
upo#ProcessOrchestrationSpecification
hasHomeProcess ofType (0 1) Process
hasFirstWorkflowElement ofType(1 1) WorkflowElement
The concepts related to interaction tasks in BPMO are GoalTask,
Receive, Send and ReceiveMessageEvent (see Listing 2), which
are subconcepts of Task. A Task is also a Business Activity (as in
Listing 1) and thus can also refer to business attributes such as a
business policy or a business process goal. Tasks have attributes
to represent information about the interaction with a partner
process, such as partner role (hasPartnerRole), inputs
(hasInputDescription) and outputs (hasOutputDescription). Most
attribute types in Tasks are defined as SemanticCapability which
is a wrapper for ontology elements or service descriptions. For
example, a SemanticCapability instance can refer to the URI of an
concept within an ontology or to the URI of a Web Service or
Goal description.
Listing 2. Concepts related to interaction tasks
concept GoalTask subConceptOf Task
hasPartnerGoal ofType (0 1) SemanticCapability
hasPartnerRole ofType (0 1) BusinessRole
messageTo ofType (0 1) Receive
messageFrom ofType (0 1) Send
hasInputDescription ofType SemanticCapability
hasOutputDescription ofType SemanticCapability
requestsCapability ofType (0 1) SemanticCapability
providesCapability ofType (0 1) SemanticCapability
concept Send subConceptOf Task
hasPartnerWebService ofType (0 1)SemanticCapability
hasPartnerRole ofType (0 1) BusinessRole
hasReceiveCounterpart ofType (0 1) Receive
messageTo ofType (0 1) Receive
hasOutputDescription ofType SemanticCapability
requestsCapability ofType (0 1) SemanticCapability
concept Receive subConceptOf Task
hasPartnerWebService ofType (0 1 SemanticCapability
hasPartnerRole ofType (0 1) BusinessRole
hasSendCounterpart ofType Send
messageFrom ofType (0 1) Send
hasInputDescription ofType SemanticCapability
providesCapability ofType (0 1) SemanticCapability
concept ReceiveMessageEvent subConceptOf {
IntermediateEvent, Receive}
A GoalTask represents an atomic activity, which can be
automatically achieved through a SWS invocation (synchronous
communication). The attribute hasPartnerGoal is used in this
case to refer to the Goal description. The hasInputDescription and
hasOutputDescription attributes refer to the semantic descriptions
of request and response data respectively. Hence, dataflow is
enabled by sharing the same data description across tasks in the
workflow. The requestsCapability and providesCapability
attributes refer to the semantic descriptions of operations related
to request and response respectively. The Send and Receive tasks
are similar to Goal tasks, but they are used for asynchronous
communication. A Receive task can be associated with a Send in
the same workflow via the hasSendCounterpart attribute (and
conversely for Send). ReceiveMessageEvent works as a Receive
task, but is also associated to an event, which is triggered when a
message is received.
Listing 3. Concepts related to Mediation
concept MediationTask subConceptOf Task
hasSourceTask ofType (0 1) Task
hasTargetTask ofType (0 1) Task
hasDataMediator ofType DataMediator
concept Mediator subConceptOf upo#BusinessProcessMediator
hasName ofType (0 1) _string
hasDescription ofType (0 1) _string
concept ProcessMediator subConceptOf Mediator
hasSourceProcess ofType (1 1) Process
hasTargetProcess ofType (1 *) Process
hasMediationProcess ofType (0 1) MediationProcess
hasSWSMediator ofType (0 1) SemanticCapability
concept DataMediator subConceptOf Mediator
hasMediator ofType SemanticCapability
hasMediationService ofType SemanticCapability
hasInputDescription ofType (0 1) SemanticCapability
hasOutputDescription ofType(0 1) SemanticCapability
concept MediationProcess subConceptOf Process
BPMO also supports data and process mediation through a
number of concepts as shown in Listing 3. See also the examples
in the next section. A MediationTask is a task that provides data
mapping specifications to be used between tasks during runtime.
A MediationTask can have one or more DataMediators. The
DataMediator concept refers to a data mediator or mediation
service and the input and output for them. In a typical use case,
the hasMediator attribute will refer to a mapping definition
(URI), the hasInputDescription will refer to a source ontology
(URI) and the hasOutputDescription will refer to a target
ontology (URI). In addition, the ProcessMediator concept is used
as a descriptor to identify a process with a mediation role
(hasMediation Process) and mediated processes
(hasSourceProcess, hasTargetProcess) in order to facilitate the
job of tools for verification and creation of mediation processes.
The ProcessMediator can also refer to a mediator component
(hasSWSMediator).
4. USE CASE
In this section we will illustrate and evaluate the BPMO model
through an example taken from the mediation scenario provided
in the SWS Challenge (http://sws-challenge.org). This scenario is
about a Purchase Order process and involves three partners: the
service requester (customer), company Blue, which order
products; the service provider, company Moon, which sells
products; and the mediator, which must be implemented to
mediate between Blue and Moon. The goal of the mediator is to
map the incoming and outgoing messages between Blue and
Moon and also invoke required services from Moon so that the
interactions necessary to buy a product is complete. Company
Blue sends a purchase order and receives an acknowledgment via
the mediator. In this paper we focus on the part of the solution
comprising the use of ontology based-technology, required to
solve the scenario above. We use BPMO for modelling the main
process using SWS references for Task descriptions, and domain
ontologies for modelling data and mappings.
We created a BPMO diagram to represent the mediator process
(Moon Mediator Process) as shown in Figure 1, using WSMO
studio’s BPMO modeller. The modeller generates an initial set of
BPMO instances corresponding to the process control-flow, to
which the user can add data instances for attributes using the
modeller’s property editor. A number of BPMO instances
corresponding to the diagram presented in Figure 1 are shown in
Listing 4.
Figure 1. BPMO diagram of the Mediator process
The Moon Mediator Process workflow is quite self-explanatory.
Basically, we used activities Receive Purchase Order and Send
PO Confirmation to interact with the Blue Company, modelled as
Receive and Send BPMO tasks accordingly. Map Purchase Order
and Map Result are modelled as Mediation Tasks and used to map
the values needed by the Moon and Blue Web Services,
respectively. Search Customer, Create Order and Close Order are
modelled as Goal Tasks for invoking Web Services provided by
Moon. Add Line Item and Confirm Line Item are modelled as
corresponding asynchronous Send and Receive tasks, which are
called in a Repeat (loop) for every item in the received Purchase
Order. Start and End are events used to initiate and finalise the
process.
Listing 4. BPMO instances for the Moon Mediator Process
instance Process_MoonMediator memberOf bpmo#Process
bpmo#hasName hasValue "Moon Mediator Process"
bpmo#hasWorkflow hasValue Workflow_1217
bpmo#hasBusinessStrategy hasValue moon#strategy45
bpmo#hasBusinessPolicy hasValue moon#policy33
upo#hasInvolvedRole hasValue moonMediator
instance moonMediator memberOf bpmo#BusinessRole
bpmo#hasName hasValue "Moon Mediator"
bpmo#hasOrganisation hasValue kmi
instance kmi memberOf upo#Organisation
upo#hasName hasValue "KMi, The Open University, UK"
instance blue memberOf upo#Organisation
upo#hasName hasValue "Blue, SWS Challenge"
instance customer memberOf bpmo#BusinessRole
bpmo#hasName hasValue "Blue Customer"
bpmo#hasOrganisation hasValue blue
instance moon memberOf upo#Organisation
upo#hasName hasValue "Moon, SWS Challenge"
instance moonCRM memberOf bpmo#BusinessRole
bpmo#hasName hasValue "Moon Customer Relationship
Management"
bpmo#hasOrganisation hasValue moon
instance Workflow_1217 memberOf bpmo#Workflow
bpmo#hasHomeProcess hasValue Process_MoonMediator
bpmo#hasFirstWorkflowElement hasValue StartEvent_1
instance StartEvent_1 memberOf bpmo#StartEvent
bpmo#hasHomeProcess hasValue Process_MoonMediator
bpmo#hasName hasValue "Start"
instance ControlflowConnector_100 memberOf
bpmo#ControlflowConnector
bpmo#hasHomeProcess hasValue Process_MoonMediator
