Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ILIKS2010 - Montali - Monitoring Time-Aware Commitments

162 views

Published on

Invited talk on "Monitoring Time-Aware Commitments" at the 2010 Annual meeting of the Interdisciplinary Laboratory on Interacting Knowledge (ILIKS 2010), 30/11/2010, LOA-CNR, Trento.

  • Be the first to comment

  • Be the first to like this

ILIKS2010 - Montali - Monitoring Time-Aware Commitments

  1. 1. MONITORING TIME-AWARE COMMITMENTS Marco Montali University of Bologna ILIKS 2010, Trento Joint work with Federico Chesani, Paola Mello and Paolo Torroni
  2. 2. Outline • Interaction models, openness, flexibility and monitoring • Social commitments • Why first-order languages are needed for capturing commitments • Time-aware commitments • Axiomatization in the Event Calculus • Monitoring with the Reactive and Cached Event Calculus • Implementation Issues
  3. 3. Interaction and Open Systems •  In many emerging settings! •  Distribution of activities and resources •  Unpredictability of their dynamics •  Programming-in-the-large paradigms to attack their complexity •  Intrinsic presence of multiple stakeholders •  Participants’ autonomy and heterogeneity ! Open systems •  Shift from the internal implementation of a single component to the interaction between components
  4. 4. Examples Participants Events Interaction Model Main Challenge Employees External stakeholders Customer Services Activities lifecycle: start, complete, abort, reassign,! Business Process Balance between the boundaries of the BP and the expertise of the involved stakeholders Healthcare professionals Patients Medical devices Admin. actions Therapeutic actions ! Clinical Guideline Balance between generally accepted best practices and the peculiarities of a patient Services People Messages Service Choreography Balance between conformance and adaptability/replaceability
  5. 5. Compliance vs Flexibility •  Interaction modeling languages for open systems must be able to balance between •  Compliance The act of conforming as requested by the interaction model (e.g. internal and external rules and norms) •  Flexibility The ability of accommodating and promptly adapting to change and to unforeseen situations Universe of Traces Compliant Traces Compliance Flexibility
  6. 6. State of the art •  Closed and procedural modeling abstractions
  7. 7. Towards open and declarative models Closed approaches All that is not explicitly modeled is forbidden Open approaches All that is not explicitly forbidden is allowed Procedural approaches A-priori, rigid definition of all the acceptable courses of interaction Declarative approaches Capture the interaction constraints without fixing a pre-determined way of satisfying them Flexibility sacrificed Flexibility guaranteed
  8. 8. Flexibility with procedural approaches Van der Aalst’s Spaghetti Models
  9. 9. The need for monitoring •  Autonomous entities cannot be controlled •  Hence they cannot be trusted •  Even in presence of static information about their behavior •  Unpredictable behaviors (e.g. when an exception is encountered) •  Implementation mismatches •  However, their (inter)actions are observable and traced •  It becomes then possible to monitor their behavior!!! •  Monitoring: •  run-time •  continuous support for tracking an execution of the system and •  Compute the reached state of affairs •  Infer the impact on the interaction models •  Promptly identify violations
  10. 10. Social Commitments [Castelfranchi 1995, Singh 1998] • Declarative and open interaction modeling • Idea: during the interaction, agents become committed to the others •  Mutual obligations between the interacting parties • Base-level commitment: c(x,y,p) A debtor agent x is committed towards a creditor agent y to bring about p
  11. 11. Flexibility in commitments • Defined in terms of properties that must be brought about •  Flexibility in the choice of concrete actions • E.g.: when a customer c pays seller s for an order, s is committed to eventually deliver the order •  c(s,c,orderDelivered) •  Every activity that has the effect of delivering the order is a candidate for satisfying the commitment
  12. 12. Commitment states •  At each time, a commitment is in a particular state •  Status of commitments " “normative state” of the course of interaction •  Agents implicitly manipulate commitments when they perform actions (i.e., generate events) •  Event occurrences •  Have effects (make properties true or false) •  Trigger operations on commitment •  Each operation causes a commitment’s state change
  13. 13. Simplified Lifecycle active violated satisfied create c(s,c,orderDelivered) pay(c,s) sendByAirMail(s,c) orderDelivered •  Two classes of operations •  Explicit •  Directly triggered by events •  Create, cancel, release, delegate, ... •  Implicit •  Relation between events and commitments mediated by the truth value of properties •  Discharge
  14. 14. General Framework Proof Theory and Reasoning Facilities Logic-Based Framework Logical Language Commitment-based Interaction Model Commitment Lifecycle Axiomatization Commitment Language
  15. 15. Our contribution Reactive reasoning techniques ! Monitoring (abductive) Logic Programming Event Calculus axiomatization LP + Event Calculus ontology Commitment-based Interaction Model Extended Commitment Lifecycle Axiomatization Extended Commitment Language
  16. 16. How expressive should a C-Language be? •  The majority of current approaches adopts propositional (modal) logics for the formalization of (commitment- based) interaction models
  17. 17. How expressive should a C-Language be? •  Completely ground properties •  orderDelivered!. But which order? •  What about data-related conditions? •  Lack of support for multiple instantiations of the same commitment •  What about an interaction protocol in which two orders must be delivered? •  No event correlation mechanisms (indistinguishable orders) •  No support for metric temporal aspects •  How to specify something like “you should deliver the order within 2 working days”? ! We need variables!
  18. 18. An example When a customer pays for an order of at least 20#, then the seller is committed to deliver that order within 2 days
  19. 19. An example When a customer pays for an order of at least 20#, then the seller is committed to deliver that order within 2 days general, universal statement data-related condition metric constraint (deadline) correlation (same order id)
  20. 20. pay(c,s) Alice sends a 30# payment to Lewis for order o-1 Charles sends a 25# payment to Lewis for order o-2 Rabbit sends a 10# payment to Lewis for order o-3 Lewis delivers o-2 to Charles Multiple instances active c(lewis,alice,orderDelivered(o-1)) active satisfied active active active c(lewis,charles,orderDelivered(o-2)) active CREATE CREATE DISCHARGE
  21. 21. Indefinitely active commitments •  An active commitment! •  that is never canceled •  whose property is never brought about •  !will indefinitely persist in the “active” state ! use of metric temporal constraints active c(lewis,alice,orderDelivered(o-1)) active CREATE active active
  22. 22. Time aware commitments active c(lewis,alice,orderDelivered(o-1)) active CREATE •  Now the seller is committed to deliver the order within 2 days at most
  23. 23. Time aware commitments active c(lewis,alice,orderDelivered(o-1)) active CREATE •  Now the seller is committed to deliver the order within 2 days at most •  The cancel operation becomes implicit violated violated 2 days elapsed Expired!
  24. 24. Existential vs universal commitments • c(x,y,prop(e(t1,t2),p)) •  Commitment satisfied iff p is brought about inside time interval [t1,t2] •  E.g.: the seller is committed to deliver the order within two days • c(x,y,prop(u(t1,t2),p)) •  Commitment satistied iff p is holds during the whole interval [t1,t2] •  E.g.: a car rental agency guarantees that the rented car will correctly work during the first five days • The effective time interval is grounded every time the commitment is instantiated
  25. 25. Formalizing time-aware commitments •  Main ingredients of commitments •  Events •  Time •  Properties that vary over time (fluents) •  States of the commitments’ lifecycle •  Again fluents! •  Operations are the “glue” Event Calculus [Kowalski and Sergot 1986] for formalizing the commitment lifecycle
  26. 26. Why Event Calculus - Language •  A logic-based framework for reasoning about time and events •  Declarativeness •  Logic-based axiomatization of commitments •  Flexibility •  Variables •  When a customer C pays seller S for an order O, S is committed to deliver O ! data-related aspects, multi-instances •  Explicit, metric characterization of time •  Quantitative Temporal Constraints ! time-aware commitments
  27. 27. Why Event Calculus - Reasoning • A logic-based framework for reasoning about time and events (A)LP + EC Ontology Event Calculus (EC) (Abductive) Logic Programming with NAF Proof Theory and Reasoning Facilities Logic-Based Framework Logical Language Commitment-based Interaction Model Commitment Lifecycle Axiomatization Commitment Language
  28. 28. Event Calculus Ontology MVI for fluent f in (2,12] a ac b 1 2 3 4 5 6 7 8 9 10 11 12 13 14 initiates(a,f,T) terminates(b,f,T) happens(a,6) holdsat(f,7) declip clip
  29. 29. •  Inspired by the seminal work of Yolum and Singh (2000) •  Commitment states as fluents state change :- operation operation :- event occurrence or effect of event Axiomatization - intuition pay(c,s,o) sendByAirMail(s,c,o) c(s,c,orderDelivered(o)) orderDelivered active satisfied CREATE DISCHARGE
  30. 30. Some basic axioms • Commitment activation initiates(E,status(C,active),T):- create(E,C,T). • Active→Satisfied transition terminates(E,status(C,active),T):- discharge(E,C,T). initiates(E,status(C,satisfied),T):- discharge(E,C,T). • Semantics of discharge discharge(E,c(X,Y,P),T):- holds_at(status(c(X,Y,P),active),T), initiates(E,P,T). • Domain-dependent fact: create(pay(C,S,O),c(S,C,orderDelivered(O)),_).
  31. 31. Existential Commitment 1/2 •  Discharged if p is brought about inside the requested interval discharge(E,c(X,Y,prop(e(T1,T2),P),T):- holds_at(status(c(X,Y,prop(e(T1,T2),P)),active),T), T∈[T1,T2], initiates(E,P,T). p active CREATE DISCHARGE t1 t2 satisfied
  32. 32. Existential Commitment 2/2 active CREATE t1 t2 violated •  Canceled if it is still active after the expiration time •  Situation recognized as soon as an event occurring after the expiration time is processed •  What matters is the actual time, not the event content cancel(_,c(X,Y,prop(e(T1,T2),P),T):- holdsat(status(c(X,Y,prop(e(T1,T2),P)),active),T), T>T2. DISCHARGE
  33. 33. •  Canceled if during [t1,t2] it is recognized that the property does not hold (anymore) Universal commitment 1/2 p active CREATE CANCEL violated t1 t2 cancel(_,c(X,Y,prop(u(T1,T2),P),T):- holds_at(status(c(X,Y,prop(u(T1,T2),P)),active),T), T∈[T1,T2], not holds_at(P,T).
  34. 34. •  Canceled if during [t1,t2] it is recognized that the property does not hold (anymore) Universal commitment 1/2 p active CREATE CANCEL violated t1 t2 cancel(_,c(X,Y,prop(u(T1,T2),P),T):- holds_at(status(c(X,Y,prop(u(T1,T2),P)),active),T), T∈[T1,T2], not holds_at(P,T).
  35. 35. •  Discharged if it is still active after t2 discharge(_,c(X,Y,prop(u(T1,T2),P),T):- holds_at(status(c(X,Y,prop(u(T1,T2),P)),active),T), T>T2. Universal commitment 2/2 p active CREATE satisfied t1 t2 DISCHARGE
  36. 36. Compensation •  In real-life situations, agents could recover from a violation by means of another commitment •  The recovery mechanism is called compensation •  When the first commitment is canceled! •  The second commitment (compensating commitment) is implicitly created •  The first commitment enters into a “compensated” state •  It has been violated but another commitment is currently active to deal with the exceptional situation •  Other compensation protocols can be seamlessly modeled •  Thanks to the EC declarativeness!
  37. 37. Example - Car rental contract • When a customer rents a car! • the agency guarantees that the rented car will correctly work for the first five days • if the rented car breaks down before the fifth day has elapsed, the agency promises a “1- day” immediate replacement Violation Compensating commitment
  38. 38. Example - Car rental contract •  The agency guarantees that the rented car will correctly work for the first five days create( do(Customer, rent(Agency,Car,Days)), c(Agency,Customer,property(u(Ts,Te),great_car(Car))), Ts ):- 5 < Days -> Te is Ts + 5; Te is Ts + Days.
  39. 39. Example - Car rental contract •  if the rented car breaks down before the fifth day has elapsed, the agency promises a “1-day” immediate replacement compensation( c( Agency, Customer, property(u(Ts,Te),great_car(Car))), c( Agency, Customer, property(e(Tv,Td),car_replaced(Car))), Tv ):- Td is Tv + 1.
  40. 40. Handling compensations rent-a-car (jan,ag,c) 1 great_car(c) CREATE c(ag,jan,prop(u(1,6),great_car(c)) actual time interval
  41. 41. Handling compensations rent-a-car (jan,ag,c) 1 great_car(c) 2 tick active great_car(c) CREATE c(ag,jan,prop(u(1,6),great_car(c))
  42. 42. Handling compensations rent-a-car (jan,ag,c) 1 great_car(c) 2 tick active great_car(c) CREATE 3 break-down (c) c(ag,jan,prop(u(1,6),great_car(c))
  43. 43. Handling compensations rent-a-car (jan,ag,c) 1 great_car(c) 2 tick active great_car(c) CREATE 43 break-down (c) tick c(ag,jan,prop(u(1,6),great_car(c))
  44. 44. active Handling compensations rent-a-car (jan,ag,c) 1 great_car(c) 2 tick active great_car(c) CREATE 43 break-down (c) tick compensated CREATE compensating commitment c(ag,jan,prop(e(4,5),car_replaced(c)) C(ag,jan,prop(u(1,6),great_car(c)) CANCEL
  45. 45. EC reactive reasoning effects of actions [initiates/terminates] evolution of fluents [holds_at] initial state [initially] partial trace [happens] Monitoring commitments • Dynamically track how the course of interaction affects commitments • EC-based monitoring ! reactive reasoning •  Update the truth of each fluent as events occur •  Commitments’ state are reified •  ! can be accessed by the agents •  Compliance evaluation: analysis of the currently discharged/ compensated/violated commitments
  46. 46. Monitoring! how to? • Classical reasoning in EC •  Deductive: given a trace and an initial state, does the narrative lead to a certain state of affairs (goal)? •  Abductive: Given an initial state, does a trace (plan) exists s.t. a desired state of affairs (goal) is reached? Which? •  EC has been rarely employed at run-time •  Deductive-like reasoning but •  Dynamic - incremental •  Event-driven, not goal-driven
  47. 47. Monitoring! how to? •  Lack of reactive reasoners! •  Usually, EC-based monitoring tackled with ad-hoc implementations •  For example, both the approaches of Farrel et al. (2005) and Mahbub and Spanoudakis (2007) employ an ad-hoc algorithm written in JAVA for reasoning •  No formal semantics •  Limited expressiveness (there is no underlying logic-based language) •  We have investigated two approaches •  Reactive Event Calculus (Chesani et al.) •  Lightweight variant of Cached Event Calculus (Chittaro and Montanari)
  48. 48. Cached Event Calculus [Chittaro and Montanari, 1996] •  Two classes of updates in the EC •  Goal update ! the goal is changed •  Trace update ! the trace is extended •  Monitoring: continuously subject to trace update •  Deductive reasoners must be restarted from scratch each time a new event occurs •  Cached Event Calculus •  LP axiomatization focused on the computation of MVIs •  Caches the currently computed MVIs •  When the trace is updated, the current result is revised/ extended •  Via assert/retract predicates ! Suitable for monitoring!!!
  49. 49. Reactive Event Calculus [Chesani et al. 2010] • Developed by the AI group at DEIS – University of Bologna • Reactive axiomatization of EC on top of the SCIFF language • The SCIFF framework encompasses •  A logic, rule-based language for the declarative specification of interaction constraints •  A declarative semantics for that language •  Provides a formal definition of compliance •  A family of proof procedure for reasoning •  The SCIFF proof procedure is able to verify whether a growing or complete trace complies with a given specification
  50. 50. Caching by abduction • SCIFF is tailored to abductive logic programming • REC takes inspiration from CEC • MVIs are abducible predicates • Integrity constraints used to •  Trigger the generation of MVIs in response to events • Manage the semantics of MVIs • The axiomatization is fully declarative and does not rely on extra-logical predicates
  51. 51. REC vs CEC CEC REC Reasoning Prolog-based reactive SCIFF-based reactive Manipulation of MVIs assert / retract abduction and integrity constraints Declarative semantics - + (formal properties) Software Integration + +/-
  52. 52. The SCIFF Abstractions •  Happened event ! corresponds to happens(e,t) in the EC •  H(e,t) states that event e occurs at time t (real or integer) •  A set of ground happened events is an execution trace •  Hp: if the last event of the trace is “complete”, the trace is complete, otherwise it is partial •  Positive Expectation •  E(e,t) states that event e is expected to occur at time t •  Must have a corresponding event occurrence •  Variables are existentially quantified •  Negative Expectation •  EN(e,t) states that event e is expected not to occur at time t •  Must have no corresponding event occurrence •  Variables are universally quantified
  53. 53. Expressiveness •  Variables can be involved into other predicates and CLP constraints •  Useful to impose quantitative time constraints on time variables •  E-bay is expected to sell item i123 for a price of at least 20 #, within time 60 at most (deadline) •  E(sell(e-bay,i123,Price),T) / Price > 20# / T < 60 •  Basic customers cannot never pay by credit card •  EN(pay(Customer,Item,credit_card),T)
  54. 54. The SCIFF Language •  Prolog KB to express the static domain knowledge •  Integrity constraints to constrain the dynamics of the system •  Forward rules relating happened events with expectations H(e1,t1) / H(e2,t2) / ! / constraints $ E/EN(e3, t3) / ! / constraints / E/EN(e4, t4) / ! / constraints / ! •  Interpreted in a reactive manner: whenever •  Happened events can contain variables: the integrity constraint will trigger for any possible configuration of ground happened events matching with the body •  When the constraint triggers, the expectations contained in the head are generated
  55. 55. Examples • Every time a premium customer sends a request_for_info, an employee is expected to send back an answer by at most 2 hours H(request_for_info(Customer,Info),T) / premium(Customer) $ E(answer(Employee,Content), T2) / T2 > T / T2 < T + 12 (minute granularity) • When the seller accepts an order from a customer, it cannot refuse it anymore H(accept(Seller,Customer,Order),T) $ EN(refuse(Seller,Customer,Order), T2) / T2 > T.
  56. 56. SCIFF Semantics •  SCIFF specifications mapped onto Abductive Logic Programs •  Expectations are abducibles •  Notion of compliant trace •  A trace which fulfills all the expectations generated by the specification + trace •  Every positive expectation has a matching event in the trace •  Every negative expectation does not have a matching event in the trace •  Three-valued semantics •  The notion of compliance changes when the trace is partial or complete •  For partial traces, violation of positive expectations and fulfillment of negative expectations cannot be always assessed •  Further events may still occur!
  57. 57. SCIFF Proof Procedure • An abductive proof procedure with reactive features • Dynamically •  collects the occurring events •  combines them with the specification •  generates abducibles and expectations accordingly •  evaluates the fulfillment/violation of the currently pending expectations • Implemented in SICStus and SWI Prolog, with CHR and CLP • Freely downloadable http://lia.deis.unibo.it/sciff/
  58. 58. Reactive Event Calculus in SCIFF •  Takes inspiration from the Cached Event Calculus •  MVIs are represented as abducibles, and dynamically generated by the SCIFF proof procedure as events occur •  Expectations are used to define the semantics of MVIs and guarantee their consistency •  Makes use of rules H(!) $ H(!) to generate internal events used to clip and declip fluents •  Decoupling between the real execution trace and the manipulation of fluents •  Efficient handling of non determinism •  The formalization is fully declarative and tailored to the declarative semantics of SCIFF
  59. 59. REC – Knowledge Base •  Semantics of initially •  We suppose that each execution trace begins with H(event(start),0) •  Hence, such a special event initiates a fluent if it initially holds initiates(start,F,0) % initially(F). •  Impact of the “complete” event •  It attests that the trace is complete, and thus terminates all the fluents that are still pending. terminates(complete,F,T). •  Semantics of holds_at •  A fluent F holds at time T if there exists an MVI for F containing T holds_at(F,T) % mvi(F,T1,T2) / T > T1 / T & T2.
  60. 60. Declip Events (“weak”) H(event(E),T) / initiates(E,F,T) / ¬ holds_at(F,T) $ H(declip(F),T). T E F H(declip(F),T) If • event E occurs at time T • E is able to initiate fluent F at time T • F does not hold at time T Then • F is declipped at time T
  61. 61. Declip Effect •  The declipping of F at time T triggers the generation of an MVI for F, starting from T and ending sometime in the future H(declip(F),T) $ mvi(F,T,Tend) / Tend > T. F H(declip(F),T) mvi
  62. 62. MVI Semantics •  Each MVI is maximal •  Starts when F is declipped •  Ends when F is clipped •  Each MVI characterizes an interval in which the fluent uninterruptedly holds •  No further clipping/declipping events should occur inside the interval ! they would alter the fluent’s status! mvi(F,Tstart,Tend) $ E(declip(F),Tstart) / E(clip(F),Tend) / EN(declip(F),Td) / Td > Tstart and Td & Tend / EN(clip(F),Tc) / Tc ' Tstart and Tc < Tend. F clip mvi declip
  63. 63. Clip Events H(event(E),T) / holds_at(F,T) / terminates(E,F,T) $ H(clip(F),T). T E F H(clip(F),T) If • event E occurs at time T • F holds at time T • E is able to terminate fluent F at time T Then • F is clipped at time T "  N.B.: from the combination between this rule and the MVI semantics ! F is clipped by the first event able to terminate it
  64. 64. Monitoring with REC •  The REC axioms, together with an EC domain- dependent specification, constitute a SCIFF specification •  Hence, the SCIFF Proof Procedure can be used to monitor a running trace, dynamically generating the MVIs of fluents •  MVIs with a variable end time are the ones which hold at the current time and have not yet terminated •  Incomplete knowledge! •  Hence, REC-based monitoring with SCIFF is sound, complete, and terminates provided that the given EC specification is acyclic and bounded
  65. 65. Example •  Let us consider the following EC specification •  KBdom: initially(f). terminates(a,f,T). initiates(b,f,T). 0 SCIFF Proof Procedure REC KBdom mvi(f,0,T) / T>0 f
  66. 66. Example •  Let us consider the following EC specification •  KBdom: initially(f). terminates(a,f,T). initiates(b,f,T). 1 2 a 0 SCIFF Proof Procedure REC KBdom mvi(f,0,2) f
  67. 67. Example •  Let us consider the following EC specification •  KBdom: initially(f). terminates(a,f,T). initiates(b,f,T). c b1 2 3 4 50 SCIFF Proof Procedure REC KBdom mvi(f,0,2) f a
  68. 68. Example •  Let us consider the following EC specification •  KBdom: initially(f). terminates(a,f,T). initiates(b,f,T). c b1 2 3 4 5 60 SCIFF Proof Procedure REC KBdom mvi(f,0,2), mvi(f,6,T) / T > 6 f a b
  69. 69. Trace Updates •  Let us consider a partial trace T whose end time is tcur •  When a new event occurrence happens(e,t) is collected, the partial trace is subject to an additive change: •  Tnew = T ∪ {happens(e,t)} •  Two possibile additive changes •  Revision: t < tcur •  Extension: t ' tcur event event event event event event event event
  70. 70. Revision vs Extension • Revision is typical of temporal databases •  Transaction time vs valid time • Extension is typical of interaction-oriented systems •  Business Process Management Systems •  Service-Oriented and Multi-Agent Systems (considering local timestamps)
  71. 71. Irrevocability •  Let us consider a “well-formed” EC specification •  It is desired that the reasoner behaves in an irrevocable manner •  When a partial trace ending at time tcur is extended •  Then also the computed MVIs are extended, not revised •  All the closed MVIs (MVIs with ground ending time) are maintained •  If some open MVI is now closed, its ending time is ' tcur •  If new MVIs are introduced, their starting time is ' tcur •  Irrevocability is extremely important when fluents carry a normative meaning •  An obligation cannot suddenly “disappear”
  72. 72. Ensuring Irrevocability • First, we characterize well-formed specifications • Then we prove that irrevocability holds in the case of REC, under the assumption that partial traces are always subject to extension changes
  73. 73. Well-formedness • A well-formed EC specification meets the following requirements •  Is acyclic and bounded •  Guarantees termination! •  Triggered fluents are ground •  For every initially(F), initiates(_,F,_) and terminates(_,F,_) predicates, F is resolved with a ground substitution •  Avoids non determinism due to incomplete information •  Is past-tense •  [¬]holds_at predicates used in the definition refer to the present or the past •  Avoids non determinism due to future-tense conditions Semi-decidability !!!
  74. 74. Well-formedness • A well-formed EC specification meets the following requirements •  Is acyclic and bounded •  Guarantees termination! •  Triggered fluents are ground •  For every initially(F), initiates(_,F,_) and terminates(_,F,_) predicates, F is resolved with a ground substitution •  Avoids non determinism due to incomplete information •  Is past-tense •  [¬]holds_at predicates used in the definition refer to the present or the past •  Avoids non determinism due to future-tense conditions Semi-decidability !!! The EC-based commitment lifecycle axiomatization is well-formed!
  75. 75. REC Formal Properties 1/2 • Hp: partial traces are only subject to extensions •  SCIFF can be used under semi-open reasoning: closed w.r.t. the past, open w.r.t. the future •  Since we now that the past trace will never change, all the expectations and constraints referring to the past can be evaluated in a definitive manner
  76. 76. REC Formal Properties 2/2 • Let us consider a well-formed EC specification S •  REC(S) is the combination of S with the REC axioms • For each trace T, there is always one and only one SCIFF semi-open successful derivation for REC(S) •  I.e., there exists only a unique set of consistent MVIs • SCIFF (under semi-open reasoning) is irrevocable •  I.e., when the trace is extended, the previously computed MVIs are extended as well (never revised)
  77. 77. Visual Intuition The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. SCIFF Extension! Extension!
  78. 78. Lightweight CEC • Assumptions •  The given EC theory is well-formed •  The execution traces are only subject to additive extensions ! Deterministic evolution of fluents ! When an event happens, only two cases must be handled: 1.  The event declips a fluent, creating a new open MVI 2.  The event clips a currently open MVI
  79. 79. Clip and Declip •  Modeled exactly as in REC Fluent F is declipped at time T if: •  An event happens at time T •  The event can initiate F at time T •  F does not hold at time T declip(F,T):- happens(E,T), initiates(E,F,T), + holds_at(F,T). Fluent F is clipped at time T if: •  An event happens at time T •  The event can terminate F at time T •  F holds at time T clip(F,T):- happens(E,T), terminates(E,F,T), holds_at(F,T).
  80. 80. Event acquisition update(happens(E,T)):- assert(happens(E,T)), my_setof(F,clip(F,T),S), close_mvis(S,T), my_setof(F,declip(F,T),S2), open_mvis(S2,T). Update trace Clip fluents (close MVIs) Declip fluents (open MVIs)
  81. 81. MVIs manipulation •  open MVIs have an unknown end time (constaint inf) open_mvi(F,T):- assert(mvi(F,[T,inf])). f f mvi(f,[t,(]) t t f f mvi(f,[ts,(]) t tts ts mvi(f,[ts,t]) •  holds_from used to now when the MVI around T was initiated close_mvi(F,T):- holds_from(F,T,T1), retract(mholds_for(F,[T1,inf])), assert(mholds_for(F,[T1,T])).
  82. 82. C’mon • JAVA-based wrapper for EC-based monitoring • Both REC and (lightweight) CEC supported •  CEC ! direct integration thanks to TuProlog •  REC ! integration via the SWI Prolog JPL API • Java takes care of •  Collecting events •  Deliver events to the reasoner •  Graphically draw the computed answer • Integrated inside the ProM 6 process mining framework •  Monitoring for operational decision support
  83. 83. Timings • Promising! •  ~400ms for dealing with the car rental example with •  32 events •  9 participants, 10 cars •  ~85 MVIs • Why? •  Reasoning is event-driven •  Events are completely ground!
  84. 84. Combining regulative and constitutive aspects A payment can be executed only if at least one item has been chosen. pay choose item sms receipt e-mail receipt null active satisfied violated discharge cancel (after 20 t.u.) create ConDec (flow) constraints Social CommitmentsEvents Effects After the payment, the customer cannot choose further items. When the payment is executed, the seller is committed to deliver a receipt within 20 t.u. A receipt can be delivered either by e- mail or via sms. C(seller,customer,receiptDelivered)
  85. 85. Conclusions •  First-order languages and metric temporal aspects are needed to capture commitments in a meaningful way •  Event Calculus is a good choice for •  Formalizing •  Reasoning about (extended) commitment-based specifications •  Reactive EC reasoners can be successfully employed for monitoring commitment-based interaction models
  86. 86. Ongoing and future work • Combine commitments and business constraints •  Integration of regulative and constitutive aspects in a unified framework • Individuate meaningful different classes of commitments •  In general •  That can be modeled in our framework !  Ontological analysis!!! • Further investigate how interacting agents could exploit the information produced by the monitoring framework
  87. 87. Time for questions!?!

×