Post on 09-Jan-2017
transcript
MONITORING TIME-AWARE COMMITMENTS Marco Montali University of Bologna ILIKS 2010, Trento
Joint work with Federico Chesani, Paola Mello and Paolo Torroni
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
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
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
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
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
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
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
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
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
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
General Framework
Proof Theory and Reasoning Facilities
Logic-Based Framework
Logical Language
Commitment-based Interaction Model
Commitment Lifecycle Axiomatization
Commitment Language
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
How expressive should a C-Language be?
• The majority of current approaches adopts propositional (modal) logics for the formalization of (commitment-based) interaction models
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!
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
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)
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
Indefinitely active commitments
active
• 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
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
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!
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
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
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
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
Event Calculus Ontology
MVI for fluent f in (2,12]
a a c 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
• 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
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)),_).
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
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
• 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).
• 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).
• 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
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!
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
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.
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.
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
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))
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))
Handling compensations
rent-a-car (jan,ag,c)
1
great_car(c)
2
tick
active
great_car(c)
CREATE
4 3
break-down (c)
tick
c(ag,jan,prop(u(1,6),great_car(c))
active
Handling compensations
rent-a-car (jan,ag,c)
1
great_car(c)
2
tick
active
great_car(c)
CREATE
4 3
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
ECreactive
reasoningeffects 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
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
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)
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!!!
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
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
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 + +/-
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
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)
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
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.
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!
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/
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
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.
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
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
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.
Fclip
mvi
declip
Clip Events
H(event(E),T) /\ holds_at(F,T) /\ terminates(E,F,T) $ H(clip(F),T).
TE
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
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
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
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
Example • Let us consider the following EC specification
• KBdom: initially(f). terminates(a,f,T). initiates(b,f,T).
c b 1 2 3 4 5 0
SCIFF Proof Procedure
REC
KBdom
mvi(f,0,2)
f
a
Example • Let us consider the following EC specification
• KBdom: initially(f). terminates(a,f,T). initiates(b,f,T).
c b 1 2 3 4 5 6 0
SCIFF Proof Procedure
REC
KBdom
mvi(f,0,2), mvi(f,6,T) /\ T > 6
f
a b
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
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)
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”
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
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 !!!
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!
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
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)
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 !
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
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).
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)
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 t ts 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])).
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
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!
Combining regulative and constitutive aspects
A payment can be executed only if at least one item has been chosen.
paychooseitem
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)
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
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