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

Modeling and Reasoning over Declarative Data-Aware Processes with Object-Centric Behavioral Constraints

The document discusses modeling and reasoning over data-aware processes, specifically in the context of job hiring using object-centric behavioral constraints. It highlights the importance of case-centricity in understanding and managing the interactions between candidates and hiring organizations. Common pitfalls in modeling job hiring processes are also addressed, emphasizing the need for accurate representation of the case and task orchestration.

Embed presentation

Download as PDF, PPTX
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 con fi ned within a pool. • A pool relates to a case object type.
Case-Centricity JobOffer
Case-Centricity Hiring Company Business unit Business unit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered JobOffer
Case-Centricity Candidate JobOffer 1..* *
Case-Centricity Candidate JobOffer 1..* * Hiring Company Business unit Business unit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered Candidate
Case-Centricity Candidate JobOffer 1..* * Hiring Company Business unit Business unit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered Candidate ?
Case-Centricity 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner
Case-Centricity 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
Case-Centricity 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
Case-Centricity 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
Case-Centricity 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
Case-Centricity 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) serialisation
Case-Centricity 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) serialisation •Multiple pools required •Additional constructs needed •Synchronization issues 

Not “just” a modeling issue…
50% data models 50% con fi gure/ deploy diagnose/ get reqs. enact/ monitor (re) design adjust IT support reality (knowledge) workers managers/ analysts
50% 50% con fi gure/ deploy diagnose/ get reqs. enact/ monitor (re) design adjust IT support reality (knowledge) workers managers/ analysts data models process mining
Discovery from Event Logs • N Event Log 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 fl atten 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner which instances of tasks are related by the constraint depending on manipulate. In particular, the relevant constraints for our job hiring example are: C.1 The register data task is about a Person. C.2 A Job Offer is created by executing the post offer task. C.3 A Job Offer is closed by determining the winner. C.4 A Job Offer is stopped by canceling the hiring. Enriching Data Models with Behavioral Co C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data a date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least o responding to that Job Offer has been previously marked as el C.9 For each Application responding to a Job Offer, if the Applica as eligible then a winner must be finally determined for that this is done only once for that Job Offer. C.10 When a winner is determined for a Job Offer, Applications res
Hiring Example 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner which instances of tasks are related by the constraint depending on manipulate. In particular, the relevant constraints for our job hiring example are: C.1 The register data task is about a Person. C.2 A Job Offer is created by executing the post offer task. C.3 A Job Offer is closed by determining the winner. C.4 A Job Offer is stopped by canceling the hiring. Enriching Data Models with Behavioral Co C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data a date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least o responding to that Job Offer has been previously marked as el C.9 For each Application responding to a Job Offer, if the Applica as eligible then a winner must be finally determined for that this is done only once for that Job Offer. C.10 When a winner is determined for a Job Offer, Applications res
“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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner “Application” “Job O ff er” many one
Expressing the Process 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations
Expressing the Process 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints
Temporal Constraints 8 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. Inspired by the Declare declarative process modeling notation
Is That Enough? No! 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints
Is That Enough? No! 10 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints co-reference on object (V co-reference) co-reference on relation (U co-reference)
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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner c c
Further Hiring Constraints Enriching Data Models with Behavioral Constraints 13 is about 1 1 creates 1 promotes 1 creates 1 1 stops 1 closes 1 Person Candidate Application Job Offer Job Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 5 An Application is created by executing the submit task. 6 An Application is promoted by marking it as eligible. 7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. 8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. 9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. 0 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. 1 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2 Capturing the Job Hiring Example with Case-Centric Notations he most fundamental issue when trying to capture the job hiring example of Section 2.1 sing case-centric notation is to identify what is the case. This, in turn, determines hat is the orchestration point for the process, that is, which participant coordinates rocess instances corresponding to different case objects. This problem is apparent when ooking at BPMN, which specifies that each process should correspond to a single locus 4
Key Questions 1. What is the semantics of these models? 2. Can we do automated reasoning?
 Consistency, dead activities, implied constraints…
 Also relevant for process 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 An Application is promoted by marking it as eligible. 7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. 8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. 9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. 0 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. 1 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). .2 Capturing the Job Hiring Example with Case-Centric Notations he most fundamental issue when trying to capture the job hiring example of Section 2.1 sing case-centric notation is to identify what is the case. This, in turn, determines hat is the orchestration point for the process, that is, which participant coordinates rocess instances corresponding to different case objects. This problem is apparent when ooking at BPMN, which specifies that each process should correspond to a single locus f control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- ging Applications), and the job hiring organisation (in turn responsible for the The OCBC model implies:
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 fi nite-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 su ffi ces!
 [Combines ALCQI with LTL over concepts only] No: everything scoped by data objects! Temporal constraint over O1 and O2
Idea time data activities T u s A L C Q I
Idea time activities data T u s A L C Q I T u s A L C Q I
Response Example 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is 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 Example 12 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is 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 satis fi es 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
 
PDF
Enriching Data Models with Behavioral Constraints
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
PPT
Hr5 rec selec
bymadhvih
 
PDF
Preparing Your Data for an Affirmative Action Plan: Applicant Flow
byThomas Econometrics
 
PDF
MANAGER PROCESS GUIDE FORMAT Sample Pages
byTimothy Koirtyohann, SPHR
 
PPT
Understanding Job market using Probabilistic Graphical Models
byvumaasha
 
PDF
Understanding Candidates for better recruitment
byVijay Singh
 
PPTX
CHAPTER 2 (PART 1) - RECRUITMENT AND SELECTION.pptx
byshisyi
 
Modeling and reasoning over declarative data-aware processes with object-cent...
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Enriching Data Models with Behavioral Constraints
byFaculty of Computer Science - Free University of Bozen-Bolzano
 
Hr5 rec selec
bymadhvih
 
Preparing Your Data for an Affirmative Action Plan: Applicant Flow
byThomas Econometrics
 
MANAGER PROCESS GUIDE FORMAT Sample Pages
byTimothy Koirtyohann, SPHR
 
Understanding Job market using Probabilistic Graphical Models
byvumaasha
 
Understanding Candidates for better recruitment
byVijay Singh
 
CHAPTER 2 (PART 1) - RECRUITMENT AND SELECTION.pptx
byshisyi
 

Similar to Modeling and Reasoning over Declarative Data-Aware Processes with Object-Centric Behavioral Constraints

PDF
5 Most Costly Hiring Mistakes Companies Can Make
byCVirtual
 
PDF
Using big data to measure and maximize quality of hire | Talent Connect Anaheim
byLinkedIn Talent Solutions
 
PPTX
Affintus why did we hire this guy v 2
byAffintus
 
DOC
Recruitment %26 selection process
bySwati Sood
 
PDF
From Queries to Candidates: Exploring the Search and Source Interaction Behav...
byToine Bogers
 
PDF
Effective Hiring Process
byJoe Harks
 
PPTX
Crafting the Perfect Process
by3DResultsLLC
 
PPT
Workforce Management & BPM Integration
byNathaniel Palmer
 
PPT
Workforce Management & BPM Integration
byNathaniel Palmer
 
PDF
How to Rethink the Candidate Experience and Make Better Hires
byCareerBuilder
 
PPTX
Factors In Successful Recruitment & Retention July 09
byikuw Solutions, Inc.
 
PPT
Hrm 2nd day training slides
byHijratullah Tahir
 
PPTX
Introduction to Staffing - An Essential Human Resources Function - Aditya Das...
byAditya Dasgupta
 
PDF
Employee Recruiting Made Easy with Cyber Recruiter
byNet at Work
 
PPTX
Hiring Scernario
byStrayer University
 
PDF
Recruiting workshop 2013
byCulturalChemistry
 
PDF
Recruiting workshop 2013
byCulturalChemistry
 
PPTX
Staffing services
byShubham Singhal
 
PDF
Using Contextual Graphs as a Decision-making Tool in the Process of Hiring Ca...
bygerogepatton
 
PPT
Recruiting Great People
byCareers Coach
 
5 Most Costly Hiring Mistakes Companies Can Make
byCVirtual
 
Using big data to measure and maximize quality of hire | Talent Connect Anaheim
byLinkedIn Talent Solutions
 
Affintus why did we hire this guy v 2
byAffintus
 
Recruitment %26 selection process
bySwati Sood
 
From Queries to Candidates: Exploring the Search and Source Interaction Behav...
byToine Bogers
 
Effective Hiring Process
byJoe Harks
 
Crafting the Perfect Process
by3DResultsLLC
 
Workforce Management & BPM Integration
byNathaniel Palmer
 
Workforce Management & BPM Integration
byNathaniel Palmer
 
How to Rethink the Candidate Experience and Make Better Hires
byCareerBuilder
 
Factors In Successful Recruitment & Retention July 09
byikuw Solutions, Inc.
 
Hrm 2nd day training slides
byHijratullah Tahir
 
Introduction to Staffing - An Essential Human Resources Function - Aditya Das...
byAditya Dasgupta
 
Employee Recruiting Made Easy with Cyber Recruiter
byNet at Work
 
Hiring Scernario
byStrayer University
 
Recruiting workshop 2013
byCulturalChemistry
 
Recruiting workshop 2013
byCulturalChemistry
 
Staffing services
byShubham Singhal
 
Using Contextual Graphs as a Decision-making Tool in the Process of Hiring Ca...
bygerogepatton
 
Recruiting Great People
byCareers Coach
 

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

Recently uploaded

PPTX
Tissue Expansion , a technique used in plastic surgery
byrandil1
 
PPT
Ch04uiuuuuuuuuuuuuuuuuuuuuuukkkkkkklh.ppt
bykarzanberdawood
 
PDF
Hematology-1-Lesson_About_Hematopoiesis_and_erythropoetin
byyunahilnaya
 
PDF
12th Bio NCERT Important Questions @irfanullah_ mehar.pdf
byWorld of Wisdom
 
PDF
Understanding the Metabolism of Proteolysis Targeting Chimeras (PROTACs): The...
byVirat Ojha
 
PPTX
Sci-Tech Filler - Quiz for Coeus 2023.pptx
bynvkeerthana2002
 
PPTX
Photosynthesis (Light dependent reaction and Calvin cycle).pptx
byRashmiMG2
 
PPTX
production of glucose from starch.enz.pptx
byxenonfluxz
 
PDF
HND Networking and Cloud Computing (NCC).pdf
byssuser8dcccc
 
PPTX
Plant Physiology-Key words by Stuti Farmer.pptx
bystutifarmer
 
PPTX
PRE NATAL GROWTH OF MAXILLA in orthodontics.pptx
byharanip03
 
PDF
Animal Classification - Grade of Organisation, Symmetry, Coelom, Embryogeny ...
byWorld of Wisdom
 
PPTX
Ianalumab_ITP_Journal_Presentation_FULL.pptx
bysandiponroy342
 
PDF
Deep-Behavioral Phenotyping in Systems Neuroscience for Functional Atlasing a...
byAna Luísa Pinho
 
PDF
Sciences of Europe No 180 (2025)
bySciences of Europe
 
PPTX
ALLOSTERIC INHIBITION : ITS CHARACTERISTICS, STRUCTURE AND MECHANISMS
byaubrey02judd
 
PDF
Mechanical Properties of Fluids (Prashant Kirad).pdf
byarleenaulakh97
 
PDF
Star Constollations and Quasars.pdf Files
bycastilloronelparro22
 
PPTX
PPt Fisheries and Aquaculture.pptx course
bytigistafework
 
PPTX
Data Collection and data types Chapter 2.pptx
byModern College Shivajinagar, Pune-5
 
Tissue Expansion , a technique used in plastic surgery
byrandil1
 
Ch04uiuuuuuuuuuuuuuuuuuuuuuukkkkkkklh.ppt
bykarzanberdawood
 
Hematology-1-Lesson_About_Hematopoiesis_and_erythropoetin
byyunahilnaya
 
12th Bio NCERT Important Questions @irfanullah_ mehar.pdf
byWorld of Wisdom
 
Understanding the Metabolism of Proteolysis Targeting Chimeras (PROTACs): The...
byVirat Ojha
 
Sci-Tech Filler - Quiz for Coeus 2023.pptx
bynvkeerthana2002
 
Photosynthesis (Light dependent reaction and Calvin cycle).pptx
byRashmiMG2
 
production of glucose from starch.enz.pptx
byxenonfluxz
 
HND Networking and Cloud Computing (NCC).pdf
byssuser8dcccc
 
Plant Physiology-Key words by Stuti Farmer.pptx
bystutifarmer
 
PRE NATAL GROWTH OF MAXILLA in orthodontics.pptx
byharanip03
 
Animal Classification - Grade of Organisation, Symmetry, Coelom, Embryogeny ...
byWorld of Wisdom
 
Ianalumab_ITP_Journal_Presentation_FULL.pptx
bysandiponroy342
 
Deep-Behavioral Phenotyping in Systems Neuroscience for Functional Atlasing a...
byAna Luísa Pinho
 
Sciences of Europe No 180 (2025)
bySciences of Europe
 
ALLOSTERIC INHIBITION : ITS CHARACTERISTICS, STRUCTURE AND MECHANISMS
byaubrey02judd
 
Mechanical Properties of Fluids (Prashant Kirad).pdf
byarleenaulakh97
 
Star Constollations and Quasars.pdf Files
bycastilloronelparro22
 
PPt Fisheries and Aquaculture.pptx course
bytigistafework
 
Data Collection and data types Chapter 2.pptx
byModern College Shivajinagar, Pune-5
 

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 con fi ned within a pool. • A pool relates to a case object type.
  • 6.
  • 7.
    Case-Centricity Hiring Company Business unit Business unit offer identified postoffer HR dept HR dept handle requests interview candidates offer job job offered JobOffer
  • 8.
  • 9.
    Case-Centricity Candidate JobOffer 1..* * Hiring Company Business unit Businessunit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered Candidate
  • 10.
    Case-Centricity Candidate JobOffer 1..* * Hiring Company Business unit Businessunit offer identified post offer HR dept HR dept handle requests interview candidates offer job job offered Candidate ?
  • 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 Profile 1 / 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12])
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) serialisation
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) 6 A. Artale, D. Calvanese, M. Montali, and W. van der Aalst Hiring Company Candidate post offer check if eligible Application … Job Offer (a) A job hiring process receiving at most one application Hiring Company post offer Application Job Offer handle candidate … check if eligible Candidate (b) A job hiring process receiving multiple applica- tions in a sequential way; a new application is only han- dled when the previous applications has been checked for eligibility Fig. 2: Common beginner mistakes when capturing a job hiring process (diagrams inspired from [12]) serialisation •Multiple pools required •Additional constructs needed •Synchronization issues 

  • 18.
  • 19.
  • 20.
    50% 50% con fi gure/ 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 fl atten 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner which instances of tasks are related by the constraint depending on manipulate. In particular, the relevant constraints for our job hiring example are: C.1 The register data task is about a Person. C.2 A Job Offer is created by executing the post offer task. C.3 A Job Offer is closed by determining the winner. C.4 A Job Offer is stopped by canceling the hiring. Enriching Data Models with Behavioral Co C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data a date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least o responding to that Job Offer has been previously marked as el C.9 For each Application responding to a Job Offer, if the Applica as eligible then a winner must be finally determined for that this is done only once for that Job Offer. C.10 When a winner is determined for a Job Offer, Applications res
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner which instances of tasks are related by the constraint depending on manipulate. In particular, the relevant constraints for our job hiring example are: C.1 The register data task is about a Person. C.2 A Job Offer is created by executing the post offer task. C.3 A Job Offer is closed by determining the winner. C.4 A Job Offer is stopped by canceling the hiring. Enriching Data Models with Behavioral Co C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data a date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least o responding to that Job Offer has been previously marked as el C.9 For each Application responding to a Job Offer, if the Applica as eligible then a winner must be finally determined for that this is done only once for that Job Offer. C.10 When a winner is determined for a Job Offer, Applications res
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner “Application” “Job O ff er” many one
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints
  • 40.
    Temporal Constraints 8 A.Artale, D. Calvanese, M. Montali, and W. van der Aalst A B response A B unary-response A B non-response A B precedence A B unary-precedence A B non-precedence A B responded-existence A B non-coexistence Fig. 3: Types of temporal constraints between activities response(A, B) If A is executed, then B must be executed afterwards. unary- response(A, B) If A is executed, then B must be executed exactly once after- wards. precedence(A, B) If A is executed, then B must have been executed before. Inspired by the Declare declarative process modeling notation
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations The most fundamental issue when trying to capture the job hiring example of Section 2.1 using case-centric notation is to identify what is the case. This, in turn, determines what is the orchestration point for the process, that is, which participant coordinates process instances corresponding to different case objects. This problem is apparent when looking at BPMN, which specifies that each process should correspond to a single locus of control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- aging Applications), and the job hiring organisation (in turn responsible for the management of JobOffers). However, we cannot use neither of the two to act as unique locus of control for the process: on the one hand, candidates may simultaneously create and manage different applications for different job offers; on the other hand, the organi- sation may simultaneously spawn and manage different job offers, each one resulting Enriching Data Models with Behavioral Constraints 5 C.5 An Application is created by executing the submit task. C.6 An Application is promoted by marking it as eligible. C.7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. C.8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. C.9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. .10 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. .11 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2.2 Capturing the Job Hiring Example with Case-Centric Notations temporal constraints co-reference on object (V co-reference) co-reference on relation (U co-reference)
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner c c
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 5 An Application is created by executing the submit task. 6 An Application is promoted by marking it as eligible. 7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. 8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. 9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. 0 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. 1 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). 2 Capturing the Job Hiring Example with Case-Centric Notations he most fundamental issue when trying to capture the job hiring example of Section 2.1 sing case-centric notation is to identify what is the case. This, in turn, determines hat is the orchestration point for the process, that is, which participant coordinates rocess instances corresponding to different case objects. This problem is apparent when ooking at BPMN, which specifies that each process should correspond to a single locus 4
  • 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 Profile 1 / made by 1..⇤ ⇤ responds to 1 ⇤ refers to 1 register data submit mark as eligible post offer cancel hiring determine winner 6 An Application is promoted by marking it as eligible. 7 An Application can be submitted only if, beforehand, the data about the Candi- date who made that Application have been registered. 8 A winner can be determined for a Job Offer only if at least one Application responding to that Job Offer has been previously marked as eligible. 9 For each Application responding to a Job Offer, if the Application is marked as eligible then a winner must be finally determined for that Job Offer, and this is done only once for that Job Offer. 0 When a winner is determined for a Job Offer, Applications responding to that Job Offer cannot be marked as eligible anymore. 1 A Job Offer closed by a determine winner task cannot be stopped by executing the cancel hiring task (and vice-versa). .2 Capturing the Job Hiring Example with Case-Centric Notations he most fundamental issue when trying to capture the job hiring example of Section 2.1 sing case-centric notation is to identify what is the case. This, in turn, determines hat is the orchestration point for the process, that is, which participant coordinates rocess instances corresponding to different case objects. This problem is apparent when ooking at BPMN, which specifies that each process should correspond to a single locus f control, i.e., confined within a single pool.4 In our example, we have two participants: candidates (in turn responsible for man- ging Applications), and the job hiring organisation (in turn responsible for the The OCBC model implies:
  • 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 fi nite-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 su ffi ces!
 [Combines ALCQI with LTL over concepts only] No: everything scoped by data objects! Temporal constraint over O1 and O2
  • 60.
  • 61.
  • 62.
    Response Example 12 A.Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is 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 Example 12 A.Artale, D. Calvanese, M. Montali, and W. van der Aalst A1 A2 O R1 R2 Every time an instance a1 of A1 is 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 satis fi es 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