Modeling and Reasoning over Declarative Data-Aware Processes with Object-Centric Behavioral Constraints
•
0 likes•10 views
Presentation of the paper "Modeling and Reasoning over Declarative Data-Aware Processes with Object-Centric Behavioral Constraints" at the 17th Int. Conference on Business Process Management (BPM 2019). Paper available here: https://link.springer.com/chapter/10.1007/978-3-030-26619-6_11 Abstract Existing process modeling notations ranging from Petri nets to BPMN have difficulties capturing the data manipulated by processes. Process models often focus on the control flow, lacking an explicit, conceptually well-founded integration with real data models, such as ER diagrams or UML class diagrams. To overcome this limitation, Object-Centric Behavioral Constraints (OCBC) models were recently proposed as a new notation that combines full-fledged data models with control-flow constraints inspired by declarative process modeling notations such as DECLARE and DCR Graphs. We propose a formalization of the OCBC model using temporal description logics. The obtained formalization allows us to lift all reasoning services defined for constraint-based process modeling notations without data, to the much more sophisticated scenario of OCBC. Furthermore, we show how reasoning over OCBC models can be reformulated into decidable, standard reasoning tasks over the corresponding temporal description logic knowledge base.
Recommended
More Related Content
More from Faculty of Computer Science - Free University of Bozen-Bolzano
More from Faculty of Computer Science - Free University of Bozen-Bolzano (20)
Recently uploaded
Recently uploaded (20)
Modeling and Reasoning over Declarative Data-Aware Processes with Object-Centric Behavioral Constraints
- 1. 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
- 3. Data and processes A challenging, but necessary marriage! Typical choice: divide and conquer, separating structural and dynamic aspects
- 4. Let’s model a simple process!
- 5. 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.
- 7. 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
- 9. 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
- 10. 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 ?
- 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. Not “just” a modeling issue…
- 19. 50% data models 50% con fi gure/ deploy diagnose/ get reqs. enact/ monitor (re) design adjust IT support reality (knowledge) workers managers/ analysts
- 20. 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
- 21. Discovery from Event Logs • N Event Log Discovered Process
- 27. Do we really need to fl atten reality?
- 29. time Object-Centric Behavioral Constraints activities data data model activities refer to classes
- 30. time Object-Centric Behavioral Constraints activities data data model activities refer to classes temporal constraints co-refer via data model
- 31. data model (UML class diagram) Activities refer to classes C1 C2 R
- 32. data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C
- 33. data model (UML class diagram) Activities refer to classes C1 C2 R activities A B C # # # 1 1 R1 R2 R3
- 34. data model (UML class diagram) 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 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
- 38. 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
- 39. 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
- 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 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
- 45. 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
- 46. 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!
- 47. 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:
- 48. 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.
- 49. 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
- 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 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.
- 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 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
- 55. Combining is dangerous: undecidability around the corner! Can we formalize OCBC in a well-behaved temporal DL?
- 56. 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
- 57. 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
- 58. 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!
- 59. 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
- 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 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)
- 65. 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
- 66. Monitoring (closed-open reasoning) Discovery of OCBC fragments and other (imperative) models with data correlations Future work