AAMAS 2014 - Montali - Verification of Data-Aware Multiagent Systems

Veriﬁcation of Data-Aware
Commitment-Based Multiagent Systems
Marco Montali
KRDB Research Centre for Knowledge and Data
Free University of Bozen-Bolzano
Joint work with Diego Calvanese and Giuseppe De Giacomo
AAMAS 2014
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 1 / 22

Data-Awareness in Dynamic Systems
Traditional approach to model dynamic systems: divide et impera of
• static, data-related aspects
• dynamic, process/interaction-related aspects.
Notable examples:
• In BPM: data and business processes are conceptually isolated from each
other, and only integrated at the implementation level.
• In MAS: a plethora of logics for reasoning about the behavior of agents and
their interaction, but completely neglecting the exchanged information.
No coherent understanding of what the system is doing.
Our ultimate goals
1 Provide formal models that simultaneously account for the system
dynamics and the manipulation of data.
2 Devise logic-based techniques for the veriﬁcation and monitoring of
such integrated systems.
This combination poses major challenges to veriﬁcation.

Social Commitments
Semantics for agent interaction that abstracts away from the internal
agent implementation.
• Seminal work by Castelfranchi: social commitments as a mediation between
the individual and its “normative” relation with other agents.
• Extensive work by Singh et al.: commitments for the ﬂexible speciﬁcation of
protocols, contracts, interorganizational business processes.
Conditional commitment
cc(d, c, qp, qd)
Debtor agent d commits towards creditor agent c that, whenever condition
qp holds, it will bring about condition qd.
Example (Delivery upon payment)
cc(john, alice, item paid, item owned by alice)
The establishment of (conditional) commitments is typically regulated by a
global contract.

Social Commitments: Critical Assessment
+ Flexibility
• In terms of events: commitments are about
properties/eﬀects of events, not about events directly.
• In terms of interaction: evolution of commitments
determined by the involved agents, through explicit and
implicit operations (commitment machine). [Singh et al., IEEE Comp. 2009]
– Expressiveness
• Atoms of commitment (pre)conditions are usually propositions.
• No possibility of tracking multiple evolutions of the same type of
commitment between the same pair of agents.
• No distinction between commitments and their instances.
John commits for “delivery upon payment” with Alice, vs.
Alice paid item i1, hence John is committed towards the delivery of i1.
• Cf. work by Ferrario et al. on formal modelling of services and commitments.

Making Commitment-Based MASs Aware of Data
To solve the expressiveness issues, we propose to make commitment-based
MASs data-aware. This requires:
• To explicitly account for the data maintained by agents, and the
knowledge used to structure it.
• To deﬁne how agents query and update such data in response to
events, possibly introducing fresh data into the system.
• To extend messages/events with their data payload.
• To lift contracts, commitments, and commitment machines to
ﬁrst-order: each component will employ queries over the data.

The DACMAS Framework
Global TBox
CBox
Contract
Institutional agent
Proprietary ABox
Speciﬁcation
Event

Data Model
We use of a lightweight Description Logic ontology language: DLR-Lite.
Global TBox:
• Provides a common ground for agent interaction
• Models concepts and relations of any arity (shared vocabulary)
• Supports inheritance, disjointness, and key constraints (shared
semantic constraints).
Captures most constructs of conceptual modeling languages (UML).
Local, proprietary ABoxes:
• Each agent maintains and evolves its own ABox (nobody can directly
modify the data of another agent).
• Stored objects are from a countably infinite domain ∆.
• A special institutional agent keeps track of system-related data:
(Variable) set of names of all agents currently part of the system.
Immutable set of agent (behavioral) specifications.
Connection between each agent and its current specification.
Data about the current status of contracts.

Querying Data
Typical query language for DL ontologies: union of conjunctive queries
(UCQs).
• Correspond to select-project-join queries in SQL.
• Evaluated using the certain answer semantics (agents have
incomplete information).
We consider two extensions:
• ECQ FOL queries whose atoms are UCQs.
• ECQ location argument to disambiguate where the query has to
be posed.
Example
Item@John(i) ∧ Paid@John(i, Alice) ∧ Owns@Alice(i)
Important: ECQ enjoys ﬁrst-order-rewritability.
• Query answering can be reduced to query evaluation in standard
DBMS technology, by compiling away the TBox.
• All our results hold also in a purely relational database setting with
constraints.

Agent Speciﬁcation
Regulate the agent behavior in a data-driven, declarative way.
Proactive behavior: communicative rules
1 Determine which messages with payload can be sent.
2 Choose which to send.
Reactive behavior: update rules
1 Conditionally react to an incoming/outgoing message by invoking an
update action.
2 Apply the update action by modifying the local ABox, possibly
introducing fresh data (taken from ∆).
At each step: inﬁnitely many choices in general!

Communicative Rules
Shape
Q(r, x) enables ev(x) to r
Semantics:
• Normal agent: issues a query over its own ABox + that of the
institutional agent.
• Institutional agent: could read all ABoxes.
• Each obtained answer grounds the payload of the message and the
destination agent.
This determines a possible outgoing message.
Example
Customer speciﬁcation: registration request to a seller.
Spec@inst(sel, seller) enables req reg to sel
Seller speciﬁcation: item proposal to a customer.
MyCust(m) ∧ Item(i) enables propose(i) to m

Update Rules
Shape
• on ev(x) to r if Q(r, x) then α(r, x) (on-send)
• on ev(x) from s if Q(s, x) then α(s, x) (on-receive)
• on ev(x) from s to r if Q(s, r, x) then α(s, r, x) (on-exchange)
Semantics:
• Upon an incoming/outoing message, evaluate whether the payload +
sender/receiver satisfy a condition.
• If so, apply the update action α with paramaters the payload +
sender/receiver.
Example
Seller reaction to “empty cart” request:
on empty cart req from c if MyCust(c) then doEmpty(c)
Seller reaction to the presence of a new item:
on new item(i) from p if MyProv(p) ∧ ¬Item(i) then addItem(i)

Update Actions
Shape
α(p) : {e1, . . . , en}. Each update eﬀect e has the form:
[q+
(p, x)] ∧ Q−
(p, x) add A, del D
where:
• A is a set of facts to be added, possibly including Skolem terms.
• D is a set of facts to be deleted.
• Like in STRIPS: add wins over delete.
Semantics:
• Pose all eﬀect queries in parallel.
• For each answer substituting x, ground the facts in A and D.
• Substitute each ground Skolem term in A with an actual value from
∆ agent choice!
• Modify the ABox by deleting and adding the corresponding ground
facts, provided that the resulting ABox is consistent with the TBox.

Update Actions - Examples
Example (Empty Cart)
on empty cart req from c if MyCust(c) then doEmpty(c)
where: doEmtpy(c) : {[InCart(i, c)] del{InCart(i, c)}}.
Example (Item Addition)
on new item(i) from p if MyProv(p) ∧ ¬Item(i) then addItem(i)
where: addItem(i) : {[true] add{Item(i), Price(i, p(i))}}

Contractual Specification
Shape
Set of commitment rules of the form:
on ev(x) from s to r if Qc(s, r, x)
then ccn(s, r, [q+
p (s, r, x, y)]∧Q−
p (s, r, x, y), Qd(s, r, x, y))
Semantics: when ev is sent from a to b with actual payload d. . .
• If the boolean query Qc(a, b, d) is satisfied, an instance of conditional
commitment n is created between a and b, with payload d.
• Instance manipulated through a first-order commitment machine:
Explicit operations: delegation, cancelation, . . .
Implicit operations: handled by the institutional agent when the
precondition and condition becomes true.
Whenever the partially ground precondition is satisfied with substitution
v for y, a base-level instance is created for n with payload d, v.
When the ground condition Qd(a, b, d, v) is brought about, then such
base-level instance is discharged.
Explicit manipulation of base-level instances allowed, leading them to
different states.

Execution of Commitment Machines
on accept reg from s to c if MyCust@s(c)
then ccDelivery(s, c, [Item@s(i)∧Paid@s(i, c)], Owns@c(i))
Key Issues
1 How to keep track of commitment instances and their state?
2 How to evolve such information according to the ﬁrst-order
commitment machine rules?
3 Who is in charge of this?

Commitment Box
Special relations obtained from the contractual speciﬁcation.
For each conditional commitment:
• One relation for its instances, keeping track of debtor/sender,
creditor/receiver, payload.
• One relation for the instances of its base-level version, keeping track
also of the extended payload and the commitment state (active,
satisﬁed, violated, . . . ).
Extension of relations: managed by the institutional agent, accessible by
everybody.
Example
ccDelivery(s, c, [Item@s(i)∧Paid@s(i, c)], Owns@c(i))
leads to:
• DeliveryCC(debtor, creditor);
• DeliveryC(debtor, creditor, state, item).

From Contracts to On-Exchange Rules
Making commitments operational:
• On-exchange rules automatically generated from the contractual
speciﬁcation and the semantics of commitment machines.
Note: no detach of conditional commitments anymore!
• The institutional agent is responsible for their execution.
CC creation rule:
on accept reg from s to c if MyCust@s(c)
then create DeliveryCC(s, c)
create DeliveryCC(s, c) : {[true] add{DeliveryCC(s, c)}}
C creation and discharge (triggered for any exchanged event):
createC(d, c) : {[DeliveryCC(d, c) ∧ Item@d(i) ∧ Paid@d(i, c)]
add{DeliveryC(d, c, active, i)}}
dischargeC(d, c) : {[DeliveryC(d, c, active, i)] ∧ Owns@c(i)
add{DeliveryC(d, c, sat, i)}, del{DeliveryC(d, c, active, i)}}

Sample System Run
Seller John
Customer Alice
Name
MyCust
Alice
Bob
ID
Item
i1
i2
Item
Paid
Cust
Institutional agent D.
DeliveryCC
C.
DeliveryC
Item
ACCEPT-REG
JohnAlice
Item
Owns
PAY-CC(i1)
Item
Paid
Cust
i1 Alice
D. C. State
D.
DeliveryCC
C.
DeliveryC
Item
JohnAlice
D. C. State
i1JohnAlice active
PAY-BT(Alice, i2)
Item
Paid
Cust
i1 Alice
D.
DeliveryCC
C.
DeliveryC
Item
JohnAlice
D. C. State
i1JohnAlice active
Alice's Bank
i2JohnAlice active
i2 Alice
deliver(i1,...)
Item
Paid
Cust
i1 Alice
D.
DeliveryCC
C.
DeliveryC
Item
JohnAlice
D. C. State
i1JohnAlice sat
Carrier
i2JohnAlice active
i2 Alice
Item
Owns
i1
Item
Owns
Item
Owns

Execution Semantics
Infinite-state transition system with states labelled by agent ABoxes.
Loop forever:
1 Pick a sender agent from the table maintained by the institutional agent.
2 Eval all its communicative rules and generate enabled outgoing messages.
3 Pick one of such messages.
4 Manage the synchronous reaction of sender, receiver, and institutional agent,
evaluating their update rules and applying the obtained update actions.
If Skolem terms are involved, pick a value for each of them.
5 If all resulting ABoxes are consistent with the TBox, generate the successor,
otherwise roll-back.
...
. . .
...
. . .
...
. . .
. . .
Three sources of infinity/unboundedness:
• Infinite branching (value choice for Skolem terms).
• Infinite runs (Usage of such values in ABoxes).
• Unbounded ABoxes (accumulation of such values).

Verification
Requirements for temporal/dynamic properties:
• to capture data first-order queries;
• to capture dynamics temporal modalities;
• to capture evolution of data quantification across states.
We employ µL
ECQ
p , a first-order variant of µ-calculus:
• to capture data ECQ queries;
• to capture dynamics least and greatest fixpoints.
µ-calculus subsumes LTL, CTL, CTL∗
.
• to capture evolution of data quantification over objects/agents
that persist over time in the active domain.
Example (Delivery commitments are honored for gold customers)
νZ.(∀s, c, i.DeliveryC(s, c, active, i) ∧ MyGoldCust@s(c)
→ µY .(DeliveryC(s, c, sat, i)) ∨ (live(s, c, i) ∧ − Y )) ∧ [−]Z

Key Results
Already for a DACMAS with a single agent, it is undecidable to check
propositional reachability properties.
State boundedness
Each state of the system contains only bounded number of objects and agents.
The system has still infinite branches and infinite runs.
• Unboundedly many objects/agents can be encountered along a run,
provided that they are not accumulated in the same state.
Theorem
Verifying state-bounded DACMASs against µL
ECQ
p properties is
decidable and reducible to finite-state model checking.
Proof.
Reduction to Data-Centric Dynamic Systems [PODS2013], compiling away locations
and the global TBox.

Conclusion and Future Work
DACMAS is a rich framework for modelling data-aware MASs and track
data-aware contracts based on commitments.
• Modelling: paves the way towards a refined theory of commitments
where data are fully taken into account.
• Executability: readily implementable (e.g., in JADE).
Each execution step is in LOGSPACE w.r.t. the agent data.
• Verification: allows in principle to rely on standard model checkers.
Important observations:
• Results immediately extendible to asynchronous lossless
communication with bounded queues/sets.
• State-bounded DACMASs can also be verified against full CTL-FO
with epistemic modalities (cf. [Belardinelli et al., KR 2012]).
Ongoing and next steps:
• Connection with the work on formal ontology for services.
• Fully distributed management of commitments, without relying on the
institutional agent.
• Distributed monitoring and lossy interaction.

AAMAS 2014 - Montali - Verification of Data-Aware Multiagent Systems

More Related Content

Similar to AAMAS 2014 - Montali - Verification of Data-Aware Multiagent Systems (20)

More from Faculty of Computer Science - Free University of Bozen-Bolzano (20)

Recently uploaded (20)

AAMAS 2014 - Montali - Verification of Data-Aware Multiagent Systems