SlideShare a Scribd company logo

Modeling and Reasoning over Declarative Data-Aware Processes

Faculty of Computer Science - Free University of Bozen-Bolzano, profile picture
Faculty of Computer Science - Free University of Bozen-Bolzano

The document discusses the co-evolution of data-aware processes, focusing on modeling and reasoning with decision-making tables that interpret rules for ship clearance and refuel area determination. It highlights the challenges posed by conventional notations that encourage a separation between different object types within a process, advocating for a case-centric approach. Various examples and diagrams illustrate beginner mistakes in capturing job hiring processes and emphasize the importance of instance alignments.

Science
1 of 91
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
Modeling and Reasoning over declarative data-aware processes Marco Montali montali@inf.unibz.it KRDB SOS, 22/05/2020 joint work with Wil van der Aalst, Alessandro Artale, Alisa Kovtunova
Forgive me, logicians!
Data and processes A challenging, but necessary marriage! Typical choice: divide and conquer, 
 separating structural and dynamic aspects
Cer. Exp. (date) Length (m) Draft (m) Capacity (TEU) Cargo (mg/cm2) 0 0 0 0 0 Enter y, n U Ship Clearance  today > today < 260 < 10 < 1000 > today < 260 < 10 1000 > today < 260 [10,12] < 4000  0.75 > today < 260 [10,12] < 4000 > 0.75 > today [260,320) (10,13] < 6000  0.5 > today [260,320) (10,13] < 6000 > 0.5 > today [320,400) 13 > 4000  0.25 > today [320,400) 13 > 4000 > 0.25 n y n y n y n y n 1 2 3 4 5 6 7 8 9 Table 1: DMN representation of the ship clearance decision of Figure 1b Enter Length (m) Cargo (mg/cm2) y,n 0 0 Refuel Area none, indoor, outdoor U Refuel area determination n y  350 y > 350  0.3 y > 350 > 0.3 none indoor indoor outdoor 1 2 3 4 Table 2: DMN representation of the refuel area determination decision of Figure 1b er their corresponding datatypes. In Table 1, the input attributes are: (i) the certificate expira- on date, (ii) the length, (iii) the size, (iv) the capacity, and (v) the amount of cargo residuals of ship. Such attributes are nonnegative real numbers; this is captured by typing them as reals, ding restriction “ 0” as facet. The rightmost, red cell represents the output attribute. In both ses, there is only one output attribute, of type string. The cell below enumerates the possible tput values produced by the decision table, in descending priority order. If a default output is fined, it is underlined. This is the case for the none string in Table 2. Every other row models a rule. The intuitive interpretation of such rules relies on the usual f . ..then ...” pattern. For example, the first rule of Table 1 states that, if the certificate of the ip is expired, then the ship cannot enter the port, that is, the enter output attribute is set to n egardless of the other input attributes). The second rule, instead, states that, if the ship has a lid certificate, a length shorter than 260 m, a draft smaller than 10 m, and a capacity smaller an 1000 TEU, then the ship is allowed to enter the port (regardless of the cargo residuals it rries). Other rules are interpreted similarly. Ship id-code name Certi fi cate exp-date Harbor location Attempt when outcome tried entering into owns 1 0..1 * * receive entrance request record ship info inspect ship ship id acquire certificate record cargo residuals record exp. date cargo residuals certificate exp. date decice clearance enter refuel area enter? send refusal send fuel area info open dock N Y ship type (short name) 4 To teach details is to bring confusion; to establish the relationship between things is to bring knowledge. M. Montessori
Cer. Exp. (date) Length (m) Draft (m) Capacity (TEU) Cargo (mg/cm2) 0 0 0 0 0 Enter y, n U Ship Clearance  today > today < 260 < 10 < 1000 > today < 260 < 10 1000 > today < 260 [10,12] < 4000  0.75 > today < 260 [10,12] < 4000 > 0.75 > today [260,320) (10,13] < 6000  0.5 > today [260,320) (10,13] < 6000 > 0.5 > today [320,400) 13 > 4000  0.25 > today [320,400) 13 > 4000 > 0.25 n y n y n y n y n 1 2 3 4 5 6 7 8 9 Table 1: DMN representation of the ship clearance decision of Figure 1b Enter Length (m) Cargo (mg/cm2) y,n 0 0 Refuel Area none, indoor, outdoor U Refuel area determination n y  350 y > 350  0.3 y > 350 > 0.3 none indoor indoor outdoor 1 2 3 4 Table 2: DMN representation of the refuel area determination decision of Figure 1b er their corresponding datatypes. In Table 1, the input attributes are: (i) the certificate expira- on date, (ii) the length, (iii) the size, (iv) the capacity, and (v) the amount of cargo residuals of ship. Such attributes are nonnegative real numbers; this is captured by typing them as reals, ding restriction “ 0” as facet. The rightmost, red cell represents the output attribute. In both ses, there is only one output attribute, of type string. The cell below enumerates the possible tput values produced by the decision table, in descending priority order. If a default output is fined, it is underlined. This is the case for the none string in Table 2. Every other row models a rule. The intuitive interpretation of such rules relies on the usual f . ..then ...” pattern. For example, the first rule of Table 1 states that, if the certificate of the ip is expired, then the ship cannot enter the port, that is, the enter output attribute is set to n egardless of the other input attributes). The second rule, instead, states that, if the ship has a lid certificate, a length shorter than 260 m, a draft smaller than 10 m, and a capacity smaller an 1000 TEU, then the ship is allowed to enter the port (regardless of the cargo residuals it rries). Other rules are interpreted similarly. Ship id-code name Certi fi cate exp-date Harbor location Attempt when outcome tried entering into owns 1 0..1 * * receive entrance request record ship info inspect ship ship id acquire certificate record cargo residuals record exp. date cargo residuals certificate exp. date decice clearance enter refuel area enter? send refusal send fuel area info open dock N Y ship type (short name) 5 To teach details is to bring confusion; to establish the relationship between things is to bring knowledge. M. Montessori Our focus: co-evolution of multiple objects
Conventional notations encourage 
 “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. order package process process
Conventional notations encourage 
 “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process
Conventional notations encourage 
 “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process order 1
Conventional notations encourage 
 “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process order 2 order 1
Conventional notations encourage 
 “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process order 1 order 2 package 34
Let’s model a simple process!
Case-Centricity JobOffer
Case-Centricity Hiring Company Business unit Business unit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered JobOffer
Many-to-many Candidate JobOffer 1..* *
Many-to-many Candidate JobOffer 1..* * Hiring Company Business unit Business unit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered Candidate
Many-to-many Candidate JobOffer 1..* * Hiring Company Business unit Business unit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered Candidate ?Granularity issue: some activities refer to Candidate (?), some to JobO ff er (!)
Let’s reify 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner
Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) serialisation
Case-Centricity 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) serialisation •Looping/multi-instance constructs, with multiple pools for the same process 
 (to support concurrency) •Synchronization and communication issues •Loosely-coupled co-evolution of multiple objects 

Not “just” a modeling issue…
50% data models 50% con fi gure/ deploy diagnose/ get reqs. enact/ monitor (re) design adjust IT support reality (knowledge) workers managers/ analysts
50% 50% con fi gure/ deploy diagnose/ get reqs. enact/ monitor (re) design adjust IT support reality (knowledge) workers managers/ analysts data models process mining
Discovery from Event Logs • N Event Log
Discovery from Event Logs • N Event Log One case class Each event refers to one case object
Discovery from Event Logs • N Event Log Discovered Process
Discovery from ERP/CRM/legacy DBs • v ?
Intertwined objects time data activities
Intertwined objects time data activities Order Item Package 1 includes * * is carried in 1 o1 o2 o3 i1,1 i1,2 i2,1 i2,2 i2,3 i3,1 p1 p2 p3 igure 1: Structure of order, item, and package data objects in an order-to-delivery sce- ario whereuv items from di↵erent orders are carried in several packages event log for orders estamp overall log order o1 order o2 order o3 -22 10:00:00 create order o1 create order -22 10:01:00 add item i1,1 to order o1 add item -23 09:20:00 create order o2 create order -23 09:34:00 add item i2,1 to order o2 add item -23 11:33:00 create order o3 create order -23 11:40:00 add item i3,1 to order o3 add item -23 12:27:00 pay order o pay order Have you ever 
 placed orders online?
Flattening reality time data activities Order Item Package 1 includes * * is carried in 1 o1 o2 o3 i1,1 i1,2 i2,1 i2,2 i2,3 i3,1 p1 p2 p3 igure 1: Structure of order, item, and package data objects in an order-to-delivery sce- ario whereuv items from di↵erent orders are carried in several packages event log for orders estamp overall log order o1 order o2 order o3 -22 10:00:00 create order o1 create order -22 10:01:00 add item i1,1 to order o1 add item -23 09:20:00 create order o2 create order -23 09:34:00 add item i2,1 to order o2 add item -23 11:33:00 create order o3 create order -23 11:40:00 add item i3,1 to order o3 add item -23 12:27:00 pay order o pay order focus on orders
Flattening Reality time data activities order o1 order o2 order o3
The effect of fl attening Package is carried in 1 p1 p2 p3 Figure 1: Structure of order, item, and package data objects in an order-to-delivery sce- nario whereuv items from di↵erent orders are carried in several packages event log for orders timestamp overall log order o1 order o2 order o3 2019-09-22 10:00:00 create order o1 create order 2019-09-22 10:01:00 add item i1,1 to order o1 add item 2019-09-23 09:20:00 create order o2 create order 2019-09-23 09:34:00 add item i2,1 to order o2 add item 2019-09-23 11:33:00 create order o3 create order 2019-09-23 11:40:00 add item i3,1 to order o3 add item 2019-09-23 12:27:00 pay order o3 pay order 2019-09-23 12:32:00 add item i1,2 to order o1 add item 2019-09-23 13:03:00 pay order o1 pay order 2019-09-23 14:34:00 load item i1,1 into package p1 load item 2019-09-23 14:45:00 add item i2,2 to order o2 add item 2019-09-23 14:51:00 load item i3,1 into package p1 load item 2019-09-23 15:12:00 add item i2,3 to order o2 add item 2019-09-23 15:41:00 pay order o2 pay order 2019-09-23 16:23:00 load item i2,1 into package p2 load item 2019-09-23 16:29:00 load item i1,2 into package p2 load item 2019-09-23 16:33:00 load item i2,2 into package p2 load item 2019-09-23 17:01:00 send package p1 send package send package 2019-09-24 06:38:00 send package p2 send package send package 2019-09-24 07:33:00 load item i2,3 into package p3 load item 2019-09-24 08:46:00 send package p3 send package 2019-09-24 16:21:00 deliver package p1 deliver package deliver package 2019-09-24 17:32:00 deliver package p2 deliver package deliver package 2019-09-24 18:52:00 deliver package p3 deliver package 2019-09-24 18:57:00 accept delivery p3 accept delivery 2019-09-25 08:30:00 deliver package p1 deliver package deliver package 2019-09-25 08:32:00 accept delivery p1 accept delivery accept delivery 2019-09-25 09:55:00 deliver package p2 deliver package deliver package 2019-09-25 17:11:00 deliver package p2 deliver package deliver package 2019-09-25 17:12:00 accept delivery p2 accept delivery accept delivery
The effect of fl attening Package is carried in 1 p1 p2 p3 Figure 1: Structure of order, item, and package data objects in an order-to-delivery sce- nario whereuv items from di↵erent orders are carried in several packages event log for orders timestamp overall log order o1 order o2 order o3 2019-09-22 10:00:00 create order o1 create order 2019-09-22 10:01:00 add item i1,1 to order o1 add item 2019-09-23 09:20:00 create order o2 create order 2019-09-23 09:34:00 add item i2,1 to order o2 add item 2019-09-23 11:33:00 create order o3 create order 2019-09-23 11:40:00 add item i3,1 to order o3 add item 2019-09-23 12:27:00 pay order o3 pay order 2019-09-23 12:32:00 add item i1,2 to order o1 add item 2019-09-23 13:03:00 pay order o1 pay order 2019-09-23 14:34:00 load item i1,1 into package p1 load item 2019-09-23 14:45:00 add item i2,2 to order o2 add item 2019-09-23 14:51:00 load item i3,1 into package p1 load item 2019-09-23 15:12:00 add item i2,3 to order o2 add item 2019-09-23 15:41:00 pay order o2 pay order 2019-09-23 16:23:00 load item i2,1 into package p2 load item 2019-09-23 16:29:00 load item i1,2 into package p2 load item 2019-09-23 16:33:00 load item i2,2 into package p2 load item 2019-09-23 17:01:00 send package p1 send package send package 2019-09-24 06:38:00 send package p2 send package send package 2019-09-24 07:33:00 load item i2,3 into package p3 load item 2019-09-24 08:46:00 send package p3 send package 2019-09-24 16:21:00 deliver package p1 deliver package deliver package 2019-09-24 17:32:00 deliver package p2 deliver package deliver package 2019-09-24 18:52:00 deliver package p3 deliver package 2019-09-24 18:57:00 accept delivery p3 accept delivery 2019-09-25 08:30:00 deliver package p1 deliver package deliver package 2019-09-25 08:32:00 accept delivery p1 accept delivery accept delivery 2019-09-25 09:55:00 deliver package p2 deliver package deliver package 2019-09-25 17:11:00 deliver package p2 deliver package deliver package 2019-09-25 17:12:00 accept delivery p2 accept delivery accept delivery orders
The effect of fl attening Package is carried in 1 p1 p2 p3 Figure 1: Structure of order, item, and package data objects in an order-to-delivery sce- nario whereuv items from di↵erent orders are carried in several packages event log for orders timestamp overall log order o1 order o2 order o3 2019-09-22 10:00:00 create order o1 create order 2019-09-22 10:01:00 add item i1,1 to order o1 add item 2019-09-23 09:20:00 create order o2 create order 2019-09-23 09:34:00 add item i2,1 to order o2 add item 2019-09-23 11:33:00 create order o3 create order 2019-09-23 11:40:00 add item i3,1 to order o3 add item 2019-09-23 12:27:00 pay order o3 pay order 2019-09-23 12:32:00 add item i1,2 to order o1 add item 2019-09-23 13:03:00 pay order o1 pay order 2019-09-23 14:34:00 load item i1,1 into package p1 load item 2019-09-23 14:45:00 add item i2,2 to order o2 add item 2019-09-23 14:51:00 load item i3,1 into package p1 load item 2019-09-23 15:12:00 add item i2,3 to order o2 add item 2019-09-23 15:41:00 pay order o2 pay order 2019-09-23 16:23:00 load item i2,1 into package p2 load item 2019-09-23 16:29:00 load item i1,2 into package p2 load item 2019-09-23 16:33:00 load item i2,2 into package p2 load item 2019-09-23 17:01:00 send package p1 send package send package 2019-09-24 06:38:00 send package p2 send package send package 2019-09-24 07:33:00 load item i2,3 into package p3 load item 2019-09-24 08:46:00 send package p3 send package 2019-09-24 16:21:00 deliver package p1 deliver package deliver package 2019-09-24 17:32:00 deliver package p2 deliver package deliver package 2019-09-24 18:52:00 deliver package p3 deliver package 2019-09-24 18:57:00 accept delivery p3 accept delivery 2019-09-25 08:30:00 deliver package p1 deliver package deliver package 2019-09-25 08:32:00 accept delivery p1 accept delivery accept delivery 2019-09-25 09:55:00 deliver package p2 deliver package deliver package 2019-09-25 17:11:00 deliver package p2 deliver package deliver package 2019-09-25 17:12:00 accept delivery p2 accept delivery accept delivery orders
Discovery? p1 p2 p3 d package data objects in an order-to-delivery sce- ders are carried in several packages event log for orders order o1 order o2 order o3 create order add item create order add item create order add item pay order add item pay order load item add item load item add item pay order load item load item load item send package send package send package send package load item send package deliver package deliver package deliver package deliver package deliver package accept delivery deliver package deliver package accept delivery accept delivery deliver package deliver package deliver package deliver package accept delivery accept delivery to discover a process model th 3 2 4 2 3 3 1 1 3 3 6 5 3 3 create order 3 add item 6 pay order 3 load item 6 send package 5 deliver package 11 accept delivery 5 raw flat case this trac orde flat dire or t orde Two 1. R o s c r i 2. S a o g s i o d i c a c The cove form pro dire the der mis Thi age
Discovery? p1 p2 p3 d package data objects in an order-to-delivery sce- ders are carried in several packages event log for orders order o1 order o2 order o3 create order add item create order add item create order add item pay order add item pay order load item add item load item add item pay order load item load item load item send package send package send package send package load item send package deliver package deliver package deliver package deliver package deliver package accept delivery deliver package deliver package accept delivery accept delivery deliver package deliver package deliver package deliver package accept delivery accept delivery to discover a process model th 3 2 4 2 3 3 1 1 3 3 6 5 3 3 create order 3 add item 6 pay order 3 load item 6 send package 5 deliver package 11 accept delivery 5 raw flat case this trac orde flat dire or t orde Two 1. R o s c r i 2. S a o g s i o d i c a c The cove form pro dire the der mis Thi age non-existing loop wrong statistics
Do we really need to fl atten reality?
Declarative style: fi rst-order temporal logics • OCBC [___,BPM2019] Imperative style data-aware Petri nets • Proclets [Fahland,PN2019] • ISML [Polyvyanyy&van der Werf, CAiSE2019] • catalog-nets [___,BPM2020]
time data activities
time Object-Centric Behavioral Constraints activities data
time Object-Centric Behavioral Constraints activities data data model
time Object-Centric Behavioral Constraints activities data data model activities 
 refer to classes
time Object-Centric Behavioral Constraints activities data data model activities 
 refer to classes temporal constraints co-refer 
 via data model
data model (UML class diagram) Activities refer to classes C1 C2 R
data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C
data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3
data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3 “generating”
Hiring Example 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner which instances of tasks are related by the constraint depending on manipulate. In particular, the relevant constraints for our job hiring example are: C.1 The register data task is about a Person. C.2 A Job Offer is created by executing the post offer task. C.3 A Job Offer is closed by determining the winner. C.4 A Job Offer is stopped by canceling the hiring. Enriching Data Models with Behavioral Co C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data a date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least o responding to that Job Offer has been previously marked as el C.9 For each Application responding to a Job Offer, if the Applica as eligible then a winner must be finally determined for that this is done only once for that Job Offer. C.10 When a winner is determined for a Job Offer, Applications res
Hiring Example 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner which instances of tasks are related by the constraint depending on manipulate. In particular, the relevant constraints for our job hiring example are: C.1 The register data task is about a Person. C.2 A Job Offer is created by executing the post offer task. C.3 A Job Offer is closed by determining the winner. C.4 A Job Offer is stopped by canceling the hiring. Enriching Data Models with Behavioral Co C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data a date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least o responding to that Job Offer has been previously marked as el C.9 For each Application responding to a Job Offer, if the Applica as eligible then a winner must be finally determined for that this is done only once for that Job Offer. C.10 When a winner is determined for a Job Offer, Applications res
Emergent artifact lifecycle 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner
Emergent artifact lifecycle 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner “Application” “Job O ff er” many one
Expressing the process 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations
Expressing the process 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints
Temporal constraints 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. Inspired by the Declare declarative process modeling notation
Is that enough? No! 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints
Is that enough? No! 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints co-reference on object (V co-reference) co-reference on relation (U co-reference)
V coreference on response 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship Every time an instance a of A is executed on some object o of type O (i.e., with R1(a,o)) then an instance b of B must be executed afterwards on the same object o (i.e., with R2(b,o)) t
V coreference on response 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship Every time an instance a of A is executed on some object o of type O (i.e., with R1(a,o)) then an instance b of B must be executed afterwards on the same object o (i.e., with R2(b,o)) t o:O a:A R1 If then b:B R2
U coreference on response t A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then no instance a2 of A2 that relates to the same object o (i.e., with R2(a2, o)) can be executed afterwards (c) Co-reference of non-response over an object class 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). Every time an instance a of A is executed on some object o1 of type O (i.e., with R1(a,o1)) then an instance b of B must be executed afterwards on some object o2 of type O2 (i.e., with R2(b,o2)) that relates to o1 via R 
 (with R(o1,o2) contextually with the execution of b) 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship
U coreference on response A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then no instance a2 of A2 that relates to the same object o (i.e., with R2(a2, o)) can be executed afterwards (c) Co-reference of non-response over an object class 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). Every time an instance a of A is executed on some object o1 of type O (i.e., with R1(a,o1)) then an instance b of B must be executed afterwards on some object o2 of type O2 (i.e., with R2(b,o2)) that relates to o1 via R 
 (with R(o1,o2) contextually with the execution of b) t o1:O a:A R1 If then b:B R2 o2:O R 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship
Hiring Constraints C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations Enriching Data Models with Behavioral Constraints 13 is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner c c
Further Hiring Constraints Enriching Data Models with Behavioral Constraints 13 is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 5 An Application is created by executing the submit task. 6 An Application is promoted by marking it as eligible. 7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. 8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. 9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. 0 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. 1 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2 Capturing the Job Hiring Example with Case-Centric Notations he most fundamental issue when trying to capture the job hiring example of Section 2.1 sing case-centric notation is to identify what is the case. This, in turn, determines hat is the orchestration point for the process, that is, which participant coordinates rocess instances corresponding to different case objects. This problem is apparent when ooking at BPMN, which specifies that each process should correspond to a single locus 4
Key questions 1. What is the semantics of these models? 2. Can we do automated reasoning?
 Consistency, dead activities, implied constraints…
 Also relevant for process discovery: inferring single constraints with tolerance on the support may jeopardise model correctness!
Temporal Description Logics Family of KR logical formalisms to represent and reason about static, structural knowledge. Provide foundations to: • data models; • ontologies and semantic web. We focus on ALCQI: • captures (wide fragments of) UML class diagrams, E-R, ORM.
Temporal Description Logics OBDA for Log Extraction in Process Mining 25 Paper title : String type : String Person pName : String regTime: ts Assignment invTime: ts Submission uploadTime: ts CRUpload Creation DecidedPaper decTime: ts accepted: boolean notifiedBy Review subTime: ts leadsTo Conference cName: String crTime: ts submittedTo chairs * * * 1..* * 1 1 0..1 * 1 1 * Fig. 9: Data model of our CONFSYS running example Correctness of the Encoding. The encoding we have provided is faithful, in the sense that it fully preserves in the DL-LiteA ontology the semantics of the UML class diagram. Obviously, since, due to reification, the ontology alphabet may contain additional sym- bols with respect to those used in the UML class diagram, the two specifications cannot have the same logical models. However, it is possible to show that the logical models of a UML class diagram and those of the DL-LiteA ontology derived from it correspond to each other, and hence that satisfiability of a class or association in the UML diagram corresponds to satisfiability of the corresponding concept or role [29,7]. Example 9. We illustrate the encoding of UML class diagrams in DL-LiteA on the UML class diagram shown in Figure 9, which depicts (a simplified version of) the in- formation model of the CONFSYS conference submission system used for our running example. We assume that the components of associations are given from left to right and from top to bottom. Papers are represented through the Paper class, with attributes A L C Q I
Temporal Description Logics (title) ⌘ Paper ⇢(title) v string (funct title) (type) ⌘ Paper ⇢(type) v string (funct type) (decTime) ⌘ DecidedPaper ⇢(decTime) v ts (funct decTime) (accepted) ⌘ DecidedPaper ⇢(accepted) v boolean (funct accepted) (pName) ⌘ Person ⇢(pName) v string (funct pName) (regTime) ⌘ Person ⇢(regTime) v ts (funct regTime) (cName) ⌘ Conference ⇢(cName) v string (funct cName) (crTime) ⌘ Conference ⇢(crTime) v ts (funct crTime) (uploadTime) ⌘ Submission ⇢(uploadTime) v ts (funct uploadTime) (invTime) ⌘ Assignment ⇢(invTime) v ts (funct invTime) (subTime) ⌘ Review ⇢(subTime) v ts (funct subTime) DecidedPaper v Paper Creation v Submission CRUpload v Submission 9Submission1 ⌘ Submission 9Submission1 ⌘ Paper (funct Submission1) 9Submission2 ⌘ Submission 9Submission2 v Person (funct Submission2) 9Assignment1 ⌘ Assignment 9Assignment1 v Paper (funct Assignment1) 9Assignment2 ⌘ Assignment 9Assignment2 v Person (funct Assignment2) 9leadsTo v Assignment 9leadsTo ⌘ Review (funct leadsTo) (funct leadsTo ) 9submittedTo ⌘ Paper 9submittedTo v Conference (funct submittedTo) 9notifiedBy ⌘ DecidedPaper 9notifiedBy v Person (funct notifiedBy) 9chairs v Person 9chairs ⌘ Conference (funct chairs ) OBDA for Log Extraction in Process Mining 25 Paper title : String type : String Person pName : String regTime: ts Assignment invTime: ts Submission uploadTime: ts CRUpload Creation DecidedPaper decTime: ts accepted: boolean notifiedBy Review subTime: ts leadsTo Conference cName: String crTime: ts submittedTo chairs * * * 1..* * 1 1 0..1 * 1 1 * Fig. 9: Data model of our CONFSYS running example Correctness of the Encoding. The encoding we have provided is faithful, in the sense that it fully preserves in the DL-LiteA ontology the semantics of the UML class diagram. Obviously, since, due to reification, the ontology alphabet may contain additional sym- bols with respect to those used in the UML class diagram, the two specifications cannot have the same logical models. However, it is possible to show that the logical models of a UML class diagram and those of the DL-LiteA ontology derived from it correspond to each other, and hence that satisfiability of a class or association in the UML diagram corresponds to satisfiability of the corresponding concept or role [29,7]. Example 9. We illustrate the encoding of UML class diagrams in DL-LiteA on the UML class diagram shown in Figure 9, which depicts (a simplified version of) the in- formation model of the CONFSYS conference submission system used for our running example. We assume that the components of associations are given from left to right and from top to bottom. Papers are represented through the Paper class, with attributes A L C Q I
Temporal Description Logics Family of KR logical formalisms to represent and reason about time. We focus on LTL: • models: execution traces (over tasks only); • (in its fi nite-trace version) at the basis of the Declare modelling language.
8 A. Artale, D. Calvanese, M. Montali, and W. van A B response A unary-respons A B precedence A unary-preceden A B responded-existence Fig. 3: Types of temporal constraints response(A, B) If A is executed, then B unary- response(A, B) If A is executed, then B Calvanese, M. Montali, and W. van der Aalst B A B unary-response A B non-response B A B unary-precedence A B non-precedence B tence A B non-coexistence 3: Types of temporal constraints between activities If A is executed, then B must be executed afterwards. B) If A is executed, then B must be executed exactly once after- 8 A. Artale, D. Calvanese, M. Montali, and W. van A B response A unary-respons A B precedence A unary-preceden A B responded-existence Fig. 3: Types of temporal constraints response(A, B) If A is executed, then B L T L Temporal Description Logics
8 A. Artale, D. Calvanese, M. Montali, and W. van A B response A unary-respons A B precedence A unary-preceden A B responded-existence Fig. 3: Types of temporal constraints response(A, B) If A is executed, then B unary- response(A, B) If A is executed, then B Calvanese, M. Montali, and W. van der Aalst B A B unary-response A B non-response B A B unary-precedence A B non-precedence B tence A B non-coexistence 3: Types of temporal constraints between activities If A is executed, then B must be executed afterwards. B) If A is executed, then B must be executed exactly once after- 8 A. Artale, D. Calvanese, M. Montali, and W. van A B response A unary-respons A B precedence A unary-preceden A B responded-existence Fig. 3: Types of temporal constraints response(A, B) If A is executed, then B L T L Temporal Description Logics 2(A ! 3F B) 2(A ! 3PB) 2(A ! 2 ⇤ ¬B) ns available to model business processes, ife processes using mainstream notations
Temporal Description Logics Combine static and dynamic aspects into a unique logical framework. The right framework to capture OCBC. • Model: global event log with intertwined objects.
 1-to-1 correspondence with data-aware logs o1 : Order ol1 : Order Line ol2 : Order Line ol3 : Order Line d1 : Delivery d2 : Delivery ... ... ... ... ... ... co1 : Create Order pi1 : Pick Item pi2 : Pick Item wi1 : Wrap Item wi2 : Wrap Item pi3 : Pick Item wi3 : Wrap Item po1 : Pay Order di1 : Deliver Items di2 : Deliver Items t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 creates fills contains fills contains prepares prepares fills contains prepares closes refers to results in results in refers to results in
Combining multiple dimensions is dangerous: undecidability around the corner! Can we formalize OCBC in a well-behaved temporal DL?
Idea time data activities T u s A L C Q I
Idea time activities data T u s A L C Q I T u s A L C Q I
Which Route? A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex
Which Route? A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Chaining relations across time Flow object
Which Route? A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Chaining relations across time Flow object
Question A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Do we need to global constraints on activities, without co-referencing in the data model? No: everything scoped by data objects!
Activities Fade Away A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Do we need to global constraints on activities, without co-referencing in the data model? The temporal DL su ffi ces!
 [Combines with LTL over concepts only] No: everything scoped by data objects! Temporal constraint over O1 and O2 no order line of an order can be wrapped after ify that the former constraint is indeed implied, ot. While it is true that once an order is paid or it, already picked order lines may still need . This amounts to check whether a trace frag- n M. Since ρ is a trace fragment, we require ained in ρ and that ρ can be’completed’ into a satisfies M. This corresponds to the notion of ntroduced in [15]. In our setting, this amounts coding ρ is satisfiable w.r.t. the TBox TM, i.e., ble. Notice that, KB satisfiability and logical impli- n ALCQI [6] (and thus in TUSALCQI) and SALCQI are ExpTime-complete [18,27], which an be paid only if it has been an order can be wrapped after mer constraint is indeed implied, true that once an order is paid cked order lines may still need to check whether a trace frag- s a trace fragment, we require hat ρ can be’completed’ into a is corresponds to the notion of 5]. In our setting, this amounts sfiable w.r.t. the TBox TM, i.e., satisfiability and logical impli- and thus in TUSALCQI) and
Response Example Every time an instance a of A is executed on some object o1 of type O (i.e., with R1(a,o1)) then an instance b of B must be executed afterwards on some object o2 (i.e., with R2(b,o2)) that relates to o1 via R 
 (with R(o1,o2) contextually with the execution of b) 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then no instance a2 of A2 that relates to the same object o (i.e., with R2(a2, o)) can be executed afterwards 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once
Response Example 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then no instance a2 of A2 that relates to the same object o (i.e., with R2(a2, o)) can be executed afterwards 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once Every time an instance a of A is executed on some object o1 of type O (i.e., with R1(a,o1)) then an instance b of B must be executed afterwards on some object o2 (i.e., with R2(b,o2)) that relates to o1 via R 
 (with R(o1,o2) contextually with the execution of b) Every time some object o1 of type O1 is subject to some instance of A (i.e., is target of R1) then afterwards some object o2 of type O2 must relate to o1 via R and be subject to some instance of B (i.e., be target of R2) o1:O … some A R1 If then o2:O R R2 … some B
A glimpse of the formalization 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship t o:O a:A R1 If then according to Definition 3, can be either ge either over object classes (as illustrated ips (as illustrated in Fig. 5b and d). Let d O ∈ UC s.t. tc(A1, A2) ∈ Σ+ T C, τRAC O) and cref be a co-reference constraint o c(A1, A2), R1, R2) = O (as in Fig. 5a). Then n tc is the response temporal constraint i ∃R− 1 ! ♦F ∃R− 2 t “whenever an object is in the range of b:B R2
b’:B R2 A glimpse of the formalization o:O a:A R1 If then b:B R2 according to Definition 3, can be either ge either over object classes (as illustrated ips (as illustrated in Fig. 5b and d). Let d O ∈ UC s.t. tc(A1, A2) ∈ Σ+ T C, τRAC O) and cref be a co-reference constraint o c(A1, A2), R1, R2) = O (as in Fig. 5a). Then n tc is the response temporal constraint i ∃R− 1 ! ♦F ∃R− 2 t “whenever an object is in the range of 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship t ver the activities via the co-referenced obj ed via R1 to an object in O then it must b erencing the same object via R2. Formally ds: (2), A1 ! ∃R1} |= A1 ! ∃R1. ♦F ∃R− 2 . A2 y-response temporal constraint we need t mula that guarantees a unique occurrence o ∃R− 2 " ♦P ∃R− 1 ! "F ¬∃R− 2
A glimpse of the formalization t o:O a:A R1 If then A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then no instance a2 of A2 that relates to the same object o (i.e., with R2(a2, o)) can be executed afterwards (c) Co-reference of non-response over an object class 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship b:B R2 R ∃R− 2 # ♦F ∃R− 1 " "P ¬∃R− 2 ∃R− 1 " ♦ ∗ ∃R− 2 sider co-reference constraints over relationships. A ∈ UR, with τ(R) = (O1, O2), τRAC (R1) = (A1, O ef be a co-reference of the form: cref(tc(A1, A2 ntics of co-reference over relationships when tc i ptured by: ∃R− 1 " ♦F ∃R. ∃R− 2 “every object in the range of R1 sometime in th
Key reasoning tasks Consistency: does the OCBC model admit at least one conforming event log? Dead activity detection: is it possible to imagine a log containing the execution of the activity of interest? Hidden dependencies: is a constraint implied by the model? Conditional conformance: does a given log satisfy the OCBC model, possibly introducing missing events/data?
Implied Constraints 
 (Hidden Dependencies) Enriching Data Models with Behavioral Constraints 13 is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 An Application is promoted by marking it as eligible. 7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. 8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. 9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. 0 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. 1 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). .2 Capturing the Job Hiring Example with Case-Centric Notations he most fundamental issue when trying to capture the job hiring example of Section 2.1 sing case-centric notation is to identify what is the case. This, in turn, determines hat is the orchestration point for the process, that is, which participant coordinates rocess instances corresponding to different case objects. This problem is apparent when ooking at BPMN, which specifies that each process should correspond to a single locus f control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- ging Applications), and the job hiring organisation (in turn responsible for the The OCBC model implies:
Complexity considerations Consistency, dead activity detection, checking implied constraints, conditional conformance can all be reduced to standard reasoning in • ExpTime upper bound If we only adopt V-coreference on classes, and do not consider covering on UML hierarchies: • The logic su ffi ces • Complexity drops to PSPACE 
 (same as plain old LTL) tained in ρ and that ρ can be’completed’ into a at satisfies M. This corresponds to the notion of introduced in [15]. In our setting, this amounts encoding ρ is satisfiable w.r.t. the TBox TM, i.e., able. . Notice that, KB satisfiability and logical impli- in ALCQI [6] (and thus in TUSALCQI) and USALCQI are ExpTime-complete [18,27], which bound for verifying properties of OCBC models. e base DL is due to co-reference constraints over he power of qualified existential (∃R. C) and its raints (i.e., only consider OCBC constraints co- use a temporalized version of a DL-Lite dialect. L-Lite fragment TUSDL-Lite (HN ) bool , showed to be to capture OCBC models with the exception of ationships while, at the level of the data model, main constructs of UML—with the exception of ation is contained in ρ and that ρ can be’completed’ int te trace that satisfies M. This corresponds to the notion nce recently introduced in [15]. In our setting, this amou e ABox Aρ encoding ρ is satisfiable w.r.t. the TBox TM, i M,ρ is satisfiable. derations. Notice that, KB satisfiability and logical im reducible in ALCQI [6] (and thus in TUSALCQI) a lems over TUSALCQI are ExpTime-complete [18,27], wh ime upper bound for verifying properties of OCBC mod CQI as the base DL is due to co-reference constraints o requires the power of qualified existential (∃R. C) and such constraints (i.e., only consider OCBC constraints , we could use a temporalized version of a DL-Lite diale emporal DL-Lite fragment TUSDL-Lite (HN ) bool , showed to [8], is able to capture OCBC models with the exception
Conclusion OCBC: a declarative approach
 to elegantly capture processes
 with co-evolving objects Formal logic-based semantics in a temporal DL that enables automated reasoning
Rigid roles? Monitoring
 (closed-open reasoning) Discovery of OCBC fragments 
 and other (imperative) models with data correlations
 Baseline: [Li et al,BIS2017], [Berti&vanderAalst,Arxiv2020],
 [Lu et al, IEEETSC2015] Future work

More Related Content

PDF
From Case-Isolated to Object-Centric Processes - A Tale of two Models
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
From Case-Isolated to Object-Centric Processes
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
M Bridge 12 An Algorithm to Reduce Container Reposition Cost through Virtual.pdf
CINEC Campus
 
PDF
M Bridge 6 CASA 2019 July - An Algorithm to Reduces Container Reposition Cost...
CINEC Campus
 
PDF
Processes and organizations - a look behind the paper wall
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PPTX
Transportation, Transshipment and Assignment Problem.pptx
KiranMittal7
 
DOCX
Report Normalization documents
Wakil Kumar
 
PDF
Semantic DMN: Formalizing Decision Models with Domain Knowledge
Marlon Dumas
 
From Case-Isolated to Object-Centric Processes - A Tale of two Models
Faculty of Computer Science - Free University of Bozen-Bolzano
 
From Case-Isolated to Object-Centric Processes
Faculty of Computer Science - Free University of Bozen-Bolzano
 
M Bridge 12 An Algorithm to Reduce Container Reposition Cost through Virtual.pdf
CINEC Campus
 
M Bridge 6 CASA 2019 July - An Algorithm to Reduces Container Reposition Cost...
CINEC Campus
 
Processes and organizations - a look behind the paper wall
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Transportation, Transshipment and Assignment Problem.pptx
KiranMittal7
 
Report Normalization documents
Wakil Kumar
 
Semantic DMN: Formalizing Decision Models with Domain Knowledge
Marlon Dumas
 

Similar to Modeling and Reasoning over Declarative Data-Aware Processes (17)

PDF
Semantic DMN: Formalizing Decision Models with Domain Knowledge
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PPT
Assign transportation
Kinshook Chaturvedi
 
PDF
Business Model That Presents ( Operation Process...
Carmen Martin
 
PDF
Swot Analysis Of Swissair
Veronica Smith
 
PPT
SCM: Fedex
Amit Kumar
 
PDF
Container Market Literature Review
Mary Stevenson
 
PDF
Edgar Allan Poe Thesis Statement Essay
Molly Wood
 
PDF
Crossdocking Insights from a Third Party Logistics Firm in Turkey
ertekg
 
PDF
Strategy Synthesis for Data-Aware Dynamic Systems with Multiple Actors
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Academic Summary Example. A Summary Of A
Alison Carias
 
PDF
Crossdocking Insights from a Third Party Logistics Firm in Turkey
Gurdal Ertek
 
PDF
Nt1320 Unit 4
Nicolle Dammann
 
DOCX
CS844 U4 Individual Project
ThienSi Le
 
PDF
Damien lamberton, bernard lapeyre, nicolas rabeau
Bliyaminou Mamane Issa
 
PPTX
4 Tranportation Proplem Final 1 special notes
aloksinghtanwar7720
 
DOCX
Script for presentation 54030072
Yuyie Pharita
 
PPTX
LP network chapter 5 transportation and assignment problem
Harun Al-Rasyid Lubis
 
Semantic DMN: Formalizing Decision Models with Domain Knowledge
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Assign transportation
Kinshook Chaturvedi
 
Business Model That Presents ( Operation Process...
Carmen Martin
 
Swot Analysis Of Swissair
Veronica Smith
 
SCM: Fedex
Amit Kumar
 
Container Market Literature Review
Mary Stevenson
 
Edgar Allan Poe Thesis Statement Essay
Molly Wood
 
Crossdocking Insights from a Third Party Logistics Firm in Turkey
ertekg
 
Strategy Synthesis for Data-Aware Dynamic Systems with Multiple Actors
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Academic Summary Example. A Summary Of A
Alison Carias
 
Crossdocking Insights from a Third Party Logistics Firm in Turkey
Gurdal Ertek
 
Nt1320 Unit 4
Nicolle Dammann
 
CS844 U4 Individual Project
ThienSi Le
 
Damien lamberton, bernard lapeyre, nicolas rabeau
Bliyaminou Mamane Issa
 
4 Tranportation Proplem Final 1 special notes
aloksinghtanwar7720
 
Script for presentation 54030072
Yuyie Pharita
 
LP network chapter 5 transportation and assignment problem
Harun Al-Rasyid Lubis
 
Ad

More from Faculty of Computer Science - Free University of Bozen-Bolzano (20)

PDF
Reasoning on Labelled Petri Nets and Their Dynamics in a Stochastic Setting
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Constraints for Process Framing in Augmented BPM
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Intelligent Systems for Process Mining
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Declarative process mining
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Process Reasoning and Mining with Uncertainty
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Soundness of Data-Aware Processes with Arithmetic Conditions
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Probabilistic Trace Alignment
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Extending Temporal Business Constraints with Uncertainty
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Extending Temporal Business Constraints with Uncertainty
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Modeling and Reasoning over Declarative Data-Aware Processes with Object-Cent...
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
From legacy data to event data
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Putting Decisions in Perspective(s)
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Enriching Data Models with Behavioral Constraints
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Representing and querying norm states using temporal ontology-based data access
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Compliance monitoring of multi-perspective declarative process models
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Formal modeling and SMT-based parameterized verification of Data-Aware BPMN
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Modeling and reasoning over declarative data-aware processes with object-cent...
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Putting decisions in perspective(s)
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
How to Present Scientific Work
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Cooking with Data and Processes
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Reasoning on Labelled Petri Nets and Their Dynamics in a Stochastic Setting
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Constraints for Process Framing in Augmented BPM
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Intelligent Systems for Process Mining
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Declarative process mining
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Process Reasoning and Mining with Uncertainty
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Soundness of Data-Aware Processes with Arithmetic Conditions
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Probabilistic Trace Alignment
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Extending Temporal Business Constraints with Uncertainty
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Extending Temporal Business Constraints with Uncertainty
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Modeling and Reasoning over Declarative Data-Aware Processes with Object-Cent...
Faculty of Computer Science - Free University of Bozen-Bolzano
 
From legacy data to event data
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Putting Decisions in Perspective(s)
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Enriching Data Models with Behavioral Constraints
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Representing and querying norm states using temporal ontology-based data access
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Compliance monitoring of multi-perspective declarative process models
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Formal modeling and SMT-based parameterized verification of Data-Aware BPMN
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Modeling and reasoning over declarative data-aware processes with object-cent...
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Putting decisions in perspective(s)
Faculty of Computer Science - Free University of Bozen-Bolzano
 
How to Present Scientific Work
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Cooking with Data and Processes
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Ad

Recently uploaded (20)

PPTX
TOTAL hIP ARTHROPLASTY Presentation.pptx
hararghemssc
 
PDF
Unveiling a 36 billion solar mass black hole at the centre of the Cosmic Hors...
Sérgio Sacani
 
PPTX
Classification Systems_TAXONOMY_SCIENCE8.pptx
glofernignacio
 
PDF
Phytochemical Investigation of Miliusa longipes.pdf
IrfanShahirSharafi
 
PDF
Biophysics 2.pdffffffffffffffffffffffffff
MiraMusleh
 
PPTX
DRUG THERAPY FOR SHOCK gjjjgfhhhhh.pptx.
vipvivek704
 
PDF
VARICELLA VACCINATION: A POTENTIAL STRATEGY FOR PREVENTING MULTIPLE SCLEROSIS
ijab2
 
PDF
SEHH2274 Organic Chemistry Notes 1 Structure and Bonding.pdf
ivan1108lau
 
PDF
bbec55_b34400a7914c42429908233dbd381773.pdf
agambirev
 
PPTX
2Systematics of Living Organisms t-.pptx
RachanaT6
 
PDF
Formation of Supersonic Turbulence in the Primordial Star-forming Cloud
Sérgio Sacani
 
PPT
POSITIONING IN OPERATION THEATRE ROOM.ppt
PrabakaranMP1
 
PPTX
7. General Toxicologyfor clinical phrmacy.pptx
faysalphr
 
PDF
. Radiology Case Scenariosssssssssssssss
MiraMusleh
 
PDF
HPLC-PPT.docx high performance liquid chromatography
darshanambiga1633
 
PPTX
Introduction to Fisheries Biotechnology_Lesson 1.pptx
Esther Pongcol
 
PPTX
The KM-GBF monitoring framework – status & key messages.pptx
pensoftservices
 
PPTX
Comparative Structure of Integument in Vertebrates.pptx
Dr Showkat Ahmad Wani
 
PDF
CAPERS-LRD-z9:AGas-enshroudedLittleRedDotHostingaBroad-lineActive GalacticNuc...
Sérgio Sacani
 
PPT
The World of Physical Science, • Labs: Safety Simulation, Measurement Practice
joybejerano
 
TOTAL hIP ARTHROPLASTY Presentation.pptx
hararghemssc
 
Unveiling a 36 billion solar mass black hole at the centre of the Cosmic Hors...
Sérgio Sacani
 
Classification Systems_TAXONOMY_SCIENCE8.pptx
glofernignacio
 
Phytochemical Investigation of Miliusa longipes.pdf
IrfanShahirSharafi
 
Biophysics 2.pdffffffffffffffffffffffffff
MiraMusleh
 
DRUG THERAPY FOR SHOCK gjjjgfhhhhh.pptx.
vipvivek704
 
VARICELLA VACCINATION: A POTENTIAL STRATEGY FOR PREVENTING MULTIPLE SCLEROSIS
ijab2
 
SEHH2274 Organic Chemistry Notes 1 Structure and Bonding.pdf
ivan1108lau
 
bbec55_b34400a7914c42429908233dbd381773.pdf
agambirev
 
2Systematics of Living Organisms t-.pptx
RachanaT6
 
Formation of Supersonic Turbulence in the Primordial Star-forming Cloud
Sérgio Sacani
 
POSITIONING IN OPERATION THEATRE ROOM.ppt
PrabakaranMP1
 
7. General Toxicologyfor clinical phrmacy.pptx
faysalphr
 
. Radiology Case Scenariosssssssssssssss
MiraMusleh
 
HPLC-PPT.docx high performance liquid chromatography
darshanambiga1633
 
Introduction to Fisheries Biotechnology_Lesson 1.pptx
Esther Pongcol
 
The KM-GBF monitoring framework – status & key messages.pptx
pensoftservices
 
Comparative Structure of Integument in Vertebrates.pptx
Dr Showkat Ahmad Wani
 
CAPERS-LRD-z9:AGas-enshroudedLittleRedDotHostingaBroad-lineActive GalacticNuc...
Sérgio Sacani
 
The World of Physical Science, • Labs: Safety Simulation, Measurement Practice
joybejerano
 

Modeling and Reasoning over Declarative Data-Aware Processes

  • 1. Modeling and Reasoning over declarative data-aware processes Marco Montali montali@inf.unibz.it KRDB SOS, 22/05/2020 joint work with Wil van der Aalst, Alessandro Artale, Alisa Kovtunova
  • 3. Data and processes A challenging, but necessary marriage! Typical choice: divide and conquer, 
 separating structural and dynamic aspects
  • 4. Cer. Exp. (date) Length (m) Draft (m) Capacity (TEU) Cargo (mg/cm2) 0 0 0 0 0 Enter y, n U Ship Clearance  today > today < 260 < 10 < 1000 > today < 260 < 10 1000 > today < 260 [10,12] < 4000  0.75 > today < 260 [10,12] < 4000 > 0.75 > today [260,320) (10,13] < 6000  0.5 > today [260,320) (10,13] < 6000 > 0.5 > today [320,400) 13 > 4000  0.25 > today [320,400) 13 > 4000 > 0.25 n y n y n y n y n 1 2 3 4 5 6 7 8 9 Table 1: DMN representation of the ship clearance decision of Figure 1b Enter Length (m) Cargo (mg/cm2) y,n 0 0 Refuel Area none, indoor, outdoor U Refuel area determination n y  350 y > 350  0.3 y > 350 > 0.3 none indoor indoor outdoor 1 2 3 4 Table 2: DMN representation of the refuel area determination decision of Figure 1b er their corresponding datatypes. In Table 1, the input attributes are: (i) the certificate expira- on date, (ii) the length, (iii) the size, (iv) the capacity, and (v) the amount of cargo residuals of ship. Such attributes are nonnegative real numbers; this is captured by typing them as reals, ding restriction “ 0” as facet. The rightmost, red cell represents the output attribute. In both ses, there is only one output attribute, of type string. The cell below enumerates the possible tput values produced by the decision table, in descending priority order. If a default output is fined, it is underlined. This is the case for the none string in Table 2. Every other row models a rule. The intuitive interpretation of such rules relies on the usual f . ..then ...” pattern. For example, the first rule of Table 1 states that, if the certificate of the ip is expired, then the ship cannot enter the port, that is, the enter output attribute is set to n egardless of the other input attributes). The second rule, instead, states that, if the ship has a lid certificate, a length shorter than 260 m, a draft smaller than 10 m, and a capacity smaller an 1000 TEU, then the ship is allowed to enter the port (regardless of the cargo residuals it rries). Other rules are interpreted similarly. Ship id-code name Certi fi cate exp-date Harbor location Attempt when outcome tried entering into owns 1 0..1 * * receive entrance request record ship info inspect ship ship id acquire certificate record cargo residuals record exp. date cargo residuals certificate exp. date decice clearance enter refuel area enter? send refusal send fuel area info open dock N Y ship type (short name) 4 To teach details is to bring confusion; to establish the relationship between things is to bring knowledge. M. Montessori
  • 5. Cer. Exp. (date) Length (m) Draft (m) Capacity (TEU) Cargo (mg/cm2) 0 0 0 0 0 Enter y, n U Ship Clearance  today > today < 260 < 10 < 1000 > today < 260 < 10 1000 > today < 260 [10,12] < 4000  0.75 > today < 260 [10,12] < 4000 > 0.75 > today [260,320) (10,13] < 6000  0.5 > today [260,320) (10,13] < 6000 > 0.5 > today [320,400) 13 > 4000  0.25 > today [320,400) 13 > 4000 > 0.25 n y n y n y n y n 1 2 3 4 5 6 7 8 9 Table 1: DMN representation of the ship clearance decision of Figure 1b Enter Length (m) Cargo (mg/cm2) y,n 0 0 Refuel Area none, indoor, outdoor U Refuel area determination n y  350 y > 350  0.3 y > 350 > 0.3 none indoor indoor outdoor 1 2 3 4 Table 2: DMN representation of the refuel area determination decision of Figure 1b er their corresponding datatypes. In Table 1, the input attributes are: (i) the certificate expira- on date, (ii) the length, (iii) the size, (iv) the capacity, and (v) the amount of cargo residuals of ship. Such attributes are nonnegative real numbers; this is captured by typing them as reals, ding restriction “ 0” as facet. The rightmost, red cell represents the output attribute. In both ses, there is only one output attribute, of type string. The cell below enumerates the possible tput values produced by the decision table, in descending priority order. If a default output is fined, it is underlined. This is the case for the none string in Table 2. Every other row models a rule. The intuitive interpretation of such rules relies on the usual f . ..then ...” pattern. For example, the first rule of Table 1 states that, if the certificate of the ip is expired, then the ship cannot enter the port, that is, the enter output attribute is set to n egardless of the other input attributes). The second rule, instead, states that, if the ship has a lid certificate, a length shorter than 260 m, a draft smaller than 10 m, and a capacity smaller an 1000 TEU, then the ship is allowed to enter the port (regardless of the cargo residuals it rries). Other rules are interpreted similarly. Ship id-code name Certi fi cate exp-date Harbor location Attempt when outcome tried entering into owns 1 0..1 * * receive entrance request record ship info inspect ship ship id acquire certificate record cargo residuals record exp. date cargo residuals certificate exp. date decice clearance enter refuel area enter? send refusal send fuel area info open dock N Y ship type (short name) 5 To teach details is to bring confusion; to establish the relationship between things is to bring knowledge. M. Montessori Our focus: co-evolution of multiple objects
  • 6. Conventional notations encourage 
 “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. order package process process
  • 7. Conventional notations encourage 
 “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process
  • 8. Conventional notations encourage 
 “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process order 1
  • 9. Conventional notations encourage 
 “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process order 2 order 1
  • 10. Conventional notations encourage 
 “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process order 1 order 2 package 34
  • 11. Let’s model a simple process!
  • 13. Case-Centricity Hiring Company Business unit Business unit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered JobOffer
  • 15. Many-to-many Candidate JobOffer 1..* * Hiring Company Business unit Business unit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered Candidate
  • 16. Many-to-many Candidate JobOffer 1..* * Hiring Company Business unit Business unit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered Candidate ?Granularity issue: some activities refer to Candidate (?), some to JobO ff er (!)
  • 17. Let’s reify 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner
  • 18. Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 19. Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 20. Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 21. Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 22. Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) serialisation
  • 23. Case-Centricity 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) serialisation •Looping/multi-instance constructs, with multiple pools for the same process 
 (to support concurrency) •Synchronization and communication issues •Loosely-coupled co-evolution of multiple objects 

  • 26. 50% 50% con fi gure/ deploy diagnose/ get reqs. enact/ monitor (re) design adjust IT support reality (knowledge) workers managers/ analysts data models process mining
  • 27. Discovery from Event Logs • N Event Log
  • 28. Discovery from Event Logs • N Event Log One case class Each event refers to one case object
  • 29. Discovery from Event Logs • N Event Log Discovered Process
  • 32. Intertwined objects time data activities Order Item Package 1 includes * * is carried in 1 o1 o2 o3 i1,1 i1,2 i2,1 i2,2 i2,3 i3,1 p1 p2 p3 igure 1: Structure of order, item, and package data objects in an order-to-delivery sce- ario whereuv items from di↵erent orders are carried in several packages event log for orders estamp overall log order o1 order o2 order o3 -22 10:00:00 create order o1 create order -22 10:01:00 add item i1,1 to order o1 add item -23 09:20:00 create order o2 create order -23 09:34:00 add item i2,1 to order o2 add item -23 11:33:00 create order o3 create order -23 11:40:00 add item i3,1 to order o3 add item -23 12:27:00 pay order o pay order Have you ever 
 placed orders online?
  • 33. Flattening reality time data activities Order Item Package 1 includes * * is carried in 1 o1 o2 o3 i1,1 i1,2 i2,1 i2,2 i2,3 i3,1 p1 p2 p3 igure 1: Structure of order, item, and package data objects in an order-to-delivery sce- ario whereuv items from di↵erent orders are carried in several packages event log for orders estamp overall log order o1 order o2 order o3 -22 10:00:00 create order o1 create order -22 10:01:00 add item i1,1 to order o1 add item -23 09:20:00 create order o2 create order -23 09:34:00 add item i2,1 to order o2 add item -23 11:33:00 create order o3 create order -23 11:40:00 add item i3,1 to order o3 add item -23 12:27:00 pay order o pay order focus on orders
  • 35. The effect of fl attening Package is carried in 1 p1 p2 p3 Figure 1: Structure of order, item, and package data objects in an order-to-delivery sce- nario whereuv items from di↵erent orders are carried in several packages event log for orders timestamp overall log order o1 order o2 order o3 2019-09-22 10:00:00 create order o1 create order 2019-09-22 10:01:00 add item i1,1 to order o1 add item 2019-09-23 09:20:00 create order o2 create order 2019-09-23 09:34:00 add item i2,1 to order o2 add item 2019-09-23 11:33:00 create order o3 create order 2019-09-23 11:40:00 add item i3,1 to order o3 add item 2019-09-23 12:27:00 pay order o3 pay order 2019-09-23 12:32:00 add item i1,2 to order o1 add item 2019-09-23 13:03:00 pay order o1 pay order 2019-09-23 14:34:00 load item i1,1 into package p1 load item 2019-09-23 14:45:00 add item i2,2 to order o2 add item 2019-09-23 14:51:00 load item i3,1 into package p1 load item 2019-09-23 15:12:00 add item i2,3 to order o2 add item 2019-09-23 15:41:00 pay order o2 pay order 2019-09-23 16:23:00 load item i2,1 into package p2 load item 2019-09-23 16:29:00 load item i1,2 into package p2 load item 2019-09-23 16:33:00 load item i2,2 into package p2 load item 2019-09-23 17:01:00 send package p1 send package send package 2019-09-24 06:38:00 send package p2 send package send package 2019-09-24 07:33:00 load item i2,3 into package p3 load item 2019-09-24 08:46:00 send package p3 send package 2019-09-24 16:21:00 deliver package p1 deliver package deliver package 2019-09-24 17:32:00 deliver package p2 deliver package deliver package 2019-09-24 18:52:00 deliver package p3 deliver package 2019-09-24 18:57:00 accept delivery p3 accept delivery 2019-09-25 08:30:00 deliver package p1 deliver package deliver package 2019-09-25 08:32:00 accept delivery p1 accept delivery accept delivery 2019-09-25 09:55:00 deliver package p2 deliver package deliver package 2019-09-25 17:11:00 deliver package p2 deliver package deliver package 2019-09-25 17:12:00 accept delivery p2 accept delivery accept delivery
  • 36. The effect of fl attening Package is carried in 1 p1 p2 p3 Figure 1: Structure of order, item, and package data objects in an order-to-delivery sce- nario whereuv items from di↵erent orders are carried in several packages event log for orders timestamp overall log order o1 order o2 order o3 2019-09-22 10:00:00 create order o1 create order 2019-09-22 10:01:00 add item i1,1 to order o1 add item 2019-09-23 09:20:00 create order o2 create order 2019-09-23 09:34:00 add item i2,1 to order o2 add item 2019-09-23 11:33:00 create order o3 create order 2019-09-23 11:40:00 add item i3,1 to order o3 add item 2019-09-23 12:27:00 pay order o3 pay order 2019-09-23 12:32:00 add item i1,2 to order o1 add item 2019-09-23 13:03:00 pay order o1 pay order 2019-09-23 14:34:00 load item i1,1 into package p1 load item 2019-09-23 14:45:00 add item i2,2 to order o2 add item 2019-09-23 14:51:00 load item i3,1 into package p1 load item 2019-09-23 15:12:00 add item i2,3 to order o2 add item 2019-09-23 15:41:00 pay order o2 pay order 2019-09-23 16:23:00 load item i2,1 into package p2 load item 2019-09-23 16:29:00 load item i1,2 into package p2 load item 2019-09-23 16:33:00 load item i2,2 into package p2 load item 2019-09-23 17:01:00 send package p1 send package send package 2019-09-24 06:38:00 send package p2 send package send package 2019-09-24 07:33:00 load item i2,3 into package p3 load item 2019-09-24 08:46:00 send package p3 send package 2019-09-24 16:21:00 deliver package p1 deliver package deliver package 2019-09-24 17:32:00 deliver package p2 deliver package deliver package 2019-09-24 18:52:00 deliver package p3 deliver package 2019-09-24 18:57:00 accept delivery p3 accept delivery 2019-09-25 08:30:00 deliver package p1 deliver package deliver package 2019-09-25 08:32:00 accept delivery p1 accept delivery accept delivery 2019-09-25 09:55:00 deliver package p2 deliver package deliver package 2019-09-25 17:11:00 deliver package p2 deliver package deliver package 2019-09-25 17:12:00 accept delivery p2 accept delivery accept delivery orders
  • 37. The effect of fl attening Package is carried in 1 p1 p2 p3 Figure 1: Structure of order, item, and package data objects in an order-to-delivery sce- nario whereuv items from di↵erent orders are carried in several packages event log for orders timestamp overall log order o1 order o2 order o3 2019-09-22 10:00:00 create order o1 create order 2019-09-22 10:01:00 add item i1,1 to order o1 add item 2019-09-23 09:20:00 create order o2 create order 2019-09-23 09:34:00 add item i2,1 to order o2 add item 2019-09-23 11:33:00 create order o3 create order 2019-09-23 11:40:00 add item i3,1 to order o3 add item 2019-09-23 12:27:00 pay order o3 pay order 2019-09-23 12:32:00 add item i1,2 to order o1 add item 2019-09-23 13:03:00 pay order o1 pay order 2019-09-23 14:34:00 load item i1,1 into package p1 load item 2019-09-23 14:45:00 add item i2,2 to order o2 add item 2019-09-23 14:51:00 load item i3,1 into package p1 load item 2019-09-23 15:12:00 add item i2,3 to order o2 add item 2019-09-23 15:41:00 pay order o2 pay order 2019-09-23 16:23:00 load item i2,1 into package p2 load item 2019-09-23 16:29:00 load item i1,2 into package p2 load item 2019-09-23 16:33:00 load item i2,2 into package p2 load item 2019-09-23 17:01:00 send package p1 send package send package 2019-09-24 06:38:00 send package p2 send package send package 2019-09-24 07:33:00 load item i2,3 into package p3 load item 2019-09-24 08:46:00 send package p3 send package 2019-09-24 16:21:00 deliver package p1 deliver package deliver package 2019-09-24 17:32:00 deliver package p2 deliver package deliver package 2019-09-24 18:52:00 deliver package p3 deliver package 2019-09-24 18:57:00 accept delivery p3 accept delivery 2019-09-25 08:30:00 deliver package p1 deliver package deliver package 2019-09-25 08:32:00 accept delivery p1 accept delivery accept delivery 2019-09-25 09:55:00 deliver package p2 deliver package deliver package 2019-09-25 17:11:00 deliver package p2 deliver package deliver package 2019-09-25 17:12:00 accept delivery p2 accept delivery accept delivery orders
  • 38. Discovery? p1 p2 p3 d package data objects in an order-to-delivery sce- ders are carried in several packages event log for orders order o1 order o2 order o3 create order add item create order add item create order add item pay order add item pay order load item add item load item add item pay order load item load item load item send package send package send package send package load item send package deliver package deliver package deliver package deliver package deliver package accept delivery deliver package deliver package accept delivery accept delivery deliver package deliver package deliver package deliver package accept delivery accept delivery to discover a process model th 3 2 4 2 3 3 1 1 3 3 6 5 3 3 create order 3 add item 6 pay order 3 load item 6 send package 5 deliver package 11 accept delivery 5 raw flat case this trac orde flat dire or t orde Two 1. R o s c r i 2. S a o g s i o d i c a c The cove form pro dire the der mis Thi age
  • 39. Discovery? p1 p2 p3 d package data objects in an order-to-delivery sce- ders are carried in several packages event log for orders order o1 order o2 order o3 create order add item create order add item create order add item pay order add item pay order load item add item load item add item pay order load item load item load item send package send package send package send package load item send package deliver package deliver package deliver package deliver package deliver package accept delivery deliver package deliver package accept delivery accept delivery deliver package deliver package deliver package deliver package accept delivery accept delivery to discover a process model th 3 2 4 2 3 3 1 1 3 3 6 5 3 3 create order 3 add item 6 pay order 3 load item 6 send package 5 deliver package 11 accept delivery 5 raw flat case this trac orde flat dire or t orde Two 1. R o s c r i 2. S a o g s i o d i c a c The cove form pro dire the der mis Thi age non-existing loop wrong statistics
  • 40. Do we really need to fl atten reality?
  • 41. Declarative style: fi rst-order temporal logics • OCBC [___,BPM2019] Imperative style data-aware Petri nets • Proclets [Fahland,PN2019] • ISML [Polyvyanyy&van der Werf, CAiSE2019] • catalog-nets [___,BPM2020]
  • 46. time Object-Centric Behavioral Constraints activities data data model activities 
 refer to classes temporal constraints co-refer 
 via data model
  • 47. data model (UML class diagram) Activities refer to classes C1 C2 R
  • 48. data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C
  • 49. data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3
  • 50. data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3 “generating”
  • 51. Hiring Example 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner which instances of tasks are related by the constraint depending on manipulate. In particular, the relevant constraints for our job hiring example are: C.1 The register data task is about a Person. C.2 A Job Offer is created by executing the post offer task. C.3 A Job Offer is closed by determining the winner. C.4 A Job Offer is stopped by canceling the hiring. Enriching Data Models with Behavioral Co C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data a date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least o responding to that Job Offer has been previously marked as el C.9 For each Application responding to a Job Offer, if the Applica as eligible then a winner must be finally determined for that this is done only once for that Job Offer. C.10 When a winner is determined for a Job Offer, Applications res
  • 52. Hiring Example 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner which instances of tasks are related by the constraint depending on manipulate. In particular, the relevant constraints for our job hiring example are: C.1 The register data task is about a Person. C.2 A Job Offer is created by executing the post offer task. C.3 A Job Offer is closed by determining the winner. C.4 A Job Offer is stopped by canceling the hiring. Enriching Data Models with Behavioral Co C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data a date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least o responding to that Job Offer has been previously marked as el C.9 For each Application responding to a Job Offer, if the Applica as eligible then a winner must be finally determined for that this is done only once for that Job Offer. C.10 When a winner is determined for a Job Offer, Applications res
  • 53. Emergent artifact lifecycle 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner
  • 54. Emergent artifact lifecycle 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner “Application” “Job O ff er” many one
  • 55. Expressing the process 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations
  • 56. Expressing the process 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints
  • 57. Temporal constraints 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. Inspired by the Declare declarative process modeling notation
  • 58. Is that enough? No! 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints
  • 59. Is that enough? No! 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints co-reference on object (V co-reference) co-reference on relation (U co-reference)
  • 60. V coreference on response 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship Every time an instance a of A is executed on some object o of type O (i.e., with R1(a,o)) then an instance b of B must be executed afterwards on the same object o (i.e., with R2(b,o)) t
  • 61. V coreference on response 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship Every time an instance a of A is executed on some object o of type O (i.e., with R1(a,o)) then an instance b of B must be executed afterwards on the same object o (i.e., with R2(b,o)) t o:O a:A R1 If then b:B R2
  • 62. U coreference on response t A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then no instance a2 of A2 that relates to the same object o (i.e., with R2(a2, o)) can be executed afterwards (c) Co-reference of non-response over an object class 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). Every time an instance a of A is executed on some object o1 of type O (i.e., with R1(a,o1)) then an instance b of B must be executed afterwards on some object o2 of type O2 (i.e., with R2(b,o2)) that relates to o1 via R 
 (with R(o1,o2) contextually with the execution of b) 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship
  • 63. U coreference on response A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then no instance a2 of A2 that relates to the same object o (i.e., with R2(a2, o)) can be executed afterwards (c) Co-reference of non-response over an object class 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). Every time an instance a of A is executed on some object o1 of type O (i.e., with R1(a,o1)) then an instance b of B must be executed afterwards on some object o2 of type O2 (i.e., with R2(b,o2)) that relates to o1 via R 
 (with R(o1,o2) contextually with the execution of b) t o1:O a:A R1 If then b:B R2 o2:O R 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship
  • 64. Hiring Constraints C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations Enriching Data Models with Behavioral Constraints 13 is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner c c
  • 65. Further Hiring Constraints Enriching Data Models with Behavioral Constraints 13 is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 5 An Application is created by executing the submit task. 6 An Application is promoted by marking it as eligible. 7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. 8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. 9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. 0 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. 1 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2 Capturing the Job Hiring Example with Case-Centric Notations he most fundamental issue when trying to capture the job hiring example of Section 2.1 sing case-centric notation is to identify what is the case. This, in turn, determines hat is the orchestration point for the process, that is, which participant coordinates rocess instances corresponding to different case objects. This problem is apparent when ooking at BPMN, which specifies that each process should correspond to a single locus 4
  • 66. Key questions 1. What is the semantics of these models? 2. Can we do automated reasoning?
 Consistency, dead activities, implied constraints…
 Also relevant for process discovery: inferring single constraints with tolerance on the support may jeopardise model correctness!
  • 67. Temporal Description Logics Family of KR logical formalisms to represent and reason about static, structural knowledge. Provide foundations to: • data models; • ontologies and semantic web. We focus on ALCQI: • captures (wide fragments of) UML class diagrams, E-R, ORM.
  • 68. Temporal Description Logics OBDA for Log Extraction in Process Mining 25 Paper title : String type : String Person pName : String regTime: ts Assignment invTime: ts Submission uploadTime: ts CRUpload Creation DecidedPaper decTime: ts accepted: boolean notifiedBy Review subTime: ts leadsTo Conference cName: String crTime: ts submittedTo chairs * * * 1..* * 1 1 0..1 * 1 1 * Fig. 9: Data model of our CONFSYS running example Correctness of the Encoding. The encoding we have provided is faithful, in the sense that it fully preserves in the DL-LiteA ontology the semantics of the UML class diagram. Obviously, since, due to reification, the ontology alphabet may contain additional sym- bols with respect to those used in the UML class diagram, the two specifications cannot have the same logical models. However, it is possible to show that the logical models of a UML class diagram and those of the DL-LiteA ontology derived from it correspond to each other, and hence that satisfiability of a class or association in the UML diagram corresponds to satisfiability of the corresponding concept or role [29,7]. Example 9. We illustrate the encoding of UML class diagrams in DL-LiteA on the UML class diagram shown in Figure 9, which depicts (a simplified version of) the in- formation model of the CONFSYS conference submission system used for our running example. We assume that the components of associations are given from left to right and from top to bottom. Papers are represented through the Paper class, with attributes A L C Q I
  • 69. Temporal Description Logics (title) ⌘ Paper ⇢(title) v string (funct title) (type) ⌘ Paper ⇢(type) v string (funct type) (decTime) ⌘ DecidedPaper ⇢(decTime) v ts (funct decTime) (accepted) ⌘ DecidedPaper ⇢(accepted) v boolean (funct accepted) (pName) ⌘ Person ⇢(pName) v string (funct pName) (regTime) ⌘ Person ⇢(regTime) v ts (funct regTime) (cName) ⌘ Conference ⇢(cName) v string (funct cName) (crTime) ⌘ Conference ⇢(crTime) v ts (funct crTime) (uploadTime) ⌘ Submission ⇢(uploadTime) v ts (funct uploadTime) (invTime) ⌘ Assignment ⇢(invTime) v ts (funct invTime) (subTime) ⌘ Review ⇢(subTime) v ts (funct subTime) DecidedPaper v Paper Creation v Submission CRUpload v Submission 9Submission1 ⌘ Submission 9Submission1 ⌘ Paper (funct Submission1) 9Submission2 ⌘ Submission 9Submission2 v Person (funct Submission2) 9Assignment1 ⌘ Assignment 9Assignment1 v Paper (funct Assignment1) 9Assignment2 ⌘ Assignment 9Assignment2 v Person (funct Assignment2) 9leadsTo v Assignment 9leadsTo ⌘ Review (funct leadsTo) (funct leadsTo ) 9submittedTo ⌘ Paper 9submittedTo v Conference (funct submittedTo) 9notifiedBy ⌘ DecidedPaper 9notifiedBy v Person (funct notifiedBy) 9chairs v Person 9chairs ⌘ Conference (funct chairs ) OBDA for Log Extraction in Process Mining 25 Paper title : String type : String Person pName : String regTime: ts Assignment invTime: ts Submission uploadTime: ts CRUpload Creation DecidedPaper decTime: ts accepted: boolean notifiedBy Review subTime: ts leadsTo Conference cName: String crTime: ts submittedTo chairs * * * 1..* * 1 1 0..1 * 1 1 * Fig. 9: Data model of our CONFSYS running example Correctness of the Encoding. The encoding we have provided is faithful, in the sense that it fully preserves in the DL-LiteA ontology the semantics of the UML class diagram. Obviously, since, due to reification, the ontology alphabet may contain additional sym- bols with respect to those used in the UML class diagram, the two specifications cannot have the same logical models. However, it is possible to show that the logical models of a UML class diagram and those of the DL-LiteA ontology derived from it correspond to each other, and hence that satisfiability of a class or association in the UML diagram corresponds to satisfiability of the corresponding concept or role [29,7]. Example 9. We illustrate the encoding of UML class diagrams in DL-LiteA on the UML class diagram shown in Figure 9, which depicts (a simplified version of) the in- formation model of the CONFSYS conference submission system used for our running example. We assume that the components of associations are given from left to right and from top to bottom. Papers are represented through the Paper class, with attributes A L C Q I
  • 70. Temporal Description Logics Family of KR logical formalisms to represent and reason about time. We focus on LTL: • models: execution traces (over tasks only); • (in its fi nite-trace version) at the basis of the Declare modelling language.
  • 71. 8 A. Artale, D. Calvanese, M. Montali, and W. van A B response A unary-respons A B precedence A unary-preceden A B responded-existence Fig. 3: Types of temporal constraints response(A, B) If A is executed, then B unary- response(A, B) If A is executed, then B Calvanese, M. Montali, and W. van der Aalst B A B unary-response A B non-response B A B unary-precedence A B non-precedence B tence A B non-coexistence 3: Types of temporal constraints between activities If A is executed, then B must be executed afterwards. B) If A is executed, then B must be executed exactly once after- 8 A. Artale, D. Calvanese, M. Montali, and W. van A B response A unary-respons A B precedence A unary-preceden A B responded-existence Fig. 3: Types of temporal constraints response(A, B) If A is executed, then B L T L Temporal Description Logics
  • 72. 8 A. Artale, D. Calvanese, M. Montali, and W. van A B response A unary-respons A B precedence A unary-preceden A B responded-existence Fig. 3: Types of temporal constraints response(A, B) If A is executed, then B unary- response(A, B) If A is executed, then B Calvanese, M. Montali, and W. van der Aalst B A B unary-response A B non-response B A B unary-precedence A B non-precedence B tence A B non-coexistence 3: Types of temporal constraints between activities If A is executed, then B must be executed afterwards. B) If A is executed, then B must be executed exactly once after- 8 A. Artale, D. Calvanese, M. Montali, and W. van A B response A unary-respons A B precedence A unary-preceden A B responded-existence Fig. 3: Types of temporal constraints response(A, B) If A is executed, then B L T L Temporal Description Logics 2(A ! 3F B) 2(A ! 3PB) 2(A ! 2 ⇤ ¬B) ns available to model business processes, ife processes using mainstream notations
  • 73. Temporal Description Logics Combine static and dynamic aspects into a unique logical framework. The right framework to capture OCBC. • Model: global event log with intertwined objects.
 1-to-1 correspondence with data-aware logs o1 : Order ol1 : Order Line ol2 : Order Line ol3 : Order Line d1 : Delivery d2 : Delivery ... ... ... ... ... ... co1 : Create Order pi1 : Pick Item pi2 : Pick Item wi1 : Wrap Item wi2 : Wrap Item pi3 : Pick Item wi3 : Wrap Item po1 : Pay Order di1 : Deliver Items di2 : Deliver Items t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 creates fills contains fills contains prepares prepares fills contains prepares closes refers to results in results in refers to results in
  • 74. Combining multiple dimensions is dangerous: undecidability around the corner! Can we formalize OCBC in a well-behaved temporal DL?
  • 77. Which Route? A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex
  • 78. Which Route? A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Chaining relations across time Flow object
  • 79. Which Route? A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Chaining relations across time Flow object
  • 80. Question A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Do we need to global constraints on activities, without co-referencing in the data model? No: everything scoped by data objects!
  • 81. Activities Fade Away A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Do we need to global constraints on activities, without co-referencing in the data model? The temporal DL su ffi ces!
 [Combines with LTL over concepts only] No: everything scoped by data objects! Temporal constraint over O1 and O2 no order line of an order can be wrapped after ify that the former constraint is indeed implied, ot. While it is true that once an order is paid or it, already picked order lines may still need . This amounts to check whether a trace frag- n M. Since ρ is a trace fragment, we require ained in ρ and that ρ can be’completed’ into a satisfies M. This corresponds to the notion of ntroduced in [15]. In our setting, this amounts coding ρ is satisfiable w.r.t. the TBox TM, i.e., ble. Notice that, KB satisfiability and logical impli- n ALCQI [6] (and thus in TUSALCQI) and SALCQI are ExpTime-complete [18,27], which an be paid only if it has been an order can be wrapped after mer constraint is indeed implied, true that once an order is paid cked order lines may still need to check whether a trace frag- s a trace fragment, we require hat ρ can be’completed’ into a is corresponds to the notion of 5]. In our setting, this amounts sfiable w.r.t. the TBox TM, i.e., satisfiability and logical impli- and thus in TUSALCQI) and
  • 82. Response Example Every time an instance a of A is executed on some object o1 of type O (i.e., with R1(a,o1)) then an instance b of B must be executed afterwards on some object o2 (i.e., with R2(b,o2)) that relates to o1 via R 
 (with R(o1,o2) contextually with the execution of b) 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then no instance a2 of A2 that relates to the same object o (i.e., with R2(a2, o)) can be executed afterwards 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once
  • 83. Response Example 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then no instance a2 of A2 that relates to the same object o (i.e., with R2(a2, o)) can be executed afterwards 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once Every time an instance a of A is executed on some object o1 of type O (i.e., with R1(a,o1)) then an instance b of B must be executed afterwards on some object o2 (i.e., with R2(b,o2)) that relates to o1 via R 
 (with R(o1,o2) contextually with the execution of b) Every time some object o1 of type O1 is subject to some instance of A (i.e., is target of R1) then afterwards some object o2 of type O2 must relate to o1 via R and be subject to some instance of B (i.e., be target of R2) o1:O … some A R1 If then o2:O R R2 … some B
  • 84. A glimpse of the formalization 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship t o:O a:A R1 If then according to Definition 3, can be either ge either over object classes (as illustrated ips (as illustrated in Fig. 5b and d). Let d O ∈ UC s.t. tc(A1, A2) ∈ Σ+ T C, τRAC O) and cref be a co-reference constraint o c(A1, A2), R1, R2) = O (as in Fig. 5a). Then n tc is the response temporal constraint i ∃R− 1 ! ♦F ∃R− 2 t “whenever an object is in the range of b:B R2
  • 85. b’:B R2 A glimpse of the formalization o:O a:A R1 If then b:B R2 according to Definition 3, can be either ge either over object classes (as illustrated ips (as illustrated in Fig. 5b and d). Let d O ∈ UC s.t. tc(A1, A2) ∈ Σ+ T C, τRAC O) and cref be a co-reference constraint o c(A1, A2), R1, R2) = O (as in Fig. 5a). Then n tc is the response temporal constraint i ∃R− 1 ! ♦F ∃R− 2 t “whenever an object is in the range of 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship t ver the activities via the co-referenced obj ed via R1 to an object in O then it must b erencing the same object via R2. Formally ds: (2), A1 ! ∃R1} |= A1 ! ∃R1. ♦F ∃R− 2 . A2 y-response temporal constraint we need t mula that guarantees a unique occurrence o ∃R− 2 " ♦P ∃R− 1 ! "F ¬∃R− 2
  • 86. A glimpse of the formalization t o:O a:A R1 If then A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then no instance a2 of A2 that relates to the same object o (i.e., with R2(a2, o)) can be executed afterwards (c) Co-reference of non-response over an object class 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. unary- precedence(A, B) If A is executed, then B must have been executed exactly once before. responded- existence(A, B) If A is execute, then B must also be executed (either before or afterwards). 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is executed on some object o of type O (i.e., with R1(a1, o)), then an instance a2 of A2 must be executed afterwards on the same object o (i.e., with R2(a2, o)) (a) Co-reference of response over an object class A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A1 is executed on some object o1 of type O1 (i.e., with R1(a1, o1)), then an instance a2 of A2 must be executed afterwards on some object o2 of type O2 (i.e., with R2(a2, o2)) that relates to o1 via R (i.e., having R(o1, o2) at the moment of execution of a2). (b) Co-reference of response over a relationship b:B R2 R ∃R− 2 # ♦F ∃R− 1 " "P ¬∃R− 2 ∃R− 1 " ♦ ∗ ∃R− 2 sider co-reference constraints over relationships. A ∈ UR, with τ(R) = (O1, O2), τRAC (R1) = (A1, O ef be a co-reference of the form: cref(tc(A1, A2 ntics of co-reference over relationships when tc i ptured by: ∃R− 1 " ♦F ∃R. ∃R− 2 “every object in the range of R1 sometime in th
  • 87. Key reasoning tasks Consistency: does the OCBC model admit at least one conforming event log? Dead activity detection: is it possible to imagine a log containing the execution of the activity of interest? Hidden dependencies: is a constraint implied by the model? Conditional conformance: does a given log satisfy the OCBC model, possibly introducing missing events/data?
  • 88. Implied Constraints 
 (Hidden Dependencies) Enriching Data Models with Behavioral Constraints 13 is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 An Application is promoted by marking it as eligible. 7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. 8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. 9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. 0 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. 1 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). .2 Capturing the Job Hiring Example with Case-Centric Notations he most fundamental issue when trying to capture the job hiring example of Section 2.1 sing case-centric notation is to identify what is the case. This, in turn, determines hat is the orchestration point for the process, that is, which participant coordinates rocess instances corresponding to different case objects. This problem is apparent when ooking at BPMN, which specifies that each process should correspond to a single locus f control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- ging Applications), and the job hiring organisation (in turn responsible for the The OCBC model implies:
  • 89. Complexity considerations Consistency, dead activity detection, checking implied constraints, conditional conformance can all be reduced to standard reasoning in • ExpTime upper bound If we only adopt V-coreference on classes, and do not consider covering on UML hierarchies: • The logic su ffi ces • Complexity drops to PSPACE 
 (same as plain old LTL) tained in ρ and that ρ can be’completed’ into a at satisfies M. This corresponds to the notion of introduced in [15]. In our setting, this amounts encoding ρ is satisfiable w.r.t. the TBox TM, i.e., able. . Notice that, KB satisfiability and logical impli- in ALCQI [6] (and thus in TUSALCQI) and USALCQI are ExpTime-complete [18,27], which bound for verifying properties of OCBC models. e base DL is due to co-reference constraints over he power of qualified existential (∃R. C) and its raints (i.e., only consider OCBC constraints co- use a temporalized version of a DL-Lite dialect. L-Lite fragment TUSDL-Lite (HN ) bool , showed to be to capture OCBC models with the exception of ationships while, at the level of the data model, main constructs of UML—with the exception of ation is contained in ρ and that ρ can be’completed’ int te trace that satisfies M. This corresponds to the notion nce recently introduced in [15]. In our setting, this amou e ABox Aρ encoding ρ is satisfiable w.r.t. the TBox TM, i M,ρ is satisfiable. derations. Notice that, KB satisfiability and logical im reducible in ALCQI [6] (and thus in TUSALCQI) a lems over TUSALCQI are ExpTime-complete [18,27], wh ime upper bound for verifying properties of OCBC mod CQI as the base DL is due to co-reference constraints o requires the power of qualified existential (∃R. C) and such constraints (i.e., only consider OCBC constraints , we could use a temporalized version of a DL-Lite diale emporal DL-Lite fragment TUSDL-Lite (HN ) bool , showed to [8], is able to capture OCBC models with the exception
  • 90. Conclusion OCBC: a declarative approach
 to elegantly capture processes
 with co-evolving objects Formal logic-based semantics in a temporal DL that enables automated reasoning
  • 91. Rigid roles? Monitoring
 (closed-open reasoning) Discovery of OCBC fragments 
 and other (imperative) models with data correlations
 Baseline: [Li et al,BIS2017], [Berti&vanderAalst,Arxiv2020],
 [Lu et al, IEEETSC2015] Future work