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

Modeling and reasoning over declarative data-aware processes with object-centric behavioral constraints

The document discusses modeling and reasoning over declarative data-aware processes, specifically in the context of job hiring processes. It emphasizes the importance of integrating data models with behavioral constraints, as well as capturing processes through case-centric notations. The document also highlights common mistakes and the challenges of ensuring proper orchestration in processes involving multiple participants.

Embed presentation

Download to read offline
Modeling and Reasoning over declarative data-aware processes with object-centric behavioural constraints Alessandro Artale, Alisa Kovtunova, Marco Montali, Wil M. P. van der Aalst
Forgive me, logicians!
Data and processes A challenging, but necessary marriage! Typical choice: divide and conquer, 
 separating structural and dynamic aspects
Let’s model a simple process!
Modeling with conventional notations Two main commitments: • A business process should be confined within a pool. • A pool relates to a case object type.
Case-Centricity JobOffer
Case-Centricity HiringCompany Businessunit Business unit offer identified post offer HRdept HR dept handle requests interview candidates offer job job offered JobOffer
Case-Centricity Candidate JobOffer 1..* *
Case-Centricity Candidate JobOffer 1..* * HiringCompany Businessunit Business unit offer identified post offer HRdept HR dept handle requests interview candidates offer job job offered Candidate
Case-Centricity Candidate JobOffer 1..* * HiringCompany Businessunit Business unit offer identified post offer HRdept HR dept handle requests interview candidates offer job job offered Candidate ?
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 Profile1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner
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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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])
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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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])
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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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])
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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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])
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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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 •Multiple pools required •Additional constructs needed •Synchronization issues

Not “just” a modeling issue…
50% data models 50% configure/ deploy diagnose/ get reqs. enact/ monitor (re) design adjust IT support reality (knowledge) workers managers/ analysts
50% 50% configure/ 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 Discovered Process
Discovery from ERP/CRM/legacy DBs • v ?
Flattening Reality time data activities
Flattening Reality time data activities
Flattening Reality time data activities
Flattening Reality time data activities
Do we really need to flatten reality?
time Object-Centric Behavioral Constraints activities data data model
time Object-Centric Behavioral Constraints activities data data model activities
 refer to classes
time Object-Centric Behavioral Constraints activities data data model activities
 refer to classes temporal constraints co-refer 
 via data model
data model (UML class diagram) Activities refer to classes C1 C2 R
data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C
data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3
data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3 “generating”
Hiring Example 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile1 / 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 Profile1 / 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
“Emerging” Business Artifacts 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 Profile1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner “Application” “Job Offer” many one
Expressing the Process 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile1 / 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 Profile1 / 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 Constraints8 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 Profile1 / 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 Profile1 / 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)
Behavioral Constraints Temporal constraints + V/U co-reference through the data model 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). non-response(A, B) If A is executed, then B will not be executed 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 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 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)) 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)
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 Profile1 / 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 Profile1 / 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 mining: discovering single constraints does not guarantee model correctness!
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 Profile1 / 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:
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 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; • (in its finite-trace version) at the basis of the Declare process modeling 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. LTL+DLs —> the right framework to capture OCBC. Models: data-aware traces! 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 Fig. 3: Trace fragment for the OCBC model in Fig. 2
Combining is dangerous: undecidability around the corner! Can we formalize OCBC in a well-behaved temporal DL?
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
Question A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Do we need to global constraints on activities, without co-referencing in the data model? No: everything scoped by data objects!
Activities Fade Away A1 A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Do we need to global constraints on activities, without co-referencing in the data model? The temporal DL TusALCQI suffices!
 [Combines ALCQI with LTL over concepts only] No: everything scoped by data objects! Temporal constraint over O1 and O2
Idea time data activities TusALCQI
Idea time activities data TusALCQI TusALCQI
Response Example12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is execut on some object o of type O (i.e., with R1( then an instance a2 of A2 must be execute 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( then an instance a2 of A2 must be executed on some object o2 of type O2 (i.e., with R2( that relates to o1 via R (i.e., having R(o1, o2) at the moment of exe (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 then no instance a2 of A2 that relates to the (i.e., with R2(a2, o)) can be executed afterw 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A no A B precedence A B unary-precedence A non A B responded-existence A non- Fig. 3: Types of temporal constraints between activit response(A, B) If A is executed, then B must be executed unary- response(A, B) If A is executed, then B must be execute wards. precedence(A, B) If A is executed, then B must have been ex unary- precedence(A, B) If A is executed, then B must have been e 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)
Response Example12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is execut on some object o of type O (i.e., with R1( then an instance a2 of A2 must be execute 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( then an instance a2 of A2 must be executed on some object o2 of type O2 (i.e., with R2( that relates to o1 via R (i.e., having R(o1, o2) at the moment of exe (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 then no instance a2 of A2 that relates to the (i.e., with R2(a2, o)) can be executed afterw 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A no A B precedence A B unary-precedence A non A B responded-existence A non- Fig. 3: Types of temporal constraints between activit response(A, B) If A is executed, then B must be executed unary- response(A, B) If A is executed, then B must be execute wards. precedence(A, B) If A is executed, then B must have been ex unary- precedence(A, B) If A is executed, then B must have been e 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 on some object o1 of type O2 is subject to the execution of some instance of A (i.e., is target of R1) then afterwards some object o2 of type O2 must be subject to the execution of some instance of B (i.e., is target of R2)
Reasoning Consistency, dead activity detection, checking implied constraints of OCBC models can be reduced to standard reasoning in TusALCQI
 —> ExpTime upper bound Also conditional compliance: given a data-aware trace, does the trace satisfies the OCBC model, possibly introducing missing events/data? If we only adopt V-coreference on classes, and do not consider covering on UML hierarchies
 —> drops to PSPACE (same as plain old LTL)
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
Monitoring
 (closed-open reasoning) Discovery of OCBC fragments 
 and other (imperative) models with data correlations Future work

More Related Content

PDF
Modeling and Reasoning over Declarative Data-Aware Processes with Object-Cent...
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PPT
Workforce Management & BPM Integration
byNathaniel Palmer
 
PPT
Workforce Management & BPM Integration
byNathaniel Palmer
 
PDF
5 Most Costly Hiring Mistakes Companies Can Make
byCVirtual
 
PDF
MANAGER PROCESS GUIDE FORMAT Sample Pages
byTimothy Koirtyohann, SPHR
 
PDF
Enriching Data Models with Behavioral Constraints
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Employee Recruiting Made Easy with Cyber Recruiter
byNet at Work
 
PDF
Preparing Your Data for an Affirmative Action Plan: Applicant Flow
byThomas Econometrics
 
Modeling and Reasoning over Declarative Data-Aware Processes with Object-Cent...
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Workforce Management & BPM Integration
byNathaniel Palmer
 
Workforce Management & BPM Integration
byNathaniel Palmer
 
5 Most Costly Hiring Mistakes Companies Can Make
byCVirtual
 
MANAGER PROCESS GUIDE FORMAT Sample Pages
byTimothy Koirtyohann, SPHR
 
Enriching Data Models with Behavioral Constraints
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Employee Recruiting Made Easy with Cyber Recruiter
byNet at Work
 
Preparing Your Data for an Affirmative Action Plan: Applicant Flow
byThomas Econometrics
 

Similar to Modeling and reasoning over declarative data-aware processes with object-centric behavioral constraints

PPTX
CHAPTER 2 (PART 1) - RECRUITMENT AND SELECTION.pptx
byshisyi
 
PPT
Hr5 rec selec
bymadhvih
 
PPT
Hrm 2nd day training slides
byHijratullah Tahir
 
PPT
Oracle HRMS recruitment
byyogitas1
 
PDF
Understanding Candidates for better recruitment
byVijay Singh
 
PDF
Recruiting Interviewing Selecting and Orienting New Employees 6th Edition Art...
byxadcalajlar
 
PPT
Chap012 final match_editing
byZilafeeq Shafilla
 
PPTX
Affintus why did we hire this guy v 2
byAffintus
 
PDF
Recruitment Challenges in 2025 and Their Solutions
byOptnation
 
PDF
HTR by - Avvento HR Solutions
bySHARAD KASHYAP
 
DOC
Recruitment %26 selection process
bySwati Sood
 
PPTX
Factors In Successful Recruitment & Retention July 09
byikuw Solutions, Inc.
 
PDF
Using big data to measure and maximize quality of hire | Talent Connect Anaheim
byLinkedIn Talent Solutions
 
PPTX
Crafting the Perfect Process
by3DResultsLLC
 
PDF
How to Rethink the Candidate Experience and Make Better Hires
byCareerBuilder
 
PPTX
Making the Case for Recruitment Process Outsourcing
byRecruitment Process Outsourcing Association
 
PPT
Understanding Job market using Probabilistic Graphical Models
byvumaasha
 
PDF
Effective Hiring Process
byJoe Harks
 
PDF
The Candidate Experience: How Background Screening Can Help or Hinder
byProforma Screening Solutions
 
PPTX
Hiring Scernario
byStrayer University
 
CHAPTER 2 (PART 1) - RECRUITMENT AND SELECTION.pptx
byshisyi
 
Hr5 rec selec
bymadhvih
 
Hrm 2nd day training slides
byHijratullah Tahir
 
Oracle HRMS recruitment
byyogitas1
 
Understanding Candidates for better recruitment
byVijay Singh
 
Recruiting Interviewing Selecting and Orienting New Employees 6th Edition Art...
byxadcalajlar
 
Chap012 final match_editing
byZilafeeq Shafilla
 
Affintus why did we hire this guy v 2
byAffintus
 
Recruitment Challenges in 2025 and Their Solutions
byOptnation
 
HTR by - Avvento HR Solutions
bySHARAD KASHYAP
 
Recruitment %26 selection process
bySwati Sood
 
Factors In Successful Recruitment & Retention July 09
byikuw Solutions, Inc.
 
Using big data to measure and maximize quality of hire | Talent Connect Anaheim
byLinkedIn Talent Solutions
 
Crafting the Perfect Process
by3DResultsLLC
 
How to Rethink the Candidate Experience and Make Better Hires
byCareerBuilder
 
Making the Case for Recruitment Process Outsourcing
byRecruitment Process Outsourcing Association
 
Understanding Job market using Probabilistic Graphical Models
byvumaasha
 
Effective Hiring Process
byJoe Harks
 
The Candidate Experience: How Background Screening Can Help or Hinder
byProforma Screening Solutions
 
Hiring Scernario
byStrayer University
 

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

PDF
From Case-Isolated to Object-Centric Processes
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Constraints for Process Framing in Augmented BPM
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Declarative process mining
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
From legacy data to event data
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Extending Temporal Business Constraints with Uncertainty
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Intelligent Systems for Process Mining
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Reasoning on Labelled Petri Nets and Their Dynamics in a Stochastic Setting
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Process Reasoning and Mining with Uncertainty
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Formal modeling and SMT-based parameterized verification of Data-Aware BPMN
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
From Case-Isolated to Object-Centric Processes - A Tale of two Models
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Modeling and Reasoning over Declarative Data-Aware Processes
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Processes and organizations - a look behind the paper wall
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Representing and querying norm states using temporal ontology-based data access
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Putting decisions in perspective(s)
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Strategy Synthesis for Data-Aware Dynamic Systems with Multiple Actors
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Putting Decisions in Perspective(s)
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Compliance monitoring of multi-perspective declarative process models
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Soundness of Data-Aware Processes with Arithmetic Conditions
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Extending Temporal Business Constraints with Uncertainty
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PDF
Probabilistic Trace Alignment
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
From Case-Isolated to Object-Centric Processes
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Constraints for Process Framing in Augmented BPM
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Declarative process mining
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
From legacy data to event data
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Extending Temporal Business Constraints with Uncertainty
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Intelligent Systems for Process Mining
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Reasoning on Labelled Petri Nets and Their Dynamics in a Stochastic Setting
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Process Reasoning and Mining with Uncertainty
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Formal modeling and SMT-based parameterized verification of Data-Aware BPMN
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
From Case-Isolated to Object-Centric Processes - A Tale of two Models
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Modeling and Reasoning over Declarative Data-Aware Processes
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Processes and organizations - a look behind the paper wall
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Representing and querying norm states using temporal ontology-based data access
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Putting decisions in perspective(s)
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Strategy Synthesis for Data-Aware Dynamic Systems with Multiple Actors
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Putting Decisions in Perspective(s)
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Compliance monitoring of multi-perspective declarative process models
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Soundness of Data-Aware Processes with Arithmetic Conditions
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Extending Temporal Business Constraints with Uncertainty
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Probabilistic Trace Alignment
byFaculty of Computer Science - Free University of Bozen-Bolzano
 

Recently uploaded

PPTX
A short story by Luis Joaquin Katigbak: Passengers.pptx
bynathanielurgadasangg
 
PDF
SAP Strategy & Innovation - SAP Business AI 2025.pdf
byAlexander Vorobyev
 
PDF
Essential Views of the Integrated Program Management Reports.pdf
byGlenAlleman1
 
PDF
SAP Strategy Update - Business AI 2025.pdf
byAlexander Vorobyev
 
PPTX
Bob Stewart Nicodemus Final 01-25-2026.pptx
byFamilyWorshipCenterD
 
PPT
Information Technology Project Management, Fourth Edition
byZaidAlbajy
 
PDF
Manufacturing industries of Ethiopia.pdf
bydangula000
 
PPTX
2026-01-25 Hebrews 04 (shared slides).pptx
byDale Wells
 
PPTX
Right Triangle Similarity Theorem or 9th grade.pptx
by59012022
 
PPTX
Unit - 1 HISTORY IN PHARMACEUTICAL SUBSTANCE, TYPES AND SOURCES OF IMPURITIES
byShyamSudarsan1
 
A short story by Luis Joaquin Katigbak: Passengers.pptx
bynathanielurgadasangg
 
SAP Strategy & Innovation - SAP Business AI 2025.pdf
byAlexander Vorobyev
 
Essential Views of the Integrated Program Management Reports.pdf
byGlenAlleman1
 
SAP Strategy Update - Business AI 2025.pdf
byAlexander Vorobyev
 
Bob Stewart Nicodemus Final 01-25-2026.pptx
byFamilyWorshipCenterD
 
Information Technology Project Management, Fourth Edition
byZaidAlbajy
 
Manufacturing industries of Ethiopia.pdf
bydangula000
 
2026-01-25 Hebrews 04 (shared slides).pptx
byDale Wells
 
Right Triangle Similarity Theorem or 9th grade.pptx
by59012022
 
Unit - 1 HISTORY IN PHARMACEUTICAL SUBSTANCE, TYPES AND SOURCES OF IMPURITIES
byShyamSudarsan1
 

Modeling and reasoning over declarative data-aware processes with object-centric behavioral constraints

  • 1.
    Modeling and Reasoningover declarative data-aware processes with object-centric behavioural constraints Alessandro Artale, Alisa Kovtunova, Marco Montali, Wil M. P. van der Aalst
  • 2.
  • 3.
    Data and processes Achallenging, but necessary marriage! Typical choice: divide and conquer, 
 separating structural and dynamic aspects
  • 4.
    Let’s model asimple process!
  • 5.
    Modeling with conventionalnotations Two main commitments: • A business process should be confined within a pool. • A pool relates to a case object type.
  • 6.
  • 7.
    Case-Centricity HiringCompany Businessunit Business unit offer identified postoffer HRdept HR dept handle requests interview candidates offer job job offered JobOffer
  • 8.
  • 9.
    Case-Centricity Candidate JobOffer 1..* * HiringCompany Businessunit Businessunit offer identified post offer HRdept HR dept handle requests interview candidates offer job job offered Candidate
  • 10.
    Case-Centricity Candidate JobOffer 1..* * HiringCompany Businessunit Businessunit offer identified post offer HRdept HR dept handle requests interview candidates offer job job offered Candidate ?
  • 11.
    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 Profile1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner
  • 12.
    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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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])
  • 13.
    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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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])
  • 14.
    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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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])
  • 15.
    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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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])
  • 16.
    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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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
  • 17.
    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 Profile1 / 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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 HiringCompanyCandidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application HiringCompany 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 •Multiple pools required •Additional constructs needed •Synchronization issues

  • 18.
  • 19.
  • 20.
    50% 50% configure/ deploy diagnose/ get reqs. enact/ monitor (re) design adjust ITsupport reality (knowledge) workers managers/ analysts data models process mining
  • 21.
    Discovery from EventLogs • N Event Log Discovered Process
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
    Do we reallyneed to flatten reality?
  • 28.
  • 29.
  • 30.
    time Object-Centric Behavioral Constraints activities data data model activities
 referto classes temporal constraints co-refer 
 via data model
  • 31.
    data model (UML classdiagram) Activities refer to classes C1 C2 R
  • 32.
    data model (UML classdiagram) Activities refer to classes C1 C2 R activities A B C
  • 33.
    data model (UML classdiagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3
  • 34.
    data model (UML classdiagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3 “generating”
  • 35.
    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 Profile1 / 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
  • 36.
    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 Profile1 / 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
  • 37.
    “Emerging” Business Artifacts 10A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner “Application” “Job Offer” many one
  • 38.
    Expressing the Process 10A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile1 / 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
  • 39.
    Expressing the Process 10A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile1 / 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
  • 40.
    Temporal Constraints8 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
  • 41.
    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 Profile1 / 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
  • 42.
    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 Profile1 / 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)
  • 43.
    Behavioral Constraints Temporal constraints+ V/U co-reference through the data model 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). non-response(A, B) If A is executed, then B will not be executed 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 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 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)) 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)
  • 44.
    Hiring Constraints C.8 Awinner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations Enriching Data Models with Behavioral Constraints 13 is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner c c
  • 45.
    Further Hiring Constraints EnrichingData Models with Behavioral Constraints 13 is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile1 / 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
  • 46.
    Key Questions 1. Whatis the semantics of these models 2. Can we do automated reasoning?
 Consistency, dead activities, implied constraints…
 Also relevant for process mining: discovering single constraints does not guarantee model correctness!
  • 47.
    Implied Constraints
 (Hidden Dependencies) EnrichingData Models with Behavioral Constraints 13 is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile1 / 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:
  • 48.
    Temporal Description Logics Familyof KR logical formalisms to represent and reason about static, structural knowledge. Provide foundations to: • data models; • ontologies and semantic web. We focus on ALCQI: • captures UML class diagrams, E-R, ORM.
  • 49.
    Temporal Description Logics OBDAfor Log Extraction in Process Mining 25 Paper title : String type : String Person pName : String regTime: ts Assignment invTime: ts Submission uploadTime: ts CRUpload Creation DecidedPaper decTime: ts accepted: boolean notifiedBy Review subTime: ts leadsTo Conference cName: String crTime: ts submittedTo chairs * * * 1..* * 1 1 0..1 * 1 1 * Fig. 9: Data model of our CONFSYS running example Correctness of the Encoding. The encoding we have provided is faithful, in the sense that it fully preserves in the DL-LiteA ontology the semantics of the UML class diagram. Obviously, since, due to reification, the ontology alphabet may contain additional sym- bols with respect to those used in the UML class diagram, the two specifications cannot have the same logical models. However, it is possible to show that the logical models of a UML class diagram and those of the DL-LiteA ontology derived from it correspond to each other, and hence that satisfiability of a class or association in the UML diagram corresponds to satisfiability of the corresponding concept or role [29,7]. Example 9. We illustrate the encoding of UML class diagrams in DL-LiteA on the UML class diagram shown in Figure 9, which depicts (a simplified version of) the in- formation model of the CONFSYS conference submission system used for our running example. We assume that the components of associations are given from left to right and from top to bottom. Papers are represented through the Paper class, with attributes A L C Q I
  • 50.
    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
  • 51.
    Temporal Description Logics Familyof KR logical formalisms to represent and reason about time. We focus on LTL: • models: execution traces; • (in its finite-trace version) at the basis of the Declare process modeling language.
  • 52.
    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
  • 53.
    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
  • 54.
    Temporal Description Logics Combinestatic and dynamic aspects into a unique logical framework. LTL+DLs —> the right framework to capture OCBC. Models: data-aware traces! 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 Fig. 3: Trace fragment for the OCBC model in Fig. 2
  • 55.
    Combining is dangerous: undecidability around the corner! Can we formalize OCBC in a well-behaved temporal DL?
  • 56.
    Which Route? A1 A2 O R1R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex
  • 57.
    Which Route? A1 A2 O R1R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Chaining relations across time
  • 58.
    Question A1 A2 O R1 R2 Everytime an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Do we need to global constraints on activities, without co-referencing in the data model? No: everything scoped by data objects!
  • 59.
    Activities Fade Away A1A2 O R1 R2 Every time an instance a1 of on some object o of type O ( then an instance a2 of A2 mu on the same object o (i.e., wi (a) Co-reference of response over an object cl A1 A2 O1 O2 R R1 R2 Every time an instance a1 of A on some object o1 of type O1 then an instance a2 of A2 mus on some object o2 of type O2 that relates to o1 via R (i.e., having R(o1, o2) at the m (b) Co-reference of response over a relationsh A1 A2 O R1 R2 Every time an instance a1 of A on some object o of type O (i.e then no instance a2 of A2 that (i.e., with R2(a2, o)) can be ex Do we need to global constraints on activities, without co-referencing in the data model? The temporal DL TusALCQI suffices!
 [Combines ALCQI with LTL over concepts only] No: everything scoped by data objects! Temporal constraint over O1 and O2
  • 60.
  • 61.
  • 62.
    Response Example12 A.Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is execut on some object o of type O (i.e., with R1( then an instance a2 of A2 must be execute 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( then an instance a2 of A2 must be executed on some object o2 of type O2 (i.e., with R2( that relates to o1 via R (i.e., having R(o1, o2) at the moment of exe (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 then no instance a2 of A2 that relates to the (i.e., with R2(a2, o)) can be executed afterw 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A no A B precedence A B unary-precedence A non A B responded-existence A non- Fig. 3: Types of temporal constraints between activit response(A, B) If A is executed, then B must be executed unary- response(A, B) If A is executed, then B must be execute wards. precedence(A, B) If A is executed, then B must have been ex unary- precedence(A, B) If A is executed, then B must have been e 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)
  • 63.
    Response Example12 A.Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is execut on some object o of type O (i.e., with R1( then an instance a2 of A2 must be execute 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( then an instance a2 of A2 must be executed on some object o2 of type O2 (i.e., with R2( that relates to o1 via R (i.e., having R(o1, o2) at the moment of exe (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 then no instance a2 of A2 that relates to the (i.e., with R2(a2, o)) can be executed afterw 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A no A B precedence A B unary-precedence A non A B responded-existence A non- Fig. 3: Types of temporal constraints between activit response(A, B) If A is executed, then B must be executed unary- response(A, B) If A is executed, then B must be execute wards. precedence(A, B) If A is executed, then B must have been ex unary- precedence(A, B) If A is executed, then B must have been e 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 on some object o1 of type O2 is subject to the execution of some instance of A (i.e., is target of R1) then afterwards some object o2 of type O2 must be subject to the execution of some instance of B (i.e., is target of R2)
  • 64.
    Reasoning Consistency, dead activitydetection, checking implied constraints of OCBC models can be reduced to standard reasoning in TusALCQI
 —> ExpTime upper bound Also conditional compliance: given a data-aware trace, does the trace satisfies the OCBC model, possibly introducing missing events/data? If we only adopt V-coreference on classes, and do not consider covering on UML hierarchies
 —> drops to PSPACE (same as plain old LTL)
  • 65.
    Conclusion OCBC: a declarativeapproach
 to elegantly capture processes
 with co-evolving objects Formal logic-based semantics in a temporal DL that enables automated reasoning
  • 66.
    Monitoring
 (closed-open reasoning) Discovery ofOCBC fragments 
 and other (imperative) models with data correlations Future work