ILIKS2010 - Montali - Monitoring Time-Aware Commitments

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

State of the art • Closed and procedural modeling abstractions

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

Flexibility with procedural approaches

Van der Aalst’s Spaghetti Models

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


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


active

CREATE

active active

Time aware commitments

active


active

CREATE

• Now the seller is committed to deliver the order within 2 days at most

Time aware commitments

active


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 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)


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.


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



1

great_car(c)

2

tick

active

great_car(c)

CREATE




1

great_car(c)

2

tick

active

great_car(c)

CREATE

3

break-down (c)




1

great_car(c)

2

tick

active

great_car(c)

CREATE

4 3

break-down (c)

tick


active



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



1 2

a

0


REC

KBdom

mvi(f,0,2)

f



c b 1 2 3 4 5 0


REC

KBdom

mvi(f,0,2)

f

a



c b 1 2 3 4 5 6 0


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

Time for questions!?!

Presentations & Public Speaking

ILIKS2010 - Montali - Monitoring Time-Aware Commitments