Prospective Logic Agents

1. Prospective Logic Agents Luís Moniz Pereira Gonçalo Lopes

2. Broad Outlook • Logic programming (LP) languages and semantics enabling a program to talk about its own evolution through time are already well established.

3. Broad Outlook • Deliberative agents already have powerful means for extracting inferences, given their knowledge at time t. • How can they take advantage of an evolving logic program’s capabilities? • The idea: to logically model agents capable of making inferences based not only on their current knowledge, but on knowledge that they might expect to have at time t+n.

4. Broad Outlook • Agents can use abductive reasoning to produce hypothetical scenarios given partial observations from the environment and current knowledge, possibly subject to a set of integrity constraints.

5. Broad Outlook • The set of possible future scenaria can be exponentially large due to combinatorial explosion, so a means to efficiently prune the search space is required, a priori preferring some predictions over others.

6. Broad Outlook • Once possible scenaria are finally generated, a means to prefer a posteriori is also required, so that the agent can commit to a final choice of action. • The choices of the agent should of course be dynamically subject to revision, so that it may backtrack on previous assumptions and even change its preferences based on past experience.

7. Agent Cycle

8. Language • Let L be a first order language. A domain rule in L is of the form: A ← L1,...,Lt (t ≥ 0) • An integrity constraint is a rule of the form: ← L1,...,Lt (t > 0) • A is a domain atom in L, and L1,...,Lt are domain literals.  is a domain atom denoting falsity.

9. Language • A (logic) program P over L is a set of domain rules and integrity constraints, standing for all their ground instances. • Every program P has an associated set of abducibles A  L. • Abducibles are hypotheses which can be assumed to extend the theory, and therefore they do not appear in any rule heads of P.

10. Preferring Abducibles • Abducibles can have preconditions so that they can be considered, represented by the following rule: consider(A)  expect(A), not expect_not(A) • These preconditions represent domain-specific knowledge and are used a priori to constrain generation of abducibles.

11. Preferring Abducibles • Preferences between abducible literals can also be expressed via the binary relation ‘is more relevant than’, expressed by the operator : A  B  L1,...,Lt (t ≥ 0) • This relation has been extended to sets of abducibles in [pla07].

12. Prospective Logic Agents • The problem of prospection can be enounced in this framework as one of finding abductive extensions to the current knowledge theory of the agents which are both: • Relevant under the agent’s current goals • Preferred extensions w.r.t. the preference rules • The basic problem can be arbitrarily complicated by introducing belief revision requirements, utility theory, etc.

13. Goals and Observations

14. Observations • An observation is expressed as the quaternary relation: observe(Observer,Reporter,Observation,Value) • Observations can stand for actions, goals or perceptions. • A distinction should be made between goals (intentions) and desires.

15. Goals and Desires • A goal can be represented as an observation from the program to the program which must be proven true. • A desire can be represented as a possibility to fulfill a goal. We represent these by on_observe/4 literals, with a structure analogous to the observe/4 literals.

16. Goals and Desires • In any single moment, an agent can have a multitude of desires, but only some of them will actually become intentions. • We represent evaluation of an intention by the following rules: try(G)  G try(G)  not try_not(G) try_not(G)  not try(G)

17. Example: Tornado • Consider a scenario where weather forecasts have been transmitted foretelling the possibility of a tornado. • In case of emergency prevention, it is necessary to take action beforehand, proactively, so to increase the chances of success.

18. Example: Tornado • The following prospective logic program aims to deal with this scenario:   consider(tornado), not deal_with_emergency(tornado) expect(tornado)  weather_forecast(tornado) deal_with_emergency(tornado)  consider(decide_board_house) expect(decide_board_house)  consider(tornado)   decide_board_house, not boards_at_home, not go_buy_boards

19. Example: Tornado • The weather forecast implies that a tornado is expected and so the above program actually encodes two possible predictions about the future. • In one of the scenaria, the tornado is absent, but in the scenario where it is actually confirmed, the decision to board up the house follows as a necessity. • Scenaria generation can trigger goals, which in turn can trigger more scenaria generation.

20. Generating Scenaria

21. Generating Scenaria • Once the set of the agent’s active goals is known, possible scenaria can be found by reasoning backwards from the goals into abducibles under consider/1 literals. • Each abducible represents a choice: it can be assumed either true or false, meaning a combinatorial explosion of possible abducible values in a program.

22. Generating Scenaria • In practice, the combinations are contained and made tractable by a number of factors. • First, we consider only the relevant part of the program for collecting considered abducibles. • A priori preference rules and preconditions also rule out a majority of latent hypotheses, thus pruning the search space efficiently, using domain-specific knowledge.

23. Top-down consideration,Bottom-up generation • Considered abducibles are found by reasoning backwards from the goals. • However, assuming an abducible as true or false may trigger unforeseen side-effects on the rest of the program. • For this reason, scenario generation is obtained by reasoning forwards from selected abducibles to find relevant consequences.

24. Example: Emergencies • Consider the emergency scenario in the London underground [kowalski06], where smoke is observed, and we want to be able to provide an explanation for this observation. • Smoke can be caused by fire, and the possibility of flames should be considered. • But smoke could also be caused by tear gas, in case of police intervention.

25. Example: Emergencies • The tu literal stands for ‘true or undefined’. smoke  consider(fire) flames  consider(fire) smoke  consider(tear_gas) eyes_cringing  consider(tear_gas) expect(fire) expect(tear_gas)

26. Example: Emergencies   observation(smoke), not smoke observation(smoke) fire  tear_gas   flames, not observe(program,user,flames,tu)   eyes_cringing, not observe(program,user,eyes_cringing,tu)

27. Preferring a posteriori

28. Quantitative Preferences • Once each scenario’s model is known, there are a number of strategies which can be followed for choosing between them. • A possible way to achieve this is to use an utility theory to assign, in a domain-specific way, a numerical value to each scenario, which is computed during scenario generation and used as an element for choice a posteriori.

29. Qualitative Preferences • Numerical assessment of the value of each scenario can be effective in many situations, but there are occasions where a more qualitative expression of preference is desired. • This is the role of the moral theory presented in the figure. Related work [pereira07] explores this qualitative preference mechanism in more detail.

30. Exploiting Oracles • In both quantitative and qualitative cases, the possibility of acquiring additional information to make a choice is highly advantageous. • Prospective logic agents use the concept of oracles to access additional information from external systems (e.g. sensors, the user, etc.)

31. Exploiting Oracles • Queries to oracles are represented using the syntax for observations presented previously, in the form: observe(agent, oracle_name, query, Value)  oracle, L1,...,Lt (t ≥ 0) • Since oracles can be expensive to query, a principle of parsimony is enforced via the oracle literal, which is used as a toggle to allow/disallow queries to oracles.

32. Exploiting Oracles • Information obtained from the oracles can have side-effects in the rest of the program as well. • After the oracle step, it may be necessary to relaunch the procedure in order to reevaluate simulation conditions.

33. Consequences of Prospection • Even after all the strategies for choice have been used, more than a single desirable scenario may still remain. • In this case, we may have to iterate the procedure to incorporate additional information until we reach a fix-point. • Additionally, we may branch the simulation to consider a number of different possible scenarios in parallel.

34. Example: Automated Diagnosis • Consider a robotic gripper immersed in a collaborative assembly-line environment. • Commands issued to the gripper from its controller are updated to its evolving knowledge base, as well as regular readings from the sensor. • Diagnosis requests by the system are issued to the gripper's prospecting controller, in order to check for abnormal behaviour.

35. Example: Automated Diagnosis • When the system is confronted with multiple possible diagnosis, requests for experiments can be asked of the controller. The gripper can have three possible logical states: open, closed or something intermediate. The available gripper commands are simply open and close.

36. Example: Automated Diagnosis open  request_open, not consider(abnormal(gripper)) open  sensor(open), not consider(abnormal(sensor)) intermediate  request_close, manipulating_part, not consider(abnormal(gripper)), not consider(lost_part) intermediate  sensor(intermediate), not consider(abnormal(sensor)) closed  request_close, not manipulating_part, not consider(abnormal(gripper)) closed  sensor(closed), not consider(abnormal(sensor))  open, intermediate  open, closed  closed, intermediate

37. Example: Automated Diagnosis expect(abnormal(gripper)) expect(lost_part)  manipulating_part expect(abnormal(sensor)) expect_not(abnormal(sensor))  manipulating_part, observe(system,gripper,ok(sensor),true) observe(system,gripper,Experiment,Result)  oracle, test_sensor(Experiment,Result) abnormal(gripper)  abnormal(sensor)  request_open, not sensor(open), not sensor(closed) lost_part  abnormal(gripper)  observe(system,gripper,ok(sensor),true), sensor(closed) abnormal(gripper)  lost_part  not (lost_part  abnormal(gripper))

38. Example: Automated Diagnosis • In this case, there is an available experiment to test whether the sensor is malfunctioning, but resorting to it should be avoided as much as possible, as it will imply occupying additional resources from the assembly-line coalition.

39. Implementation • The presented system has already been implemented using working state-of-the-art logic programming frameworks. • XSB Prolog was used for the Well-Founded, top-down, abductive semantics. • Smodels was used for the Stable Models, bottom-up, scenaria generation semantics.

40. Prospecting the Future • Both [kowalski06] and [poole00] represent candidate actions by abducibles and use logic programs to derive possible consequences, to help in deciding between them. • However, they do not derive consequences of abducibles that are not actions, such as observations for example. Nor do they consider how to determine the value of unknown conditions (e.g. by using an oracle).

41. Prospecting the Future • Compared with Poole and Kowalski, one of the most interesting features of our approach is the use of Smodels to perform a kind of forward reasoning to derive the consequences of candidate hypotheses. • These consequences may then lead to a further cycle of abductive exploration, intertwined with preferences for pruning and for directing search.

42. Prospecting the Future • A number of additional challenges still need to be addressed, however, in order to allow the system to be able to scale up to scenarios of greater complexity. • Branching update sequences need to be extended to handle an arbitrary length in future lookahead. • Preferences over observations are also desirable, so that agents can best select over which oracles to query during prospection.

43. Prospecting the Future • Prospective agents could use abduction not only to find the means to furtheir their own goals, but to abduce the goals and intentions of other agents. • Prospection over the past is also of interest, so to gain the ability to perform counterfactuals in order to increase performance in future tasks.

44. Bibliography (excerpt) • [pereira07] - L. M. Pereira and A. Saptawijaya, Modelling Morality with Prospective Logic, 2007 • [kowalski06] – R. Kowalski, The Logical Way to be Artificially Intelligent, 2006 • [poole00] – D. Poole, Abducing Through Negation as Failure: Stable models within the independent choice logic, 2000 • [pla07] - L. M. Pereira, G. Lopes and P. Dell’Acqua, Pre and Post Preferences over Abductive Models, 2007