ontology-based description and discovery of business processes

Ontology-based Description and Discovery of Business Processes

Khalid Belhajjame, Marco Brambilla

University of Manchester, UK. Politecnico di Milano, Italy

Contact: [email protected]

K. Belhajjame, M. Brambilla. Ontology-based Discovery of BPs.

2Agenda

Intro and motivation Objectives Related works Some definitions BP description BP discovery Implementation notes Conclusions


3Introduction

Increased acceptance of BP as founding abstraction of enterprise behavior

Large amount of BP descriptions in large organizations Need of effective and efficient ways for retrieving,

managing, and reusing BPs concepts However: lack of effective retrieval (wrt precision, recall)

• Few results returned• Not really what is needed


4Objectives

a workflow is not a complete description of a business processes (BP)

Semantic description can add value both intrinsically and for BP discovery/usage

Goals Exploiting relationships between business

processes: dependencies between BP can be explicitly described in the ontology for increasing the recall of discovery queries.

Abstracting discovery queries: The user is able to formulate his/her queries in terms of the tasks (semantics) fulfilled by the desired business processes.

Increasing recall of discovery


5Related and background works

Foundations BP inheritance [van der Aalst et al., 2002] Semantics of business processes and similarity [van Glabbeek, 2001]

Existing BP discovery approaches Query mechanism on the process structure and topology only: BP-QL

[Beeri et al., 2006], process variants [Lu and Sadiq, 2006], service matchmaking [Corrales et al., 2006]

Exploiting activity similarity [Goderis et al., 2006], flexible BP queries [Markovic et al., 2008]

iSPARQL-based semantic process inter-organization matching [Kiefer et al., 2007]

OWL-WS [Beco el al., 2005] for grid architectures, no relations between BPs

inexact matching approach based on SQL-like queries on ontology repositories [Zhuge et al., 2002], but: ontology cannot be automatically built and does not include explicit relationships. Only exploits distances


Business Process

Business Process:= <nameBP, A, CF> where: nameBP is the name identifying the business process. A is the set of activities composing BP. An activity a is

<nameA, roleA> CF is (A x OP) U (OP x A) is the controlflow

An abstract business process (ABP) is a representative of a class of equivalent business processes, sharing the same set of activities and flow structure.

An ABP can be implemented by several concrete business processes.

ABP activities are generic task descriptions, associated with semantic labels about the capabilities and the data to be consumed and produced


Task ontology

The task ontology captures information about the action carried out by the activities within a domain of interest

A concept for every task E.g., in the ecommerce domain it may include

quotation request, order confirmation, and credit card payment.


Task mappings

Mapping between ABPs: two classes of functions MapEquiv: to map the tasks of a given ABP to the

tasks of another ABP that perform the same or equivalent tasks.

MapSpec: to map the tasks of a given ABP to the tasks of another ABP that perform equivalent or more specific tasks


Process ontology

The business process ontology (BPO) comprises concepts designating ABPs.

Given a concept c from business process ontology, a function getABP: BPO ABP retrieves the abstract business process designated by c.

The concepts in the ontology BPO are related using binary

properties that encode relationships between ABPs.

Currently, four binary properties to encode process relationships: equivalence, specialisation, overlap, and partOf.


Process relations

EQUIVALENCE: iff the respective constituent tasks are equivalent tasks and are connected using the same control flow.

SPECIALIZATION: iff the tasks of ABP1 are equivalent to or more specific than the tasks of ABP2, and that they have the same control flow.

PART-OF: ABP1 is part-of ABP2 iff there exists an ABP3 that is equivalent to ABP1 and that is sub-process of ABP2.

OVERLAP: Two concepts c1 and c2 overlap iff their respective ABPs have one or more tasks in common.


Building the ontology

The BPO ontology needs to be built!

defineConcept: ABP BPO defineProperty: PROPERTY x BPO x BPO Boolean addInstance: BP x OBP Boolean


Todo list: Algorithm GenerateOntology

input BPO, BPoutput BPO’begin

for each bp in BP doabp = abstract(bp)

if (exists c in BP , abp = getAbstractBP(c))then

addInstance(bp,c)else

c := defineConcept(abp)addInstance(bp,c)

deriveAndAssertProperties(c)end


BP query and discovery

A discovery query is an ABP designed by the user by selecting concepts from the task ontology and connecting them using a control flow graph.

We distinguish the following cases for discovering the business processes that implement the specified ABP:

1. A concept is equivalent to the ABP specified by the user. Result: instances(ABP)

2. No concept in the business process ontology that is equivalent to the ABP specified by the user. Result: subconcepts(ABP)

3. The business process ontology may not contain any concept that is equivalent or subconcept of the ABP specied by the user. Then: attempt to create business processes that match the user request by aggregating other business processes


Building aggregated BP as tentative responses

1. The set of concepts ABP’ in the business process ontology designating abstract business processes that are part of the query ABP are retrieved.

2. Subsets ABP’’ are extracted for which the union of tasks is a set that contains all the tasks required for building the query ABP.

3. A new ABP (abp’’) is defined as composition of the ABP’’ elements, using the respective controlflow primitives.

4. The result is defined as all the BPs that are obtained by substituting the abstract business processes abp’’ with their instances


Discovery by example

A concrete BP is given instead of an ABP.

Same technique, preceded by:

Building an abstract business process that corresponds to the business process specified by the user


Implementation notes

As an ontology language, we use OWL. As starting point, we took the myGrid Ontology, (branch named task)

Protégé was used to browse the ontology using a GUI Java-based implementation The reasoner Pellet was used for semantic reasoning To query and browse the ontology programatically, we

made use of OWLAPI (owlapi.sourceforge.net)


Conclusions and future work

Basic ontology-based framework for classifying and retrieving business processes

Exploitation of power of semantic descriptions of: Tasks, Business processes, Relations between processes

Ongoing and future work: Definition of more sophisticate relationships between BP and

between tasks Refinement of BP composition technique (parameters, ...) Validation on industrial repositories (finance) Exploitation of control flow topology Solid implementation with effective user interface for:

• Task and BP ontology editing

• Query submission

• Result presentation

Thanks

Khalid Belhajjame, Marco Brambilla

University of Manchester, UK. Politecnico di Milano, Italy

Contact: [email protected]


A (very) small example

ontology-based description and discovery of business processes

Technology