SlideShare a Scribd company logo

From Case-Isolated to Object-Centric Processes - A Tale of two Models

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

The document discusses challenges with modeling processes that involve multiple interacting objects. Conventional process modeling approaches encourage separating objects and focusing on one object type per process, which can lead to issues when objects interact. The document proposes modeling objects as first-class citizens and capturing relationships between objects to better represent real-world processes where objects corelate and influence each other. It provides examples of how conventional case-centric modeling can struggle to accurately capture a hiring process that involves interacting candidate, application, job offer and other objects.

Science
Related topics:
Business Processes
1 of 123
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
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
Modeling and Reasoning over Declarative Data-Aware Processes
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
From Case-Isolated to Object-Centric Processes
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
M Bridge 12 An Algorithm to Reduce Container Reposition Cost through Virtual.pdf
CINEC Campus
 
PDF
M Bridge 6 CASA 2019 July - An Algorithm to Reduces Container Reposition Cost...
CINEC Campus
 
PPTX
Transportation, Transshipment and Assignment Problem.pptx
KiranMittal7
 
PDF
Processes and organizations - a look behind the paper wall
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Business Model That Presents ( Operation Process...
Carmen Martin
 
PDF
Semantic DMN: Formalizing Decision Models with Domain Knowledge
Marlon Dumas
 
Modeling and Reasoning over Declarative Data-Aware Processes
Faculty of Computer Science - Free University of Bozen-Bolzano
 
From Case-Isolated to Object-Centric Processes
Faculty of Computer Science - Free University of Bozen-Bolzano
 
M Bridge 12 An Algorithm to Reduce Container Reposition Cost through Virtual.pdf
CINEC Campus
 
M Bridge 6 CASA 2019 July - An Algorithm to Reduces Container Reposition Cost...
CINEC Campus
 
Transportation, Transshipment and Assignment Problem.pptx
KiranMittal7
 
Processes and organizations - a look behind the paper wall
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Business Model That Presents ( Operation Process...
Carmen Martin
 
Semantic DMN: Formalizing Decision Models with Domain Knowledge
Marlon Dumas
 

Similar to From Case-Isolated to Object-Centric Processes - A Tale of two Models (15)

PDF
Semantic DMN: Formalizing Decision Models with Domain Knowledge
Faculty of Computer Science - Free University of Bozen-Bolzano
 
PPT
Assign transportation
Kinshook Chaturvedi
 
PDF
Swot Analysis Of Swissair
Veronica Smith
 
PPT
SCM: Fedex
Amit Kumar
 
PDF
Container Market Literature Review
Mary Stevenson
 
DOCX
Report Normalization documents
Wakil Kumar
 
PDF
Crossdocking Insights from a Third Party Logistics Firm in Turkey
ertekg
 
PDF
Crossdocking Insights from a Third Party Logistics Firm in Turkey
Gurdal Ertek
 
DOCX
Script for presentation 54030072
Yuyie Pharita
 
PDF
Academic Summary Example. A Summary Of A
Alison Carias
 
PDF
Nt1320 Unit 4
Nicolle Dammann
 
PDF
Edgar Allan Poe Thesis Statement Essay
Molly Wood
 
PDF
Port Economics 1st Edition Cullinane K Ed Talley Wk Ed
akuoczoch
 
PPTX
4 Tranportation Proplem Final 1 special notes
aloksinghtanwar7720
 
PDF
Strategy Synthesis for Data-Aware Dynamic Systems with Multiple Actors
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Semantic DMN: Formalizing Decision Models with Domain Knowledge
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Assign transportation
Kinshook Chaturvedi
 
Swot Analysis Of Swissair
Veronica Smith
 
SCM: Fedex
Amit Kumar
 
Container Market Literature Review
Mary Stevenson
 
Report Normalization documents
Wakil Kumar
 
Crossdocking Insights from a Third Party Logistics Firm in Turkey
ertekg
 
Crossdocking Insights from a Third Party Logistics Firm in Turkey
Gurdal Ertek
 
Script for presentation 54030072
Yuyie Pharita
 
Academic Summary Example. A Summary Of A
Alison Carias
 
Nt1320 Unit 4
Nicolle Dammann
 
Edgar Allan Poe Thesis Statement Essay
Molly Wood
 
Port Economics 1st Edition Cullinane K Ed Talley Wk Ed
akuoczoch
 
4 Tranportation Proplem Final 1 special notes
aloksinghtanwar7720
 
Strategy Synthesis for Data-Aware Dynamic Systems with Multiple Actors
Faculty of Computer Science - Free University of Bozen-Bolzano
 
Ad

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

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

Recently uploaded (20)

PDF
IFIT3 RNA-binding activity primores influenza A viruz infection and translati...
saracelre
 
PPTX
EPIDURAL ANESTHESIA ANATOMY AND PHYSIOLOGY.pptx
PrabakaranMP1
 
PPTX
GEN. BIO 1 - CELL TYPES & CELL MODIFICATIONS
breeysal7
 
PPTX
Introduction to Fisheries Biotechnology_Lesson 1.pptx
Esther Pongcol
 
PDF
Placing the Near-Earth Object Impact Probability in Context
Sérgio Sacani
 
PDF
Formation of Supersonic Turbulence in the Primordial Star-forming Cloud
Sérgio Sacani
 
PPTX
The KM-GBF monitoring framework – status & key messages.pptx
pensoftservices
 
PPTX
Derivatives of integument scales, beaks, horns,.pptx
Dr Showkat Ahmad Wani
 
PPTX
DRUG THERAPY FOR SHOCK gjjjgfhhhhh.pptx.
vipvivek704
 
PPTX
2Systematics of Living Organisms t-.pptx
RachanaT6
 
PPTX
G5Q1W8 PPT SCIENCE.pptx 2025-2026 GRADE 5
Rodel Gordzkie
 
PPTX
ECG_Course_Presentation د.محمد صقران ppt
lelouchml1995
 
PPTX
Introduction to Cardiovascular system_structure and functions-1
muralinath2
 
PDF
The scientific heritage No 166 (166) (2025)
The scientific heritage
 
PPTX
Microbiology with diagram medical studies .pptx
mohammedabbusiddiq
 
PPTX
7. General Toxicologyfor clinical phrmacy.pptx
faysalphr
 
PDF
Biophysics 2.pdffffffffffffffffffffffffff
MiraMusleh
 
PDF
HPLC-PPT.docx high performance liquid chromatography
darshanambiga1633
 
PPTX
BIOMOLECULES PPT........................
vachieagrawal1221
 
PDF
An interstellar mission to test astrophysical black holes
Sérgio Sacani
 
IFIT3 RNA-binding activity primores influenza A viruz infection and translati...
saracelre
 
EPIDURAL ANESTHESIA ANATOMY AND PHYSIOLOGY.pptx
PrabakaranMP1
 
GEN. BIO 1 - CELL TYPES & CELL MODIFICATIONS
breeysal7
 
Introduction to Fisheries Biotechnology_Lesson 1.pptx
Esther Pongcol
 
Placing the Near-Earth Object Impact Probability in Context
Sérgio Sacani
 
Formation of Supersonic Turbulence in the Primordial Star-forming Cloud
Sérgio Sacani
 
The KM-GBF monitoring framework – status & key messages.pptx
pensoftservices
 
Derivatives of integument scales, beaks, horns,.pptx
Dr Showkat Ahmad Wani
 
DRUG THERAPY FOR SHOCK gjjjgfhhhhh.pptx.
vipvivek704
 
2Systematics of Living Organisms t-.pptx
RachanaT6
 
G5Q1W8 PPT SCIENCE.pptx 2025-2026 GRADE 5
Rodel Gordzkie
 
ECG_Course_Presentation د.محمد صقران ppt
lelouchml1995
 
Introduction to Cardiovascular system_structure and functions-1
muralinath2
 
The scientific heritage No 166 (166) (2025)
The scientific heritage
 
Microbiology with diagram medical studies .pptx
mohammedabbusiddiq
 
7. General Toxicologyfor clinical phrmacy.pptx
faysalphr
 
Biophysics 2.pdffffffffffffffffffffffffff
MiraMusleh
 
HPLC-PPT.docx high performance liquid chromatography
darshanambiga1633
 
BIOMOLECULES PPT........................
vachieagrawal1221
 
An interstellar mission to test astrophysical black holes
Sérgio Sacani
 

From Case-Isolated to Object-Centric Processes - A Tale of two Models

  • 1. 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.
  • 2. Data and processes A challenging, 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 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
  • 4. Cer. Exp. (date) Length (m) Draft (m) Capacity (TEU) Cargo (mg/cm2) 0 0 0 0 0 Enter y, n U Ship Clearance  today > today < 260 < 10 < 1000 > today < 260 < 10 1000 > today < 260 [10,12] < 4000  0.75 > today < 260 [10,12] < 4000 > 0.75 > today [260,320) (10,13] < 6000  0.5 > today [260,320) (10,13] < 6000 > 0.5 > today [320,400) 13 > 4000  0.25 > today [320,400) 13 > 4000 > 0.25 n y n y n y n y n 1 2 3 4 5 6 7 8 9 Table 1: DMN representation of the ship clearance decision of Figure 1b Enter Length (m) Cargo (mg/cm2) y,n 0 0 Refuel Area none, indoor, outdoor U Refuel area determination n y  350 y > 350  0.3 y > 350 > 0.3 none indoor indoor outdoor 1 2 3 4 Table 2: DMN representation of the refuel area determination decision of Figure 1b er their corresponding datatypes. In Table 1, the input attributes are: (i) the certificate expira- on date, (ii) the length, (iii) the size, (iv) the capacity, and (v) the amount of cargo residuals of ship. Such attributes are nonnegative real numbers; this is captured by typing them as reals, ding restriction “ 0” as facet. The rightmost, red cell represents the output attribute. In both ses, there is only one output attribute, of type string. The cell below enumerates the possible tput values produced by the decision table, in descending priority order. If a default output is fined, it is underlined. This is the case for the none string in Table 2. Every other row models a rule. The intuitive interpretation of such rules relies on the usual f . ..then ...” pattern. For example, the first rule of Table 1 states that, if the certificate of the ip is expired, then the ship cannot enter the port, that is, the enter output attribute is set to n egardless of the other input attributes). The second rule, instead, states that, if the ship has a lid certificate, a length shorter than 260 m, a draft smaller than 10 m, and a capacity smaller an 1000 TEU, then the ship is allowed to enter the port (regardless of the cargo residuals it rries). Other rules are interpreted similarly. Ship id-code name Certi fi cate exp-date Harbor location Attempt when outcome tried entering into owns 1 0..1 * * receive entrance request record ship info inspect ship ship id acquire certificate record cargo residuals record exp. date cargo residuals certificate exp. date decice clearance enter refuel area enter? send refusal send fuel area info open dock N Y ship type (short name) 4 To teach details is to bring confusion; to establish the relationship between things is to bring knowledge. M. Montessori Our focus: co-evolution of multiple objects
  • 5. 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
  • 6. Conventional notations encourage “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process
  • 7. Conventional notations encourage “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process order 1
  • 8. Conventional notations encourage “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process order 2 order 1
  • 9. Conventional notations encourage “social distancing” on objects Two main commitments… • Each process focuses on a single object type (case). • Each instance of the process works on a single case object. time data activities order package process process order 1 order 2 package 34
  • 10. Let’s model a simple process!
  • 12. 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
  • 14. 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
  • 15. Many-to-many Candidate JobOffer 1..* * Hiring Company Business unit Business unit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered Candidate ?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 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])
  • 18. Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 19. Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 20. Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 21. Struggling with instance alignments 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 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
  • 25. 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
  • 26. Discovery from Event Logs • N Event Log
  • 27. Discovery from Event Logs • N Event Log One case class Each event refers to one case object
  • 28. Discovery from Event Logs • N Event Log Discovered Process
  • 31. 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?
  • 32. 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
  • 34. 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
  • 35. The effect of fl attening Package is carried in 1 p1 p2 p3 Figure 1: Structure of order, item, and package data objects in an order-to-delivery sce- nario whereuv items from di↵erent orders are carried in several packages event log for orders timestamp overall log order o1 order o2 order o3 2019-09-22 10:00:00 create order o1 create order 2019-09-22 10:01:00 add item i1,1 to order o1 add item 2019-09-23 09:20:00 create order o2 create order 2019-09-23 09:34:00 add item i2,1 to order o2 add item 2019-09-23 11:33:00 create order o3 create order 2019-09-23 11:40:00 add item i3,1 to order o3 add item 2019-09-23 12:27:00 pay order o3 pay order 2019-09-23 12:32:00 add item i1,2 to order o1 add item 2019-09-23 13:03:00 pay order o1 pay order 2019-09-23 14:34:00 load item i1,1 into package p1 load item 2019-09-23 14:45:00 add item i2,2 to order o2 add item 2019-09-23 14:51:00 load item i3,1 into package p1 load item 2019-09-23 15:12:00 add item i2,3 to order o2 add item 2019-09-23 15:41:00 pay order o2 pay order 2019-09-23 16:23:00 load item i2,1 into package p2 load item 2019-09-23 16:29:00 load item i1,2 into package p2 load item 2019-09-23 16:33:00 load item i2,2 into package p2 load item 2019-09-23 17:01:00 send package p1 send package send package 2019-09-24 06:38:00 send package p2 send package send package 2019-09-24 07:33:00 load item i2,3 into package p3 load item 2019-09-24 08:46:00 send package p3 send package 2019-09-24 16:21:00 deliver package p1 deliver package deliver package 2019-09-24 17:32:00 deliver package p2 deliver package deliver package 2019-09-24 18:52:00 deliver package p3 deliver package 2019-09-24 18:57:00 accept delivery p3 accept delivery 2019-09-25 08:30:00 deliver package p1 deliver package deliver package 2019-09-25 08:32:00 accept delivery p1 accept delivery accept delivery 2019-09-25 09:55:00 deliver package p2 deliver package deliver package 2019-09-25 17:11:00 deliver package p2 deliver package deliver package 2019-09-25 17:12:00 accept delivery p2 accept delivery accept delivery orders
  • 36. The effect of fl attening Package is carried in 1 p1 p2 p3 Figure 1: Structure of order, item, and package data objects in an order-to-delivery sce- nario whereuv items from di↵erent orders are carried in several packages event log for orders timestamp overall log order o1 order o2 order o3 2019-09-22 10:00:00 create order o1 create order 2019-09-22 10:01:00 add item i1,1 to order o1 add item 2019-09-23 09:20:00 create order o2 create order 2019-09-23 09:34:00 add item i2,1 to order o2 add item 2019-09-23 11:33:00 create order o3 create order 2019-09-23 11:40:00 add item i3,1 to order o3 add item 2019-09-23 12:27:00 pay order o3 pay order 2019-09-23 12:32:00 add item i1,2 to order o1 add item 2019-09-23 13:03:00 pay order o1 pay order 2019-09-23 14:34:00 load item i1,1 into package p1 load item 2019-09-23 14:45:00 add item i2,2 to order o2 add item 2019-09-23 14:51:00 load item i3,1 into package p1 load item 2019-09-23 15:12:00 add item i2,3 to order o2 add item 2019-09-23 15:41:00 pay order o2 pay order 2019-09-23 16:23:00 load item i2,1 into package p2 load item 2019-09-23 16:29:00 load item i1,2 into package p2 load item 2019-09-23 16:33:00 load item i2,2 into package p2 load item 2019-09-23 17:01:00 send package p1 send package send package 2019-09-24 06:38:00 send package p2 send package send package 2019-09-24 07:33:00 load item i2,3 into package p3 load item 2019-09-24 08:46:00 send package p3 send package 2019-09-24 16:21:00 deliver package p1 deliver package deliver package 2019-09-24 17:32:00 deliver package p2 deliver package deliver package 2019-09-24 18:52:00 deliver package p3 deliver package 2019-09-24 18:57:00 accept delivery p3 accept delivery 2019-09-25 08:30:00 deliver package p1 deliver package deliver package 2019-09-25 08:32:00 accept delivery p1 accept delivery accept delivery 2019-09-25 09:55:00 deliver package p2 deliver package deliver package 2019-09-25 17:11:00 deliver package p2 deliver package deliver package 2019-09-25 17:12:00 accept delivery p2 accept delivery accept delivery orders
  • 37. 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
  • 38. Discovery? p1 p2 p3 d package data objects in an order-to-delivery sce- ders are carried in several packages event log for orders order o1 order o2 order o3 create order add item create order add item create order add item pay order add item pay order load item add item load item add item pay order load item load item load item send package send package send package send package load item send package deliver package deliver package deliver package deliver package deliver package accept delivery deliver package deliver package accept delivery accept delivery deliver package deliver package deliver package deliver package accept delivery accept delivery to discover a process model th 3 2 4 2 3 3 1 1 3 3 6 5 3 3 create order 3 add item 6 pay order 3 load item 6 send package 5 deliver package 11 accept delivery 5 raw flat case this trac orde flat dire or t orde Two 1. R o s c r i 2. S a o g s i o d i c a c The cove form pro dire the der mis Thi age non-existing loop wrong statistics
  • 39. Do we really need to fl atten reality?
  • 44. time activities data data objects objects and relationships evolve over time control- fl ow refers to data objects
  • 45. Declarative style: fi rst-order temporal logics • OCBC [___,BPM2019] Imperative style data-aware Petri nets Proclets [Fahland,PN2019] ISML [Polyvyanyy&van der Werf, CAiSE2019] catalog-nets [___,BPM2020]
  • 46. 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]
  • 47. data model (UML class diagram) Start from a data model C1 C2 R
  • 48. data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C
  • 49. data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3
  • 50. data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3 “generating”
  • 51. Hiring Example 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner which instances of tasks are related by the constraint depending on manipulate. In particular, the relevant constraints for our job hiring example are: C.1 The register data task is about a Person. C.2 A Job Offer is created by executing the post offer task. C.3 A Job Offer is closed by determining the winner. C.4 A Job Offer is stopped by canceling the hiring. Enriching Data Models with Behavioral Co C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data a date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least o responding to that Job Offer has been previously marked as el C.9 For each Application responding to a Job Offer, if the Applica as eligible then a winner must be finally determined for that this is done only once for that Job Offer. C.10 When a winner is determined for a Job Offer, Applications res
  • 52. Hiring Example 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner which instances of tasks are related by the constraint depending on manipulate. In particular, the relevant constraints for our job hiring example are: C.1 The register data task is about a Person. C.2 A Job Offer is created by executing the post offer task. C.3 A Job Offer is closed by determining the winner. C.4 A Job Offer is stopped by canceling the hiring. Enriching Data Models with Behavioral Co C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data a date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least o responding to that Job Offer has been previously marked as el C.9 For each Application responding to a Job Offer, if the Applica as eligible then a winner must be finally determined for that this is done only once for that Job Offer. C.10 When a winner is determined for a Job Offer, Applications res
  • 53. Emergent artifact lifecycle 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner
  • 54. 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
  • 55. Expressing the process 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations 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 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
  • 60. 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
  • 61. 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!
  • 62. 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.
  • 63. 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]
  • 64. 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
  • 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 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
  • 67. 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
  • 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 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 … … …
  • 71. 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*(+*,
  • 72. 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*(+*,
  • 73. 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*(+*,
  • 74. 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*(+*,
  • 75. 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*(+*,
  • 76. 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*(+*,
  • 77. 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-,
  • 78. 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-,
  • 79. 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-,
  • 80. 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-,
  • 81. 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-,
  • 82. 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-,
  • 83. 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
  • 84. 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)
  • 85. 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
  • 86. 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
  • 87. 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
  • 88. 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
  • 89. 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
  • 90. 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
  • 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 • 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).
  • 93. 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
  • 94. 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.
  • 95. 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
  • 96. 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
  • 97. 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
  • 98. 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
  • 99. 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
  • 100. 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
  • 101. 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
  • 104. 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
  • 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 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.
  • 107. 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
  • 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 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.
  • 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 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
  • 113. Combining multiple dimensions is dangerous: undecidability around the corner! Can we formalize OCBC in a well-behaved temporal DL?
  • 114. 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!
  • 115. 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
  • 116. 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
  • 117. 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
  • 118. 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
  • 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) 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:
  • 121. 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
  • 122. 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
  • 123. 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