J

1
IMPACT Agent Implementation

• Jürgen Dix
• University of Maryland/ University of Koblenz
• joint work with
• Thomas Eiter (TU Vienna),
• VS Subrahmanian (Maryland)

1
2
Algorithms

• Run-time
• compute status set.
• trigger actions.
• incrementally compute status set (algorithm
  developed, not implemented).

• Compile time
• check syntax
• check regularity
• 1 conflict freedom
• 2 strong safety
• 3 deontic stratification
• 4 boundedness
• unfold out agent program.
• Compute initial status set.

3
1 Conflict freedom

• EXAMPLE
• Consider the following two non
• ground rules
• FmaintainCourse(NoGo,Route,Loc) ? ccc1 , Do
  action1
• OmaintainCourse(NoGo,Route,Loc) ? ccc2
  , F action2,
• Both can be conflict-free (depending on ccc1,
  ccc2 being true in the state) or not.

• Two ground rules Head1?Body1 Head2?Body2 conflict
  in a state iff
• the heads of the two rules conflict, and
• cccs in the bodies of the rules are true in the
  state, and
• ? deontically consistent status set that makes
  the action literals in the bodies true.
• THEOREM Checking conflict freeness is
  undecidable.
• Developed 4 different sufficient conditions if
  satisfied, they all guarantee that underlying
  set of rules is conflict free.

4
Conflict freedom performance

• 1. Sufficient Condition

• 2. Sufficient Condition

0.02 sec
0.008 sec
Even for many actions, it is fast.
Even for many arguments, it is fast.
5
Algorithms

• Run-time
• compute status set.
• trigger actions.
• incrementally compute status set (algorithm
  developed, not implemented).

• Compile time
• check syntax
• check regularity
• 1 conflict freedom
• 2 strong safety
• 3 deontic stratification
• 4 boundedness
• unfold out agent program.
• Compute initial status set.

6
Safety

• Safety is a condition on code call conditions
  that ensures that the code call condition is
  evaluable.
• We developed a provably sound and complete
  algorithm for testing safety.
• EXAMPLE
• The code call condition
• in(RP, terraingetPlan(P1,P2,Vehicle))
  
  in(RP, terraingetPlan(P2,P3,Vehicle))
  
  in(P3, coordnextPoint(P1,P2,Goal))
• is safe, if P1,P2,Vehicle, Goal are given
  Reorder the ccc!

7
2 Strong safety

• Strong safety requires not only that queries are
  executable, but that their evaluation terminates
  in finite time.
• The executable code call condition
• in(X, mathgeq(25)) in(Y,
  mathsquare(X)) Y lt 2000
• if executed left-to-right does not terminate.
• If reordered, it does it is strongly safe.
• There is no finiteness-checking! Solution
  Specifying in AgentDE infiniteness table
  listing all code calls returning infinite answers.

• Developed a provably correct algorithm to
  polynomially check strong safety of a ccc.
• Table lists code calls and a binding pattern for
  the variables involved mathgeq(X) ()
  mathfct(X,Y,Z) (X,,Z) Xgt5
  Zlt3
• Modification of the safety algorithm Safety
  Look-up in Table. (Linear in size(ccc) linear
  in size(table) .)

8
Example/Performance of (strong) safety

• EXAMPLE Code call
  condition ccc with up to 20 conjuncts.
• Each point in the graph (fixed of conjuncts) is
  the result of
• do 1000 runs by varying of arguments, of
  variables (generate ccc randomly) and take the
  average run time.
• Result safe_ccc is extremely fast. Suggests that
  safety checking for programs containing 1000
  rules can be done in 20-40 milliseconds

0.046
20 conj.
9
Algorithms

• Run-time
• compute status set.
• trigger actions.
• incrementally compute status set (algorithm
  developed, not implemented).

• Compile time
• check syntax
• check regularity
• 1 conflict freedom
• 2 strong safety
• 3 deontic stratification
• 4 boundedness
• unfold out agent program.
• Compute initial status set.

10
3 Deontic stratification

• This is a complex condition requiring that an
  action not be defined negatively in terms of
  itself.
• EXAMPLE
• Do compute(Loc) ? Do compute(Loc) , misc1
• Do compute(Loc) ? Do something(P), misc2
  Do
  something(P) ? Do compute(Loc), misc3
• Do compute(Loc) ? O compute(Loc) , misc4
  
• But the following is harmless
  
  Do compute(Loc) ? F compute(Loc) , misc4
  
• A deontically stratified program comes in
  finitely many strata, negative dependencies lead
  to strictly lower strata.

11
Deontic stratification

• We developed a polynomial algorithm to evaluate
  deontic stratifiability.
• Graph based approach.
• Algorithm is provably correct and performs well.
• Performance results on the right.

0.26sec
Number of rules 200
12
Regular Agent

• A regular agent program is one that is
• 1 conflict free
• 2 strongly safe
• 3 deontically stratifiable
• 4 unfoldable (see next slide)
• Regular agents require that all components of the
  agent satisfy an appropriate mix of the above
  conditions (e.g., integrity constraints must have
  strongly safe bodies, etc.).
• THEOREM Every regular agent has a unique
  rational status set.
• THEOREM The data complexity of computing the
  above rational status set is polynomial (under
  appropriate assumptions).

13
Algorithms

• Run-time
• compute status set.
• trigger actions.
• incrementally compute status set (algorithm
  developed, not implemented).

• Compile time
• check syntax
• check regularity
• 1 conflict freedom
• 2 strong safety
• 3 deontic stratification
• 4 boundedness
• unfold out agent program.
• Compute initial status set.

14
4 Boundedness

• Consider the program
• Do com(Loc) ? Do some(P), ccc1
  Do some(P) ? Do else(Loc), ccc2
• Do else(P) ? ccc3
• and let ccc3 be false in the state.
• Instead of checking Do-actions at run-time
• we simplify the program at compile time into
• Do com(Loc) ? ccc3, ccc2, ccc1
  Do some(P) ? ccc3, ccc2
• Do else(P) ? ccc3
• Replace successively in all rules the positive
  action atoms in the bodies.
• Boundedness If, eventually, all positive body
  atoms disappear larger but simpler program.

• We developed a provably correct polynomial (under
  suitable conditions) algorithm to unfold agent
  programs.
• Run-time Computation Start with those
  rules whose bodies contain only cccs or negative
  action status atoms.

15
Unfolding Performance

• No detailed study yet (not enough agent programs
  available, not clear how to vary large number of
  parameters).
• Sample Program Logistics demo based on US Army
  War Reserves data.
• Unfolding 0.82 sec (17 rules
  transformed into 30)

16
Status Set Computation

• For regular agent programs, we have developed an
  algorithm that takes the result of the unfolding
  step as input, and produces as output, a rational
  status set.
• This algorithm has been implemented and performs
  well.
• Status Set 39 sec
• Note massive amounts of data resident in flat
  (unindexed) Oracle files were accessed and
  network time (33 sec) is included.
• Status Set 6 sec 33 sec

• We have developed an incremental algorithm that
  takes as input
• a feasible status set St at time t
• a set of changes at time t
• and returns as output,
• a feasible status set St1 which incorporates
  the changes.
• Not yet implemented, but we expect to decrease
  even the network time.

17
Research to be Performed

• Optimized unfolding once the table of
  (Op,Action,CCC) triples is constructed, we must
  create a CCC-evaluation plan that merges common
  parts of different triples in this table.
• Caching strategies if an agent has a cache of
  size S available to it, what views of remote data
  should be cached there so as to optimize run-time
  computation?
• Cost-based feasible status sets how can the
  algorithms for feasible status set computation be
  extended to compute status sets that optimize an
  objective function? How can we extend our
  implementation to support this?