Faculty of Computer Science - Free University of Bozen-Bolzano, profile picture
Uploaded byFaculty of Computer Science - Free University of Bozen-Bolzano
PDF, PPTX29 views

From Case-Isolated to Object-Centric Processes

The document discusses the transition from case-isolated to object-centric process models, emphasizing the importance of integrating data and processes. It presents decision tables for ship clearance and refuel area determination, illustrating rules that dictate outcomes based on various input attributes. The text highlights challenges in instance alignment and offers insights into modeling job hiring processes with a focus on case-centricity.

Science◦
Related topics:
ERP Systems•

Embed presentation

Download as PDF, PPTX
1 / 123
2 / 123
3 / 123
4 / 123
5 / 123
6 / 123
7 / 123
8 / 123
9 / 123
10 / 123
11 / 123
12 / 123
13 / 123
14 / 123
15 / 123
16 / 123
17 / 123
18 / 123
19 / 123
20 / 123
21 / 123
22 / 123
23 / 123
24 / 123
25 / 123
26 / 123
27 / 123
28 / 123
29 / 123
30 / 123
31 / 123
32 / 123
33 / 123
34 / 123
35 / 123
36 / 123
37 / 123
38 / 123
39 / 123
40 / 123
41 / 123
42 / 123
43 / 123
44 / 123
45 / 123
46 / 123
47 / 123
48 / 123
49 / 123
50 / 123
51 / 123
52 / 123
53 / 123
54 / 123
55 / 123
56 / 123
57 / 123
58 / 123
59 / 123
60 / 123
61 / 123
62 / 123
63 / 123
64 / 123
65 / 123
66 / 123
67 / 123
68 / 123
69 / 123
70 / 123
71 / 123
72 / 123
73 / 123
74 / 123
75 / 123
76 / 123
77 / 123
78 / 123
79 / 123
80 / 123
81 / 123
82 / 123
83 / 123
84 / 123
85 / 123
86 / 123
87 / 123
88 / 123
89 / 123
90 / 123
91 / 123
92 / 123
93 / 123
94 / 123
95 / 123
96 / 123
97 / 123
98 / 123
99 / 123
100 / 123
101 / 123
102 / 123
103 / 123
104 / 123
105 / 123
106 / 123
107 / 123
108 / 123
109 / 123
110 / 123
111 / 123
112 / 123
113 / 123
114 / 123
115 / 123
116 / 123
117 / 123
118 / 123
119 / 123
120 / 123
121 / 123
122 / 123
123 / 123
From Case-Isolated to Object-Centric Processes A Tale of Two Models Marco Montali montali@inf.unibz.it BINF, 26/05/2021 joint work with Wil van der Aalst, Alessandro Artale, Alisa Kovtunova, Silvio Ghilardi, Alessandro Gianola, Andrey Rivkin.
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) 3 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) 4 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?
time data activities
time activities data
time activities data data objects
time activities data data objects control- fl ow 
 refers to data objects
time activities data data objects objects and relationships evolve over time control- fl ow 
 refers to data objects
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]
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]
data model (UML class diagram) Start from a data model 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
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)
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!
Key answers 1. What is the semantics of these models? Temporal description logics 2. Can we do automated reasoning?
 Yes, upon carefully formalising models, letting the control- fl ow “disappear”.
 This gives ExpTime-completeness for reasoning tasks.
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]
Data components • object ID s • typed case dat a • Read-only DB (catalog) Process components • high-level Petri ne t Catalog and Object-Aware Nets
Coloured places maintain (typed) case data • each data type is having a potentially in fi nite value domain and equipped with an equality predicat e • data types can be de fi ned using the Cartesian product • EX: Order=<INTo,=o> is an order type whose value domain is an in fi nite set of order identi fi ers that can be compared by equality Net Object lifecycle pool: Truck use in house: Truck go back at dest: Truck move hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti Figure 1: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. working: Order new order pay paid: Order ⌫o o o Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. 2 COA-nets: main features
Fresh data generation using dedicated -variables (like in [FI’08]) • EX: generates always (locally) unique order identi fi ers ⌫ <latexit sha1_base64="Jlo2fTg1/mzzbJ8f9iNdQEnpd2c=">AAAB7HicbZDLSgMxFIbP1Fsdb1WXboKt4KpM3OhGLLhxWcVpC+1QMmmmDc1khiQjlKHgG7hxoYhbH8iN+Daml4W2/hD4+P9zyDknTAXXxvO+ncLK6tr6RnHT3dre2d0r7R80dJIpynyaiES1QqKZ4JL5hhvBWqliJA4Fa4bD60nefGBK80Tem1HKgpj0JY84JcZafqUjs0q3VPaq3lRoGfAcyldf7uUjANS7pc9OL6FZzKShgmjdxl5qgpwow6lgY7eTaZYSOiR91rYoScx0kE+HHaMT6/RQlCj7pEFT93dHTmKtR3FoK2NiBnoxm5j/Ze3MRBdBzmWaGSbp7KMoE8gkaLI56nHFqBEjC4QqbmdFdEAUocbex7VHwIsrL0PjrIq9Kr7F5dodzFSEIziGU8BwDjW4gTr4QIHDE7zAqyOdZ+fNeZ+VFpx5zyH8kfPxA6B7kB0=</latexit> ⌫o <latexit sha1_base64="VpxPZuWw3J3QGSpkBFjp/ObT3b4=">AAAB7nicbZDLSgMxFIbPeK31VnWnm2AruCozbnRZEMFlBXuBdiiZNNOG5jIkGaEMBV/BjQtF3PZ53PkCPofp1IW2/hDy8f8n5JwTJZwZ6/uf3srq2vrGZmGruL2zu7dfOjhsGpVqQhtEcaXbETaUM0kblllO24mmWESctqLR9SxvPVBtmJL3dpzQUOCBZDEj2DqrVenKtKcqvVLZr/q50DIEP1CuHU+/EADUe6WPbl+RVFBpCcfGdAI/sWGGtWWE00mxmxqaYDLCA9pxKLGgJszydifozDl9FCvtjrQod3+/yLAwZiwiVymwHZrFbGb+l3VSG1+FGZNJaqkk84/ilCOr0Gx21GeaEsvHDjDRzPWKyBBrTKzbUNEtIVgceRmaF9XArwZ3Qbl28wi5CnACp3AOAVxCDW6hDg0gMIIneIFXL/GevTfvfV664s1vOII/8qbfgi+RnQ==</latexit> [FI’08] Rosa-Velardo F. and de Frutos-Escrig D. “Name Creation vs. Replication in Petri Net Systems”. Fundam. Inform 88(3), 2008 Net Object lifecycle pool: Truck use in house: Truck go back at dest: Truck move hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti Figure 1: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. working: Order new order pay paid: Order ⌫o o o Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. 2 COA-nets: main features
Catalog is a read-only relational database • every fact has a unique ID (Primary Key) • relations can be related using Foreign Keys Product category Typ e fish … Product-truck compatibility CID Prod. Type Truck Type 15 fish refrig. truck … … … attribute types have to coincide! COA-nets: main features
Transition guards [Q⋀ 𝞿 ] have two functions: • fi lter ( 𝞿 ) the fl ow of the case data (analogous to CPNs) • query (Q) the catalog and possibly inject data into the net using query results add item [ProdCat(p) ^ p 6= 0 alcohol0 ] ready: Item working: Order new order pay paid: Order ⌫o o ⌫o o o hp, oi hp, oi Figure 1: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Petri Net-Based Object-Centric Processes with Read-Only Data COA-nets: main features
Transition guards [Q⋀ 𝞿 ] have two functions: • fi lter ( 𝞿 ) the fl ow of the case data (analogous to CPNs) • query (Q) the catalog and possibly inject data into the net using query results add item [ProdCat(p) ^ p 6= 0 alcohol0 ] ready: Item working: Order new order pay paid: Order ⌫o o ⌫o o o hp, oi hp, oi Figure 1: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Petri Net-Based Object-Centric Processes with Read-Only Data “injected” product category consider all product categories but ‘alcohol’ COA-nets: main features
COA-nets: execution Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. !"#$%&'()*(+*, !"-#./'(0*(+*, Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … …
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … ⌫o 7! o233 <latexit sha1_base64="7+f5Cc+zpVJ5cs+ln19shw0YmPc=">AAACA3icbVDLSsNAFL2pr1pfUXe6CRbBVUlaQZcFNy4r2Ac0oUymk3boZCbMTIQSCm78FTcuFHHbP3Dlzr9xmnahrQeGOZxzL/feEyaMKu2631ZhbX1jc6u4XdrZ3ds/sA+PWkqkEpMmFkzITogUYZSTpqaakU4iCYpDRtrh6Gbmtx+IVFTwez1OSBCjAacRxUgbqWef+DztCT9GidLCMb8eqigT1Vpt0rPLbsXN4awSb0HK9eLnFAwaPfvL7wucxoRrzJBSXc9NdJAhqSlmZFLyU0UShEdoQLqGchQTFWT5DRPn3Ch9JxLSPK6dXP3dkaFYqXEcmsp8yWVvJv7ndVMdXQcZ5UmqCcfzQVHKHHPuLBCnTyXBmo0NQVhSs6uDh0girE1sJROCt3zyKmlVK55b8e68cv0S5ijCKZzBBXhwBXW4hQY0AcMjPMMrvFlP1ov1bn3MSwvWoucY/sCa/gBYF5lq</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 ⌫o 7! o45 <latexit sha1_base64="5A+IAallYCTgIQWtp+DQ42/M+w8=">AAACAnicbVDLSsNAFL3xWesr6krcBIvgqiRS0WXBjcsK9gFNCJPppB06mQkzE6GE4sZfceNCEbf6B67c+TdO0y609cAwh3Pu5d57opRRpV3321paXlldWy9tlDe3tnd27b39lhKZxKSJBROyEyFFGOWkqalmpJNKgpKIkXY0vJr47TsiFRX8Vo9SEiSoz2lMMdJGCu1Dn2eh8BOUKi0c8+uBinNROx+HdsWtugWcReLNSKVe+vwAg0Zof/k9gbOEcI0ZUqrruakOciQ1xYyMy36mSIrwEPVJ11COEqKCvDhh7JwYpefEQprHtVOovztylCg1SiJTWew4703E/7xupuPLIKc8zTTheDoozphjrp3k4fSoJFizkSEIS2p2dfAASYS1Sa1sQvDmT14krbOq51a9G69Sr8EUJTiCYzgFDy6gDtfQgCZguIdHeIYX68F6sl6tt2npkjXrOYA/sN5/AOIhmTE=</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- o 7! o45 <latexit sha1_base64="Q+h2I9D+v8dR8mfuE7LWxc6ER4k=">AAAB/nicbVDLSgMxFL3js9bXqLhyEyyCqzIjFd1ZcOOygn1AO5RMmmlDM8mQZIQyFPyN7nTjQhG3+hvu/BvTx0JbL4QczrmXe+4JE8608bxvZ2l5ZXVtPbeR39za3tl19/ZrWqaK0CqRXKpGiDXlTNCqYYbTRqIojkNO62H/eqzX76nSTIo7M0hoEOOuYBEj2Fiq7R7KVowTbSSyv+npKJOl82HbLXhFb1JoEfgzULj6HI0eAaDSdr9aHUnSmApDONa66XuJCTKsDCOcDvOtVNMEkz7u0qaFAsdUB9nE/hCdWKaDIqnsEwZN2N8TGY61HsSh7Zx4nNfG5H9aMzXRZZAxkaSGCjJdFKUc2WvHWaAOU5QYPrAAE8WsV0R6WGFibGJ5G4I/f/IiqJ0Vfa/o3/qFcgmmlYMjOIZT8OECynADFagCgQye4AVenQfn2Xlz3qetS85s5gD+lPPxAwWkmGQ=</latexit> p 7! fish <latexit sha1_base64="yF736hH/nj+oZ4l43YcY80kLqVI=">AAAB/nicbVDLSgMxFL3js9ZHR8WVm2ARXJUZEXRnwY3LCvYBbSmZNNOGZpKQZIQyFPwVNy4Ucet3uPMT/AvTaRfaeiDkcM695OREijNjg+DLW1ldW9/YLGwVt3d290r+/kHDyFQTWieSS92KsKGcCVq3zHLaUpriJOK0GY1upn7zgWrDpLi3Y0W7CR4IFjOCrZN6/pHqJFgZK91lhybOYmaGk55fDipBDrRMwjkpV0vf1wgAaj3/s9OXJE2osIRjY9phoGw3w9oywumk2EkNVZiM8IC2HRU4oaab5fEn6NQpfRRL7Y6wKFd/b2Q4MWacRG4yD7noTcX/vHZq46tuxoRKLRVk9lCccmQlmnaB+kxTYvnYEUw0c1kRGWKNiXWNFV0J4eKXl0njvBIGlfAuLFcvYIYCHMMJnEEIl1CFW6hBHQhk8AQv8Oo9es/em/c+G13x5juH8Afexw96ypfk</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- !4567'13-, COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- o 7! o45 <latexit sha1_base64="Q+h2I9D+v8dR8mfuE7LWxc6ER4k=">AAAB/nicbVDLSgMxFL3js9bXqLhyEyyCqzIjFd1ZcOOygn1AO5RMmmlDM8mQZIQyFPyN7nTjQhG3+hvu/BvTx0JbL4QczrmXe+4JE8608bxvZ2l5ZXVtPbeR39za3tl19/ZrWqaK0CqRXKpGiDXlTNCqYYbTRqIojkNO62H/eqzX76nSTIo7M0hoEOOuYBEj2Fiq7R7KVowTbSSyv+npKJOl82HbLXhFb1JoEfgzULj6HI0eAaDSdr9aHUnSmApDONa66XuJCTKsDCOcDvOtVNMEkz7u0qaFAsdUB9nE/hCdWKaDIqnsEwZN2N8TGY61HsSh7Zx4nNfG5H9aMzXRZZAxkaSGCjJdFKUc2WvHWaAOU5QYPrAAE8WsV0R6WGFibGJ5G4I/f/IiqJ0Vfa/o3/qFcgmmlYMjOIZT8OECynADFagCgQye4AVenQfn2Xlz3qetS85s5gD+lPPxAwWkmGQ=</latexit> p 7! fish <latexit sha1_base64="yF736hH/nj+oZ4l43YcY80kLqVI=">AAAB/nicbVDLSgMxFL3js9ZHR8WVm2ARXJUZEXRnwY3LCvYBbSmZNNOGZpKQZIQyFPwVNy4Ucet3uPMT/AvTaRfaeiDkcM695OREijNjg+DLW1ldW9/YLGwVt3d290r+/kHDyFQTWieSS92KsKGcCVq3zHLaUpriJOK0GY1upn7zgWrDpLi3Y0W7CR4IFjOCrZN6/pHqJFgZK91lhybOYmaGk55fDipBDrRMwjkpV0vf1wgAaj3/s9OXJE2osIRjY9phoGw3w9oywumk2EkNVZiM8IC2HRU4oaab5fEn6NQpfRRL7Y6wKFd/b2Q4MWacRG4yD7noTcX/vHZq46tuxoRKLRVk9lCccmQlmnaB+kxTYvnYEUw0c1kRGWKNiXWNFV0J4eKXl0njvBIGlfAuLFcvYIYCHMMJnEEIl1CFW6hBHQhk8AQv8Oo9es/em/c+G13x5juH8Afexw96ypfk</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-, !4567'13-,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- o 7! o45 <latexit sha1_base64="Q+h2I9D+v8dR8mfuE7LWxc6ER4k=">AAAB/nicbVDLSgMxFL3js9bXqLhyEyyCqzIjFd1ZcOOygn1AO5RMmmlDM8mQZIQyFPyN7nTjQhG3+hvu/BvTx0JbL4QczrmXe+4JE8608bxvZ2l5ZXVtPbeR39za3tl19/ZrWqaK0CqRXKpGiDXlTNCqYYbTRqIojkNO62H/eqzX76nSTIo7M0hoEOOuYBEj2Fiq7R7KVowTbSSyv+npKJOl82HbLXhFb1JoEfgzULj6HI0eAaDSdr9aHUnSmApDONa66XuJCTKsDCOcDvOtVNMEkz7u0qaFAsdUB9nE/hCdWKaDIqnsEwZN2N8TGY61HsSh7Zx4nNfG5H9aMzXRZZAxkaSGCjJdFKUc2WvHWaAOU5QYPrAAE8WsV0R6WGFibGJ5G4I/f/IiqJ0Vfa/o3/qFcgmmlYMjOIZT8OECynADFagCgQye4AVenQfn2Xlz3qetS85s5gD+lPPxAwWkmGQ=</latexit> p 7! fish <latexit sha1_base64="yF736hH/nj+oZ4l43YcY80kLqVI=">AAAB/nicbVDLSgMxFL3js9ZHR8WVm2ARXJUZEXRnwY3LCvYBbSmZNNOGZpKQZIQyFPwVNy4Ucet3uPMT/AvTaRfaeiDkcM695OREijNjg+DLW1ldW9/YLGwVt3d290r+/kHDyFQTWieSS92KsKGcCVq3zHLaUpriJOK0GY1upn7zgWrDpLi3Y0W7CR4IFjOCrZN6/pHqJFgZK91lhybOYmaGk55fDipBDrRMwjkpV0vf1wgAaj3/s9OXJE2osIRjY9phoGw3w9oywumk2EkNVZiM8IC2HRU4oaab5fEn6NQpfRRL7Y6wKFd/b2Q4MWacRG4yD7noTcX/vHZq46tuxoRKLRVk9lCccmQlmnaB+kxTYvnYEUw0c1kRGWKNiXWNFV0J4eKXl0njvBIGlfAuLFcvYIYCHMMJnEEIl1CFW6hBHQhk8AQv8Oo9es/em/c+G13x5juH8Afexw96ypfk</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-, !4567'13-,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-, !4567'13-,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- o 7! o45 <latexit sha1_base64="Q+h2I9D+v8dR8mfuE7LWxc6ER4k=">AAAB/nicbVDLSgMxFL3js9bXqLhyEyyCqzIjFd1ZcOOygn1AO5RMmmlDM8mQZIQyFPyN7nTjQhG3+hvu/BvTx0JbL4QczrmXe+4JE8608bxvZ2l5ZXVtPbeR39za3tl19/ZrWqaK0CqRXKpGiDXlTNCqYYbTRqIojkNO62H/eqzX76nSTIo7M0hoEOOuYBEj2Fiq7R7KVowTbSSyv+npKJOl82HbLXhFb1JoEfgzULj6HI0eAaDSdr9aHUnSmApDONa66XuJCTKsDCOcDvOtVNMEkz7u0qaFAsdUB9nE/hCdWKaDIqnsEwZN2N8TGY61HsSh7Zx4nNfG5H9aMzXRZZAxkaSGCjJdFKUc2WvHWaAOU5QYPrAAE8WsV0R6WGFibGJ5G4I/f/IiqJ0Vfa/o3/qFcgmmlYMjOIZT8OECynADFagCgQye4AVenQfn2Xlz3qetS85s5gD+lPPxAwWkmGQ=</latexit> n 7! T52YN <latexit sha1_base64="TIGsAcai7alWVaH1QYFY6+BN218=">AAACAHicbVDLSsNAFL2pr1pfURcu3ASL4KokRdGdBTeupEJf0oYymU7aoZNJmJkIJWTjX3QnuHGhiEv9DHf+jdO0C209MMzhnHu59x4vYlQq2/42ckvLK6tr+fXCxubW9o65u9eQYSwwqeOQhaLlIUkY5aSuqGKkFQmCAo+Rpje8mvjNeyIkDXlNjSLiBqjPqU8xUlrqmge8E6BIqtDSvxpIP6mdle9u0q5ZtEt2BmuRODNSvPwYjx8BoNo1vzq9EMcB4QozJGXbsSPlJkgoihlJC51YkgjhIeqTtqYcBUS6SXZAah1rpWf5odCPKytTf3ckKJByFHi6Mtty3puI/3ntWPkXbkJ5FCvC8XSQHzNL3ztJw+pRQbBiI00QFlTvauEBEggrnVlBh+DMn7xIGuWSY5ecW6dYOYUp8nAIR3ACDpxDBa6hCnXAkMITvMCr8WA8G2/G+7Q0Z8x69uEPjM8fL2+ZAQ==</latexit> p 7! fish <latexit sha1_base64="yF736hH/nj+oZ4l43YcY80kLqVI=">AAAB/nicbVDLSgMxFL3js9ZHR8WVm2ARXJUZEXRnwY3LCvYBbSmZNNOGZpKQZIQyFPwVNy4Ucet3uPMT/AvTaRfaeiDkcM695OREijNjg+DLW1ldW9/YLGwVt3d290r+/kHDyFQTWieSS92KsKGcCVq3zHLaUpriJOK0GY1upn7zgWrDpLi3Y0W7CR4IFjOCrZN6/pHqJFgZK91lhybOYmaGk55fDipBDrRMwjkpV0vf1wgAaj3/s9OXJE2osIRjY9phoGw3w9oywumk2EkNVZiM8IC2HRU4oaab5fEn6NQpfRRL7Y6wKFd/b2Q4MWacRG4yD7noTcX/vHZq46tuxoRKLRVk9lCccmQlmnaB+kxTYvnYEUw0c1kRGWKNiXWNFV0J4eKXl0njvBIGlfAuLFcvYIYCHMMJnEEIl1CFW6hBHQhk8AQv8Oo9es/em/c+G13x5juH8Afexw96ypfk</latexit> t 7! r.t. <latexit sha1_base64="UC25E9sEdsQmQ3/NQfToUWKMWaE=">AAAB/nicbVDLSsNAFL3xWesrKq7cBIvgKiQi6M6CG5cV7APaUibTSTt0MgkzN0IJBX+jO924UMSt/oY7/8Zp2oW2HhjmcM69zJkTJIJr9Lxva2l5ZXVtvbBR3Nza3tm19/ZrOk4VZVUai1g1AqKZ4JJVkaNgjUQxEgWC1YPB9cSv3zOleSzvcJiwdkR6koecEjRSxz7EVkQSjbG5sK/DTLnojjp2yXO9HM4i8WekdPU5Hj8CQKVjf7W6MU0jJpEKonXT9xJsZ0Qhp4KNiq1Us4TQAemxpqGSREy3szz+yDkxStcJY2WORCdXf29kJNJ6GAVmMg85703E/7xmiuFlO+MySZFJOn0oTIWDsTPpwulyxSiKoSGEKm6yOrRPFKFoGiuaEvz5Ly+S2pnre65/65fK5zBFAY7gGE7Bhwsoww1UoAoUMniCF3i1Hqxn6816n44uWbOdA/gD6+MHgRyYsw==</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-, !4567'13-,
Truck Truck Truck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- !4567'13-'"-#./, COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-,
COA-nets: modelling highlights pool: Truck use in house: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o
COA-nets: modelling highlights pool: Truck use in house: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o Create unboundedly many orders (by generating fresh IDs)
COA-nets: modelling highlights pool: Truck use in house: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o a pattern for creating objects on the many side of a 1-to-many relation
COA-nets: modelling highlights pool: Truck use in house: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o A PN-version of a SELECT-PROJECT- JOIN SQL query with fi lters
COA-nets: modelling highlights pool: Truck use in house: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o • create items using the catalog and IDs of owning order s ➡ multiple items with the same product typ e • not needed to track their evolution (no explicit ID) as items are never on the 1-side of some 1-to-many relation
COA-nets: modelling highlights pool: Truck use in house: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o • when loaded on a truck, an item will reference its plate number (i.e., ID) • create items using the catalog and IDs of owning order s ➡ multiple items with the same product typ e • not needed to track their evolution (no explicit ID) as items are never on the 1-side of some 1-to-many relation
COA-nets: modelling highlights pool: Truck use in house: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o • trucks as resources ( fi xed in pool ) • can change their stat e • cannot be destroyed
COA-nets: modelling highlights pool: Truck use in house: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o nondeterministic synch.: items can synchronise with a referenced truck, but the truck can decide to go back and leave some items undelivered
Reasoning on COA-nets • Typical Petri nets properties (reachability, coverability, soundness) in their “data-aware” version. • More sophisticated data-aware temporal logics to express (un)desired co-evolutions of objects. • What about the catalog? We can fi x it, or focus on veri fi cation no-matter-what-the-catalog-contains • The latter setting gives raise to a parameterised veri fi cation problem (where parameterisation is on the catalog content)
Veri fi cation Highlights • In the unbounded case, undecidability holds even forgetting the catalog in presence of tokens with binary data (the minimum we need to express co- reference) • But we have a partially sound and complete veri fi cation procedure for safety properties, with a real model checker behind the scenes: MCMT! • If we remove fresh-value injection: the procedure becomes sound and complete. • If we impose token-boundedness and require the catalog to have acyclic foreign keys: safety checking becomes decidable. • If we further restrict our attention to nets without any catalog: it is decidable to verify very sophisticated fi rst-order temporal logics (but no tool yet).
Conclusion • Need to move from case-isolated to object-centric processes • New models required, with reasoning capabilities • OCBC and COA-nets as a declarative and procedural candidate to capture object-centric processes • Interesting trade-o ff between expressiveness and reasoning capabilities
What I did not talk about • Data preparation: key problem especially when focusing on object-centric processes. See our work on OnProM and the recent OCEL standard. • Process mining tasks: discovery, conformance checking. Techniques are coming! • Commonsense reasoning and process mining. Especially with object-centric processes, what is logged is not enough to understand what is happening.
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
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
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
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 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
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?
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!
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
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
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Modeling and Reasoning over Declarative Data-Aware Processes
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Semantic DMN: Formalizing Decision Models with Domain Knowledge
byMarlon Dumas
 
PDF
Semantic DMN: Formalizing Decision Models with Domain Knowledge
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Processes and organizations - a look behind the paper wall
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
ATAED2016 Montali - Marrying data and processes: from model to event data ana...
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Strategy Synthesis for Data-Aware Dynamic Systems with Multiple Actors
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PPT
DataFlowDiagram.ppt
byChinnu Chinnu
 
From Case-Isolated to Object-Centric Processes - A Tale of two Models
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Modeling and Reasoning over Declarative Data-Aware Processes
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Semantic DMN: Formalizing Decision Models with Domain Knowledge
byMarlon Dumas
 
Semantic DMN: Formalizing Decision Models with Domain Knowledge
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Processes and organizations - a look behind the paper wall
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
ATAED2016 Montali - Marrying data and processes: from model to event data ana...
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Strategy Synthesis for Data-Aware Dynamic Systems with Multiple Actors
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
DataFlowDiagram.ppt
byChinnu Chinnu
 

Similar to From Case-Isolated to Object-Centric Processes

PDF
Jet fuelsupplychaindesign
byAlkis Vazacopoulos
 
PPTX
Lecture3-ProcessModeling1_Lecture3-ProcessModeling1.pptx
bymoatazbelkhair
 
PPT
Data flow diagram of presentation ppts.ppt
bypragyabajpayi
 
PDF
Cooking with Data and Processes
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
SocioTechnical-systems-sim
byRub Afonso
 
PPT
208-dataflowdgm.ppt
byRAJA RAY
 
PPT
data flow diagram power point presentation
bySUBHASHREEBASU5
 
PPT
208-dataflowdgm_5.ppt
byTalhaNazeer5
 
PDF
Seminar@UNIVR 31/05/2016 Montali: Data-aware business processes - balancing b...
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Unit 4- Software Engineering System Model Notes
byarvind pandey
 
PDF
13 Petri Nets (22).pdf
byNicholasielts
 
PDF
DutchMLSchool. ML for Logistics
byBigML, Inc
 
PDF
OBDA for Log Extraction in Process Mining
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Montali - DB-Nets: On The Marriage of Colored Petri Nets 
and Relational Data...
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Port Clearance Rules in PSOA RuleML: From Controlled-English Regulation to Ob...
byRuleML
 
PDF
Applying Process Mining to a Dispatching Process
byProcess mining Evangelist
 
PPT
208 dataflowdgm
byTCT
 
PPT
Data flow
byHady Saeed
 
PPT
How to Data Flow Diagram
byجلال مصطفیٰ
 
PDF
Modeling Your Applications Based on Airport Operations
byCentric Consulting
 
Jet fuelsupplychaindesign
byAlkis Vazacopoulos
 
Lecture3-ProcessModeling1_Lecture3-ProcessModeling1.pptx
bymoatazbelkhair
 
Data flow diagram of presentation ppts.ppt
bypragyabajpayi
 
Cooking with Data and Processes
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
SocioTechnical-systems-sim
byRub Afonso
 
208-dataflowdgm.ppt
byRAJA RAY
 
data flow diagram power point presentation
bySUBHASHREEBASU5
 
208-dataflowdgm_5.ppt
byTalhaNazeer5
 
Seminar@UNIVR 31/05/2016 Montali: Data-aware business processes - balancing b...
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Unit 4- Software Engineering System Model Notes
byarvind pandey
 
13 Petri Nets (22).pdf
byNicholasielts
 
DutchMLSchool. ML for Logistics
byBigML, Inc
 
OBDA for Log Extraction in Process Mining
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Montali - DB-Nets: On The Marriage of Colored Petri Nets 
and Relational Data...
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Port Clearance Rules in PSOA RuleML: From Controlled-English Regulation to Ob...
byRuleML
 
Applying Process Mining to a Dispatching Process
byProcess mining Evangelist
 
208 dataflowdgm
byTCT
 
Data flow
byHady Saeed
 
How to Data Flow Diagram
byجلال مصطفیٰ
 
Modeling Your Applications Based on Airport Operations
byCentric Consulting
 

More from Faculty of Computer Science - Free University of Bozen-Bolzano

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

Recently uploaded

PDF
MultispacecraftMeasurementsof theEvolvingGeometryof theSolarAlfvénSurface ove...
bySérgio Sacani
 
PDF
Rock Types and Formations: Igneous, Sedimentary, and Metamorphic
byarabelladiorms
 
PDF
AThickVolatileAtmosphereontheUltrahotSuper-EarthTOI-561b
bySérgio Sacani
 
PPTX
Biodiversity and stability.pptx for grade 10
byROLANARIBATO3
 
PDF
CosmologywithVoidsfromtheNancyGraceRomanSpaceTelescope
bySérgio Sacani
 
PDF
Campbell Biology 12th Edition PDF Textbook
bywosarix923
 
PPTX
Determination of Permanent Wilting Point (PWP) by Sunflower pot culture techn...
bySaurabh Upadhyay
 
PPT
1-2_SterilisationValidationQualification.ppt
byUrvashiPatni1
 
PDF
Gaussian Multiplicative Chaos: Theory, Structure, and Applications
byBob Marcus
 
PPTX
CLASSIFICATION OF LIVING ORGANISMS: THE THREE DOMAINS OF LIFE
byHOME
 
PPTX
RESTRICTION ENDONUCLEASE ,TYPES , MECHANISM , APPLICATION
byRemya M S
 
PPTX
Typical_Menstrual_Cycle introductiom .pptx
bysofiamansoor4
 
PDF
Child Development 9th Edition PDF Textbook
bywosarix923
 
PDF
Introduction of bioinformatics in hindi ( जैव सूचना विज्ञान का परिचय ) @irfan...
byWorld of Wisdom
 
PPTX
Lateral Thinking in - Managerial Skills
bycscprabh
 
PDF
glyoproteins and its types n o gpi linked pdf.pdf
byrutikbait012
 
PPT
DLC911_Feedback.ppt for grade 10 students
byROLANARIBATO3
 
PPTX
What is Blockchain Security is managed in order to protect some vital informa...
bycscprabh
 
PPTX
Anatomy of long bone and it's blood supply
byHimanshu66467
 
PDF
Class - 10 Science Book Full Concept Explanation With Last Five Years Solved ...
byDr. Juber Hawaldar
 
MultispacecraftMeasurementsof theEvolvingGeometryof theSolarAlfvénSurface ove...
bySérgio Sacani
 
Rock Types and Formations: Igneous, Sedimentary, and Metamorphic
byarabelladiorms
 
AThickVolatileAtmosphereontheUltrahotSuper-EarthTOI-561b
bySérgio Sacani
 
Biodiversity and stability.pptx for grade 10
byROLANARIBATO3
 
CosmologywithVoidsfromtheNancyGraceRomanSpaceTelescope
bySérgio Sacani
 
Campbell Biology 12th Edition PDF Textbook
bywosarix923
 
Determination of Permanent Wilting Point (PWP) by Sunflower pot culture techn...
bySaurabh Upadhyay
 
1-2_SterilisationValidationQualification.ppt
byUrvashiPatni1
 
Gaussian Multiplicative Chaos: Theory, Structure, and Applications
byBob Marcus
 
CLASSIFICATION OF LIVING ORGANISMS: THE THREE DOMAINS OF LIFE
byHOME
 
RESTRICTION ENDONUCLEASE ,TYPES , MECHANISM , APPLICATION
byRemya M S
 
Typical_Menstrual_Cycle introductiom .pptx
bysofiamansoor4
 
Child Development 9th Edition PDF Textbook
bywosarix923
 
Introduction of bioinformatics in hindi ( जैव सूचना विज्ञान का परिचय ) @irfan...
byWorld of Wisdom
 
Lateral Thinking in - Managerial Skills
bycscprabh
 
glyoproteins and its types n o gpi linked pdf.pdf
byrutikbait012
 
DLC911_Feedback.ppt for grade 10 students
byROLANARIBATO3
 
What is Blockchain Security is managed in order to protect some vital informa...
bycscprabh
 
Anatomy of long bone and it's blood supply
byHimanshu66467
 
Class - 10 Science Book Full Concept Explanation With Last Five Years Solved ...
byDr. Juber Hawaldar
 

From Case-Isolated to Object-Centric Processes

  • 1.
    From Case-Isolated to Object-CentricProcesses A Tale of Two Models Marco Montali montali@inf.unibz.it BINF, 26/05/2021 joint work with Wil van der Aalst, Alessandro Artale, Alisa Kovtunova, Silvio Ghilardi, Alessandro Gianola, Andrey Rivkin.
  • 2.
    Data and processes Achallenging, but necessary marriage! Typical choice: divide and conquer, 
 separating structural and dynamic aspects
  • 3.
    Cer. Exp. (date) Length (m) Draft (m) Capacity (TEU) Cargo (mg/cm2) 0 00 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) 3 To teach details is to bring confusion; to establish the relationship between things is to bring knowledge. M. Montessori
  • 4.
    Cer. Exp. (date) Length (m) Draft (m) Capacity (TEU) Cargo (mg/cm2) 0 00 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 Our focus: co-evolution of multiple objects
  • 5.
    Conventional notations encourage 
 “socialdistancing” 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
  • 6.
    Conventional notations encourage 
 “socialdistancing” 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
  • 7.
    Conventional notations encourage 
 “socialdistancing” 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
  • 8.
    Conventional notations encourage 
 “socialdistancing” 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
  • 9.
    Conventional notations encourage 
 “socialdistancing” 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
  • 10.
    Let’s model asimple process!
  • 11.
  • 12.
    Case-Centricity Hiring Company Business unit Business unit offer identified postoffer HR dept HR dept handle requests interview candidates offer job job offered JobOffer
  • 13.
  • 14.
    Many-to-many Candidate JobOffer 1..* * Hiring Company Business unit Businessunit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered Candidate
  • 15.
    Many-to-many Candidate JobOffer 1..* * Hiring Company Business unit Businessunit 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 (!)
  • 16.
    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
  • 17.
    Struggling with instance alignments 10A. 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])
  • 18.
    Struggling with instance alignments 10A. 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 10A. 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 10A. 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])
  • 21.
    Struggling with instance alignments 10A. 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
  • 22.
    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 

  • 23.
  • 24.
  • 25.
    50% 50% con fi gure/ deploy diagnose/ get reqs. enact/ monitor (re) design adjust ITsupport reality (knowledge) workers managers/ analysts data models process mining
  • 26.
    Discovery from EventLogs • N Event Log
  • 27.
    Discovery from EventLogs • N Event Log One case class Each event refers to one case object
  • 28.
    Discovery from EventLogs • N Event Log Discovered Process
  • 29.
  • 30.
  • 31.
    Intertwined objects time data activities Order Item Package 1 includes * * is carriedin 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?
  • 32.
    Flattening reality time data activities Order Item Package 1 includes * * is carriedin 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
  • 33.
  • 34.
    The effect of fl attening Package iscarried 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
  • 35.
    The effect of fl attening Package iscarried 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
  • 36.
    The effect of fl attening Package iscarried 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.
    Discovery? p1 p2 p3 d packagedata 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
  • 38.
    Discovery? p1 p2 p3 d packagedata 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
  • 39.
    Do we reallyneed to fl atten reality?
  • 40.
  • 41.
  • 42.
  • 43.
  • 44.
    time activities data data objects objects and relationshipsevolve over time control- fl ow 
 refers to data objects
  • 45.
    Declarative style: fi rst-order temporallogics • OCBC [___,BPM2019] Imperative style data-aware Petri nets Proclets [Fahland,PN2019] ISML [Polyvyanyy&van der Werf, CAiSE2019] catalog-nets [___,BPM2020]
  • 46.
    Declarative style: fi rst-order temporallogics • OCBC [___,BPM2019] Imperative style data-aware Petri nets Proclets [Fahland,PN2019] ISML [Polyvyanyy&van der Werf, CAiSE2019] catalog-nets [___,BPM2020]
  • 47.
    data model (UML classdiagram) Start from a data model C1 C2 R
  • 48.
    data model (UML classdiagram) Activities refer to classes C1 C2 R activities A B C
  • 49.
    data model (UML classdiagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3
  • 50.
    data model (UML classdiagram) 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 10A. 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.
    Expressing the process 10A. 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
  • 55.
    Expressing the process 10A. 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
  • 56.
    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
  • 57.
    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
  • 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 co-reference on object (V co-reference) co-reference on relation (U co-reference)
  • 59.
    Hiring Constraints C.8 Awinner 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
  • 60.
    Further Hiring Constraints EnrichingData 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
  • 61.
    Key questions 1. Whatis 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!
  • 62.
    Key answers 1. Whatis the semantics of these models? Temporal description logics 2. Can we do automated reasoning?
 Yes, upon carefully formalising models, letting the control- fl ow “disappear”.
 This gives ExpTime-completeness for reasoning tasks.
  • 63.
    Declarative style: fi rst-order temporallogics • OCBC [___,BPM2019] Imperative style data-aware Petri nets Proclets [Fahland,PN2019] ISML [Polyvyanyy&van der Werf, CAiSE2019] catalog-nets [___,BPM2020]
  • 64.
    Data components • objectID s • typed case dat a • Read-only DB (catalog) Process components • high-level Petri ne t Catalog and Object-Aware Nets
  • 65.
    Coloured places maintain(typed) case data • each data type is having a potentially in fi nite value domain and equipped with an equality predicat e • data types can be de fi ned using the Cartesian product • EX: Order=<INTo,=o> is an order type whose value domain is an in fi nite set of order identi fi ers that can be compared by equality Net Object lifecycle pool: Truck use in house: Truck go back at dest: Truck move hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti Figure 1: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. working: Order new order pay paid: Order ⌫o o o Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. 2 COA-nets: main features
  • 66.
    Fresh data generationusing dedicated -variables (like in [FI’08]) • EX: generates always (locally) unique order identi fi ers ⌫ <latexit sha1_base64="Jlo2fTg1/mzzbJ8f9iNdQEnpd2c=">AAAB7HicbZDLSgMxFIbP1Fsdb1WXboKt4KpM3OhGLLhxWcVpC+1QMmmmDc1khiQjlKHgG7hxoYhbH8iN+Daml4W2/hD4+P9zyDknTAXXxvO+ncLK6tr6RnHT3dre2d0r7R80dJIpynyaiES1QqKZ4JL5hhvBWqliJA4Fa4bD60nefGBK80Tem1HKgpj0JY84JcZafqUjs0q3VPaq3lRoGfAcyldf7uUjANS7pc9OL6FZzKShgmjdxl5qgpwow6lgY7eTaZYSOiR91rYoScx0kE+HHaMT6/RQlCj7pEFT93dHTmKtR3FoK2NiBnoxm5j/Ze3MRBdBzmWaGSbp7KMoE8gkaLI56nHFqBEjC4QqbmdFdEAUocbex7VHwIsrL0PjrIq9Kr7F5dodzFSEIziGU8BwDjW4gTr4QIHDE7zAqyOdZ+fNeZ+VFpx5zyH8kfPxA6B7kB0=</latexit> ⌫o <latexit sha1_base64="VpxPZuWw3J3QGSpkBFjp/ObT3b4=">AAAB7nicbZDLSgMxFIbPeK31VnWnm2AruCozbnRZEMFlBXuBdiiZNNOG5jIkGaEMBV/BjQtF3PZ53PkCPofp1IW2/hDy8f8n5JwTJZwZ6/uf3srq2vrGZmGruL2zu7dfOjhsGpVqQhtEcaXbETaUM0kblllO24mmWESctqLR9SxvPVBtmJL3dpzQUOCBZDEj2DqrVenKtKcqvVLZr/q50DIEP1CuHU+/EADUe6WPbl+RVFBpCcfGdAI/sWGGtWWE00mxmxqaYDLCA9pxKLGgJszydifozDl9FCvtjrQod3+/yLAwZiwiVymwHZrFbGb+l3VSG1+FGZNJaqkk84/ilCOr0Gx21GeaEsvHDjDRzPWKyBBrTKzbUNEtIVgceRmaF9XArwZ3Qbl28wi5CnACp3AOAVxCDW6hDg0gMIIneIFXL/GevTfvfV664s1vOII/8qbfgi+RnQ==</latexit> [FI’08] Rosa-Velardo F. and de Frutos-Escrig D. “Name Creation vs. Replication in Petri Net Systems”. Fundam. Inform 88(3), 2008 Net Object lifecycle pool: Truck use in house: Truck go back at dest: Truck move hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti Figure 1: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. working: Order new order pay paid: Order ⌫o o o Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. 2 COA-nets: main features
  • 67.
    Catalog is aread-only relational database • every fact has a unique ID (Primary Key) • relations can be related using Foreign Keys Product category Typ e fish … Product-truck compatibility CID Prod. Type Truck Type 15 fish refrig. truck … … … attribute types have to coincide! COA-nets: main features
  • 68.
    Transition guards [Q⋀ 𝞿 ]have two functions: • fi lter ( 𝞿 ) the fl ow of the case data (analogous to CPNs) • query (Q) the catalog and possibly inject data into the net using query results add item [ProdCat(p) ^ p 6= 0 alcohol0 ] ready: Item working: Order new order pay paid: Order ⌫o o ⌫o o o hp, oi hp, oi Figure 1: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Petri Net-Based Object-Centric Processes with Read-Only Data COA-nets: main features
  • 69.
    Transition guards [Q⋀ 𝞿 ]have two functions: • fi lter ( 𝞿 ) the fl ow of the case data (analogous to CPNs) • query (Q) the catalog and possibly inject data into the net using query results add item [ProdCat(p) ^ p 6= 0 alcohol0 ] ready: Item working: Order new order pay paid: Order ⌫o o ⌫o o o hp, oi hp, oi Figure 1: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Petri Net-Based Object-Centric Processes with Read-Only Data “injected” product category consider all product categories but ‘alcohol’ COA-nets: main features
  • 70.
    COA-nets: execution Truck TruckTruck Figure 2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. !"#$%&'()*(+*, !"-#./'(0*(+*, Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … …
  • 71.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … ⌫o 7! o233 <latexit sha1_base64="7+f5Cc+zpVJ5cs+ln19shw0YmPc=">AAACA3icbVDLSsNAFL2pr1pfUXe6CRbBVUlaQZcFNy4r2Ac0oUymk3boZCbMTIQSCm78FTcuFHHbP3Dlzr9xmnahrQeGOZxzL/feEyaMKu2631ZhbX1jc6u4XdrZ3ds/sA+PWkqkEpMmFkzITogUYZSTpqaakU4iCYpDRtrh6Gbmtx+IVFTwez1OSBCjAacRxUgbqWef+DztCT9GidLCMb8eqigT1Vpt0rPLbsXN4awSb0HK9eLnFAwaPfvL7wucxoRrzJBSXc9NdJAhqSlmZFLyU0UShEdoQLqGchQTFWT5DRPn3Ch9JxLSPK6dXP3dkaFYqXEcmsp8yWVvJv7ndVMdXQcZ5UmqCcfzQVHKHHPuLBCnTyXBmo0NQVhSs6uDh0girE1sJROCt3zyKmlVK55b8e68cv0S5ijCKZzBBXhwBXW4hQY0AcMjPMMrvFlP1ov1bn3MSwvWoucY/sCa/gBYF5lq</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
  • 72.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
  • 73.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 ⌫o 7! o45 <latexit sha1_base64="5A+IAallYCTgIQWtp+DQ42/M+w8=">AAACAnicbVDLSsNAFL3xWesr6krcBIvgqiRS0WXBjcsK9gFNCJPppB06mQkzE6GE4sZfceNCEbf6B67c+TdO0y609cAwh3Pu5d57opRRpV3321paXlldWy9tlDe3tnd27b39lhKZxKSJBROyEyFFGOWkqalmpJNKgpKIkXY0vJr47TsiFRX8Vo9SEiSoz2lMMdJGCu1Dn2eh8BOUKi0c8+uBinNROx+HdsWtugWcReLNSKVe+vwAg0Zof/k9gbOEcI0ZUqrruakOciQ1xYyMy36mSIrwEPVJ11COEqKCvDhh7JwYpefEQprHtVOovztylCg1SiJTWew4703E/7xupuPLIKc8zTTheDoozphjrp3k4fSoJFizkSEIS2p2dfAASYS1Sa1sQvDmT14krbOq51a9G69Sr8EUJTiCYzgFDy6gDtfQgCZguIdHeIYX68F6sl6tt2npkjXrOYA/sN5/AOIhmTE=</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
  • 74.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
  • 75.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- o 7! o45 <latexit sha1_base64="Q+h2I9D+v8dR8mfuE7LWxc6ER4k=">AAAB/nicbVDLSgMxFL3js9bXqLhyEyyCqzIjFd1ZcOOygn1AO5RMmmlDM8mQZIQyFPyN7nTjQhG3+hvu/BvTx0JbL4QczrmXe+4JE8608bxvZ2l5ZXVtPbeR39za3tl19/ZrWqaK0CqRXKpGiDXlTNCqYYbTRqIojkNO62H/eqzX76nSTIo7M0hoEOOuYBEj2Fiq7R7KVowTbSSyv+npKJOl82HbLXhFb1JoEfgzULj6HI0eAaDSdr9aHUnSmApDONa66XuJCTKsDCOcDvOtVNMEkz7u0qaFAsdUB9nE/hCdWKaDIqnsEwZN2N8TGY61HsSh7Zx4nNfG5H9aMzXRZZAxkaSGCjJdFKUc2WvHWaAOU5QYPrAAE8WsV0R6WGFibGJ5G4I/f/IiqJ0Vfa/o3/qFcgmmlYMjOIZT8OECynADFagCgQye4AVenQfn2Xlz3qetS85s5gD+lPPxAwWkmGQ=</latexit> p 7! fish <latexit sha1_base64="yF736hH/nj+oZ4l43YcY80kLqVI=">AAAB/nicbVDLSgMxFL3js9ZHR8WVm2ARXJUZEXRnwY3LCvYBbSmZNNOGZpKQZIQyFPwVNy4Ucet3uPMT/AvTaRfaeiDkcM695OREijNjg+DLW1ldW9/YLGwVt3d290r+/kHDyFQTWieSS92KsKGcCVq3zHLaUpriJOK0GY1upn7zgWrDpLi3Y0W7CR4IFjOCrZN6/pHqJFgZK91lhybOYmaGk55fDipBDrRMwjkpV0vf1wgAaj3/s9OXJE2osIRjY9phoGw3w9oywumk2EkNVZiM8IC2HRU4oaab5fEn6NQpfRRL7Y6wKFd/b2Q4MWacRG4yD7noTcX/vHZq46tuxoRKLRVk9lCccmQlmnaB+kxTYvnYEUw0c1kRGWKNiXWNFV0J4eKXl0njvBIGlfAuLFcvYIYCHMMJnEEIl1CFW6hBHQhk8AQv8Oo9es/em/c+G13x5juH8Afexw96ypfk</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
  • 76.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- !4567'13-, COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*,
  • 77.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- o 7! o45 <latexit sha1_base64="Q+h2I9D+v8dR8mfuE7LWxc6ER4k=">AAAB/nicbVDLSgMxFL3js9bXqLhyEyyCqzIjFd1ZcOOygn1AO5RMmmlDM8mQZIQyFPyN7nTjQhG3+hvu/BvTx0JbL4QczrmXe+4JE8608bxvZ2l5ZXVtPbeR39za3tl19/ZrWqaK0CqRXKpGiDXlTNCqYYbTRqIojkNO62H/eqzX76nSTIo7M0hoEOOuYBEj2Fiq7R7KVowTbSSyv+npKJOl82HbLXhFb1JoEfgzULj6HI0eAaDSdr9aHUnSmApDONa66XuJCTKsDCOcDvOtVNMEkz7u0qaFAsdUB9nE/hCdWKaDIqnsEwZN2N8TGY61HsSh7Zx4nNfG5H9aMzXRZZAxkaSGCjJdFKUc2WvHWaAOU5QYPrAAE8WsV0R6WGFibGJ5G4I/f/IiqJ0Vfa/o3/qFcgmmlYMjOIZT8OECynADFagCgQye4AVenQfn2Xlz3qetS85s5gD+lPPxAwWkmGQ=</latexit> p 7! fish <latexit sha1_base64="yF736hH/nj+oZ4l43YcY80kLqVI=">AAAB/nicbVDLSgMxFL3js9ZHR8WVm2ARXJUZEXRnwY3LCvYBbSmZNNOGZpKQZIQyFPwVNy4Ucet3uPMT/AvTaRfaeiDkcM695OREijNjg+DLW1ldW9/YLGwVt3d290r+/kHDyFQTWieSS92KsKGcCVq3zHLaUpriJOK0GY1upn7zgWrDpLi3Y0W7CR4IFjOCrZN6/pHqJFgZK91lhybOYmaGk55fDipBDrRMwjkpV0vf1wgAaj3/s9OXJE2osIRjY9phoGw3w9oywumk2EkNVZiM8IC2HRU4oaab5fEn6NQpfRRL7Y6wKFd/b2Q4MWacRG4yD7noTcX/vHZq46tuxoRKLRVk9lCccmQlmnaB+kxTYvnYEUw0c1kRGWKNiXWNFV0J4eKXl0njvBIGlfAuLFcvYIYCHMMJnEEIl1CFW6hBHQhk8AQv8Oo9es/em/c+G13x5juH8Afexw96ypfk</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-,
  • 78.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-, !4567'13-,
  • 79.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- o 7! o45 <latexit sha1_base64="Q+h2I9D+v8dR8mfuE7LWxc6ER4k=">AAAB/nicbVDLSgMxFL3js9bXqLhyEyyCqzIjFd1ZcOOygn1AO5RMmmlDM8mQZIQyFPyN7nTjQhG3+hvu/BvTx0JbL4QczrmXe+4JE8608bxvZ2l5ZXVtPbeR39za3tl19/ZrWqaK0CqRXKpGiDXlTNCqYYbTRqIojkNO62H/eqzX76nSTIo7M0hoEOOuYBEj2Fiq7R7KVowTbSSyv+npKJOl82HbLXhFb1JoEfgzULj6HI0eAaDSdr9aHUnSmApDONa66XuJCTKsDCOcDvOtVNMEkz7u0qaFAsdUB9nE/hCdWKaDIqnsEwZN2N8TGY61HsSh7Zx4nNfG5H9aMzXRZZAxkaSGCjJdFKUc2WvHWaAOU5QYPrAAE8WsV0R6WGFibGJ5G4I/f/IiqJ0Vfa/o3/qFcgmmlYMjOIZT8OECynADFagCgQye4AVenQfn2Xlz3qetS85s5gD+lPPxAwWkmGQ=</latexit> p 7! fish <latexit sha1_base64="yF736hH/nj+oZ4l43YcY80kLqVI=">AAAB/nicbVDLSgMxFL3js9ZHR8WVm2ARXJUZEXRnwY3LCvYBbSmZNNOGZpKQZIQyFPwVNy4Ucet3uPMT/AvTaRfaeiDkcM695OREijNjg+DLW1ldW9/YLGwVt3d290r+/kHDyFQTWieSS92KsKGcCVq3zHLaUpriJOK0GY1upn7zgWrDpLi3Y0W7CR4IFjOCrZN6/pHqJFgZK91lhybOYmaGk55fDipBDrRMwjkpV0vf1wgAaj3/s9OXJE2osIRjY9phoGw3w9oywumk2EkNVZiM8IC2HRU4oaab5fEn6NQpfRRL7Y6wKFd/b2Q4MWacRG4yD7noTcX/vHZq46tuxoRKLRVk9lCccmQlmnaB+kxTYvnYEUw0c1kRGWKNiXWNFV0J4eKXl0njvBIGlfAuLFcvYIYCHMMJnEEIl1CFW6hBHQhk8AQv8Oo9es/em/c+G13x5juH8Afexw96ypfk</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-, !4567'13-,
  • 80.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-, !4567'13-,
  • 81.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- o 7! o45 <latexit sha1_base64="Q+h2I9D+v8dR8mfuE7LWxc6ER4k=">AAAB/nicbVDLSgMxFL3js9bXqLhyEyyCqzIjFd1ZcOOygn1AO5RMmmlDM8mQZIQyFPyN7nTjQhG3+hvu/BvTx0JbL4QczrmXe+4JE8608bxvZ2l5ZXVtPbeR39za3tl19/ZrWqaK0CqRXKpGiDXlTNCqYYbTRqIojkNO62H/eqzX76nSTIo7M0hoEOOuYBEj2Fiq7R7KVowTbSSyv+npKJOl82HbLXhFb1JoEfgzULj6HI0eAaDSdr9aHUnSmApDONa66XuJCTKsDCOcDvOtVNMEkz7u0qaFAsdUB9nE/hCdWKaDIqnsEwZN2N8TGY61HsSh7Zx4nNfG5H9aMzXRZZAxkaSGCjJdFKUc2WvHWaAOU5QYPrAAE8WsV0R6WGFibGJ5G4I/f/IiqJ0Vfa/o3/qFcgmmlYMjOIZT8OECynADFagCgQye4AVenQfn2Xlz3qetS85s5gD+lPPxAwWkmGQ=</latexit> n 7! T52YN <latexit sha1_base64="TIGsAcai7alWVaH1QYFY6+BN218=">AAACAHicbVDLSsNAFL2pr1pfURcu3ASL4KokRdGdBTeupEJf0oYymU7aoZNJmJkIJWTjX3QnuHGhiEv9DHf+jdO0C209MMzhnHu59x4vYlQq2/42ckvLK6tr+fXCxubW9o65u9eQYSwwqeOQhaLlIUkY5aSuqGKkFQmCAo+Rpje8mvjNeyIkDXlNjSLiBqjPqU8xUlrqmge8E6BIqtDSvxpIP6mdle9u0q5ZtEt2BmuRODNSvPwYjx8BoNo1vzq9EMcB4QozJGXbsSPlJkgoihlJC51YkgjhIeqTtqYcBUS6SXZAah1rpWf5odCPKytTf3ckKJByFHi6Mtty3puI/3ntWPkXbkJ5FCvC8XSQHzNL3ztJw+pRQbBiI00QFlTvauEBEggrnVlBh+DMn7xIGuWSY5ecW6dYOYUp8nAIR3ACDpxDBa6hCnXAkMITvMCr8WA8G2/G+7Q0Z8x69uEPjM8fL2+ZAQ==</latexit> p 7! fish <latexit sha1_base64="yF736hH/nj+oZ4l43YcY80kLqVI=">AAAB/nicbVDLSgMxFL3js9ZHR8WVm2ARXJUZEXRnwY3LCvYBbSmZNNOGZpKQZIQyFPwVNy4Ucet3uPMT/AvTaRfaeiDkcM695OREijNjg+DLW1ldW9/YLGwVt3d290r+/kHDyFQTWieSS92KsKGcCVq3zHLaUpriJOK0GY1upn7zgWrDpLi3Y0W7CR4IFjOCrZN6/pHqJFgZK91lhybOYmaGk55fDipBDrRMwjkpV0vf1wgAaj3/s9OXJE2osIRjY9phoGw3w9oywumk2EkNVZiM8IC2HRU4oaab5fEn6NQpfRRL7Y6wKFd/b2Q4MWacRG4yD7noTcX/vHZq46tuxoRKLRVk9lCccmQlmnaB+kxTYvnYEUw0c1kRGWKNiXWNFV0J4eKXl0njvBIGlfAuLFcvYIYCHMMJnEEIl1CFW6hBHQhk8AQv8Oo9es/em/c+G13x5juH8Afexw96ypfk</latexit> t 7! r.t. <latexit sha1_base64="UC25E9sEdsQmQ3/NQfToUWKMWaE=">AAAB/nicbVDLSsNAFL3xWesrKq7cBIvgKiQi6M6CG5cV7APaUibTSTt0MgkzN0IJBX+jO924UMSt/oY7/8Zp2oW2HhjmcM69zJkTJIJr9Lxva2l5ZXVtvbBR3Nza3tm19/ZrOk4VZVUai1g1AqKZ4JJVkaNgjUQxEgWC1YPB9cSv3zOleSzvcJiwdkR6koecEjRSxz7EVkQSjbG5sK/DTLnojjp2yXO9HM4i8WekdPU5Hj8CQKVjf7W6MU0jJpEKonXT9xJsZ0Qhp4KNiq1Us4TQAemxpqGSREy3szz+yDkxStcJY2WORCdXf29kJNJ6GAVmMg85703E/7xmiuFlO+MySZFJOn0oTIWDsTPpwulyxSiKoSGEKm6yOrRPFKFoGiuaEvz5Ly+S2pnre65/65fK5zBFAY7gGE7Bhwsoww1UoAoUMniCF3i1Hqxn6816n44uWbOdA/gD6+MHgRyYsw==</latexit> COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-, !4567'13-,
  • 82.
    Truck Truck Truck Figure2: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. add item [ProdCat(p)] rem ready: Item in house: Truck load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate working: Order new order pay paid: Order hp,oi hp, oi hm, ti hp,o,mi hp,oi hp, o, mi ⌫o o o o hp, oi hp, oi o Figure 3: A COA-net (its catalog is in Example ??). In the picture, Item and Truck are compact repre- sentations for ProdType ⇥ Order and Plate ⇥ TruckType respectively. The top blue part refers to orders, the central orange part to items, and the bottom violet part to delivery trucks. Product category books kitchen fish … Product-truck compatibility 120 books box truck 432 kitchen box truck 15 fish refrig. truck … … … 1#22 13- !4567'13-'"-#./, COA-nets: execution !"#$%&'()*(+*, !"-#./'(0*(+*, !4567'13-,
  • 83.
    COA-nets: modelling highlights pool: Truck use inhouse: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o
  • 84.
    COA-nets: modelling highlights pool: Truck use inhouse: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o Create unboundedly many orders (by generating fresh IDs)
  • 85.
    COA-nets: modelling highlights pool: Truck use inhouse: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o a pattern for creating objects on the many side of a 1-to-many relation
  • 86.
    COA-nets: modelling highlights pool: Truck use inhouse: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o A PN-version of a SELECT-PROJECT- JOIN SQL query with fi lters
  • 87.
    COA-nets: modelling highlights pool: Truck use inhouse: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o • create items using the catalog and IDs of owning order s ➡ multiple items with the same product typ e • not needed to track their evolution (no explicit ID) as items are never on the 1-side of some 1-to-many relation
  • 88.
    COA-nets: modelling highlights pool: Truck use inhouse: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o • when loaded on a truck, an item will reference its plate number (i.e., ID) • create items using the catalog and IDs of owning order s ➡ multiple items with the same product typ e • not needed to track their evolution (no explicit ID) as items are never on the 1-side of some 1-to-many relation
  • 89.
    COA-nets: modelling highlights pool: Truck use inhouse: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o • trucks as resources ( fi xed in pool ) • can change their stat e • cannot be destroyed
  • 90.
    COA-nets: modelling highlights pool: Truck use inhouse: Truck go back drive at dest: Truck move add item [ProdCat(p)] rem ready: Item load [9c.Comp(c, p, t)] drop in truck: Item ⇥ Plate deliver delivered: Item working: Order new order pay paid: Order hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hm, ti hp,oi hp, oi hm, ti hp,o,m i hp,oi hm, ti hp, o, mi hp, o, mi hp, o, mi hm, ti hp, oi ⌫o o o o hp, oi hp, oi o nondeterministic synch.: items can synchronise with a referenced truck, but the truck can decide to go back and leave some items undelivered
  • 91.
    Reasoning on COA-nets •Typical Petri nets properties (reachability, coverability, soundness) in their “data-aware” version. • More sophisticated data-aware temporal logics to express (un)desired co-evolutions of objects. • What about the catalog? We can fi x it, or focus on veri fi cation no-matter-what-the-catalog-contains • The latter setting gives raise to a parameterised veri fi cation problem (where parameterisation is on the catalog content)
  • 92.
    Veri fi cation Highlights • Inthe unbounded case, undecidability holds even forgetting the catalog in presence of tokens with binary data (the minimum we need to express co- reference) • But we have a partially sound and complete veri fi cation procedure for safety properties, with a real model checker behind the scenes: MCMT! • If we remove fresh-value injection: the procedure becomes sound and complete. • If we impose token-boundedness and require the catalog to have acyclic foreign keys: safety checking becomes decidable. • If we further restrict our attention to nets without any catalog: it is decidable to verify very sophisticated fi rst-order temporal logics (but no tool yet).
  • 93.
    Conclusion • Need tomove from case-isolated to object-centric processes • New models required, with reasoning capabilities • OCBC and COA-nets as a declarative and procedural candidate to capture object-centric processes • Interesting trade-o ff between expressiveness and reasoning capabilities
  • 94.
    What I didnot talk about • Data preparation: key problem especially when focusing on object-centric processes. See our work on OnProM and the recent OCEL standard. • Process mining tasks: discovery, conformance checking. Techniques are coming! • Commonsense reasoning and process mining. Especially with object-centric processes, what is logged is not enough to understand what is happening.
  • 95.
    V coreference onresponse 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
  • 96.
    V coreference onresponse 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
  • 97.
    U coreference onresponse 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
  • 98.
    U coreference onresponse 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
  • 99.
    Which Route? A1 A2 O R1R2 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
  • 100.
    Which Route? A1 A2 O R1R2 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
  • 101.
    Which Route? A1 A2 O R1R2 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
  • 102.
  • 103.
  • 104.
    Activities Fade Away A1A2 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
  • 105.
    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
  • 106.
    Temporal Description Logics Familyof 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.
  • 107.
    Temporal Description Logics OBDAfor 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
  • 108.
    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
  • 109.
    Temporal Description Logics Familyof 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.
  • 110.
    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
  • 111.
    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
  • 112.
    Temporal Description Logics Combinestatic 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
  • 113.
    Combining multiple dimensionsis dangerous: undecidability around the corner! Can we formalize OCBC in a well-behaved temporal DL?
  • 114.
    Question A1 A2 O R1 R2 Everytime 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!
  • 115.
    Response Example Every timean 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
  • 116.
    A glimpse ofthe 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
  • 117.
    b’:B R2 A glimpse ofthe 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
  • 118.
    A glimpse ofthe 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
  • 119.
    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?
  • 120.
    Implied Constraints 
 (Hidden Dependencies) EnrichingData 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:
  • 121.
    Complexity considerations Consistency, deadactivity 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
  • 122.
    Conclusion OCBC: a declarativeapproach
 to elegantly capture processes
 with co-evolving objects Formal logic-based semantics in a temporal DL that enables automated reasoning
  • 123.
    Rigid roles? Monitoring
 (closed-open reasoning) Discoveryof OCBC fragments 
 and other (imperative) models with data correlations
 Baseline: [Li et al,BIS2017], [Berti&vanderAalst,Arxiv2020],
 [Lu et al, IEEETSC2015] Future work