COMMITMENTS FOR ORGANIZATIONS: DEALING WITH INCONSISTENCIES

COMMITMENTS FOR ORGANIZATIONS: DEALING WITH INCONSISTENCIES Shameem Shah Nawaz Supervised by: Asst. Prof. Dr. Pınar Yolum

Outline • Technical Background • Addition of Time • Conflict Detection • Conflict Scenarios • Resolving Conflicts • Higher Level View of Organizations • Software Demo

Motivation • representing interactions among agents in multiagent organizations • using commitment-based approach • detecting and resolving conflicts • generating higher level views of interactions • desiging and developing a software tool

Technical Background • Commitment • is a promise or an obligation • expressed as CommitmentId(debtor, creditor, proposition) • an example commitment: Ci(Employee 1, Manager, Produce Toys) • Operations on Commitments • Create – can only be created by debtor • Cancel – can only be cancelled by debtor • Release – can only be released by creditor • Assign – can only be assigned by creditor • Delegate – can only be delegated by debtor • Discharge – satisfies a commitment

Technical Background - Commitment Graph C1(Emp1, Supervisor, Produce) {cancel, discharge} C2(Emp1, Manager, Produce) {cancel, discharge , assignto Supervisor} Step1: RC & D nodes are created D RC

Technical Background - Commitment Graph C1(Emp1, Supervisor, Produce) {cancel, discharge} C2(Emp1, Manager, Produce) {cancel, discharge , assignto Supervisor} Step2: For each commitment a new node and edges are created iteratively. C1 D RC

Technical Background - Commitment Graph C1(Emp1, Supervisor, Produce) {cancel, discharge} C2(Emp1, Manager, Produce) {cancel, discharge , assignto Supervisor} Step2: For each commitment a new node and edges are created iteratively. C1 D RC C2

Technical Background • Resolvable Commitment • can either be released or cancelled or discharged • or has an edge to another resolvable commitment • Conflicts among Commitments C1(Emp1, Supervisor, Produce) {discharge} C2(Emp1, Supervisor, Not Produce) {discharge} • Set of Conflicting Commitments

Addition of Time • Importance • Time Point • discrete moment in time • two special time points, tb & te • Time Interval – bounded by two time points • Transition Point – where propositions reverse smoothly • Time Quantifier • Existential • Universal

Addition of Time • Time Model • Binding Commitments with Time • CommitmentId(debtor, creditor, proposition) [Time Bound] Time Quantifier • example: Ci(Employee 1, Manager, Produce Toys) [ Today ] E • Conflicts among Time-bound Commitments tb t0 t1 t2 t3 t4 t5 te

Conflict Detection • Conflicting Commitments given Time-bounds • consider time while detecting conflicts • conflict when time is not considered C1(Emp1, Supervisor, Produce){discharge} C2(Emp1, Supervisor, Not Produce){discharge} • still in conflict after adding time C1(Emp1, Supervisor, Produce) [ Today ] E{discharge} C2(Emp1, Supervisor, Not Produce) [ Today ] U {discharge} • no longer in conflict if time intervals do not overlap C1(Emp1, Supervisor, Produce) [ Today ] E{discharge} C2(Emp1, Supervisor, Not Produce) [ Tomorrow ] U {discharge}

Conflict Detection • Conflict Types • Certain C1(Emp1, Supervisor, Produce) [ Today ] E{discharge} C2(Emp1, Supervisor, Not Produce) [ Today ] U {discharge} • Possible C1(Emp1, Supervisor, Produce) [ Today ] E{discharge} C2(Emp1, Supervisor, Not Produce) [ Today ] E {discharge} • Unrealistic Commitments • not in conflict but depends on other commitments C1(seller, customer, sell toys)[ Today ] E{discharge} C2(producer, seller, produce toys)[ Today ] E {discharge}

Conflict Scenarios • Non-overlapping Time Intervals • Identical Time Intervals C2 C1 t0 t1 t2 t3 t4 C2 C1 t0 t1 t2 t3 t4

Conflict Scenarios • Containing Time Intervals • Intersecting Time Intervals C2 C1 t0 t1 t2 t3 t4 C2 C1 t0 t1 t2 t3 t4

Resolving Conflicts • Discarding a Commitment • simplest way; eliminate erroneous commitment • Modifying a Commitment • Delegate to a different debtor • Assign to a different creditor • Shifting Time Bounds • such that time bounds do not overlap • Using Constraints • such that conflicting commitments do not have to be valid at the same time

An Example Scenario of Conflict Resolution Commitments: C1(x, y, pass through the door)[1:00pm – 1:10pm] E C2(y, x, open the door) [12:59pm – 1:09pm] E C3(x, y, close the door) [1:00pm – 1:11pm] E • C2 and C3 are possibly in conflict between 1:00pm – 1:10pm • eliminate commitment C3? • fairly distributing the time between C2 and C3 ? • shift the time bound of commitment C3? • using a constraint (C2 < C3) such that C3 is valid only when C2is satified?

Higher Level View of Organizations • Aggregation on Time • debtor, creditor and proposition same • time intervals are consecutive C1(producer, seller, produce) [ Jan ] C2(producer, seller, produce) [ Feb ] C3(producer, seller, produce) [ Mar ] ULC1(producer, seller, produce) [ Q1 ] C1 C2 C3 ULC1 Jan Feb Mar Jan Feb Mar

Higher Level View of Organizations • Grouping Agents • same proposition and time interval • group composition known beforehand C1(producer 1, seller, produce) [Q1] C2(producer 2, seller, produce) [Q1] C3(producer 3, seller, produce) [Q1] ULC1(group of producers, seller, produce)[Q1] P1 C1 C2 ULC1 P2 S Group of Producers Seller C3 P3

Higher Level View of Organizations • Conceptually Upper Level Commitments • base level commitments are part of an upper level concept C1(professor, department, prepare course outline) [ beginning of term ] C2(professor, department, give lectures) [ along term ] C3(professor, department, evaluate students) [ end of term ] ULC1(professor, department, offer a course) [ term ]

Higher Level View of Organizations • Aggregation on Transitivity of Commitments • inherent transitive relations C1(x, y, pay $100) [ t1 – t2 ] C2(y, z, pay $100) [ t2 – t3 ] ULC1(x, z, pay $100) [ t1 – t3 ] • aggregation may cause low level data loss • designer should decide whether to proceed with aggregation x x t1 C1 y t2 ULC1 C2 t3 z z

Software Tool Architecture • developed in Java • commitment protocol specified in XML • time model • commitments • constraints • when fed with XML specification • commitment graph is created • conflicts detected • help is provided on conflict resolution • upper level commitments are created

Software Tool Demo • OrgL – larger organization • OrgS – smaller organization GM Pr Is Es In E_Pr_1 E_Pr_2 E_Is E_Es E_In GM Pr E_Pr_1 E_Pr_2

Literature • Fornara and Colombetti • a method for agent communication • based on social notion of commitments • no mention of inconsistency • no time frame for commitments • Artikis et al. • develop a framework to animate computational societies • set of agents, roles, constraints, etc characterize a society • event calculus is used to represent the concepts of a society • no design rules to establish the correctness of societies

Discussion • Summary • added the concept of time with commitments • extended the algorithm to detect conflicts • developed ways to resolve conflicts • generated ways to present higher level views • Future Directions • verify protocol in run time • incorporate state transitions • process quantifiable information in propositions • employ AI techniques to suggest how to resolve conflicts

Algorithm 1Build-commitment-graph(CS, O) 1: Create a node RC 2: Create a node D 3: possible-commitments = CS 4: while (possible-commitments != ) do 5: Remove a commitment c 6: Add a new node c to V 7: fori = 1 to |O(c)| do 8: if (O(c)[i] == delegate) then 9: Add a new node c.delegate to V 10: Add (c, c.delegate) to E 11: Add c.delegate to possible-commitments

Algorithm 1Build-commitment-graph(CS, O) 12: elseif (O(c)[i] == assign) then 13: Add a new node c. assign to V 14: Add (c, c. assign) to E 15: Add c. assign to possible-commitments 16: elseif (O(c)[i] == release) || (O(c)[i] == cancel) then 17: Add (c, c.RC) to E 18: elseif (O(c)[i] == discharge) then 19: Add (c, c.D) to E 20: end if 21: endfor 22: end while

Algorithm 2Color-graph(G) 1: visited =  2: whiteList =  3: blackList =  4: fori = 1 to |V| do 5: if (V(i)  visited) then 6: visit(V(i)) 7: endif 8: endfor

Algorithm 3visit(u) 1: Add u to visited 2: if (u.adjacentTo(D OR RC)) then 3: Add u to whiteList 4: elseif (u.hasNeighbors()) then 5: while (u whiteList) AND (THERE EXIST E(u, v) : v visited) do 6: if (v visited) then 7: visit(v) 8: endif

Algorithm 3visit(u) 9: if (v whiteList) then 10: Add u to whiteList 11: else 12: Add u to blackList 13: endif 14: endwhile 15: else 16: Add u to blackList 17: endif

Algorithm 4Check-consistency(G) 1: inconsistentList =  2: fori = 1 to |V| - 1 do 3: forj = i + 1 to |V| do 4: Determine if V(i) and V(j) are conflicting 5: if conflicting(V(i) and V(j)) then 6: if NOT EXIST(E(V(i)), RC) AND NOT EXIST(E(V(j)), RC) then 7: Add V(i) and V(j) to inconsistentList 8: end if 9: end if 10: end for 11: end for

Algorithm 5Detect-CPT(SCP) 1: conflictGivenTimeList =  2: noConflictGivenTimeList =  3: fori = 1 to |SCP| do 4: Compare time intervals of SCP[i] 5: if (time intervals overlapping) then 6: Add SCP[i] to conflictGivenTimeList 7: else 8: Add SCP[i] to noConflictGivenTimeList 9: end if 10: end for

Technical Background - Commitment Graph C1(Emp1, Supervisor, Produce) {cancel, discharge} C2(Emp1, Manager, Produce) {cancel, discharge , assignto Supervisor} C3(Emp2, Supervisor, Produce) {} Step2: For each commitment a new node and edges are created iteratively. C1 D RC C3 C2

Technical Background - Commitment Graph C1(Emp1, Supervisor, Produce) {cancel, discharge} C2(Emp1, Manager, Produce) {cancel, discharge , assignto Supervisor} C3(Emp2, Supervisor, Produce) {cancel, delegate to Emp1} Step2: For each commitment a new node and edges are created iteratively. C1 D RC C3 C2

Transition Point • specify a time point when a proposition reverses • but both the proposition and its reverse are not valid at the same time • a proposition is valid until tp- • and its reverse is valid from tp+ tp t-p t+p tb te

Types of Proposition • Cumulative • accumulation is significant • ex., paying $100 – two same proposition would mean paying $200 • organization state always changes whenever a cumulative proposition is satisfied • Repetitive • accumulation is insignificant • ex., turning a light on – two same propositions would mean turning on the same light twice • organization state may not change when a repetitive proposition is satisfied more than once

COMMITMENTS FOR ORGANIZATIONS: DEALING WITH INCONSISTENCIES