1. ACORDA for Prospective Logic Programming Luís Moniz Pereira Gonçalo Lopes CENTRIA – UNL, Portugal h.c. workshop T.U. Dresden, 5 Dec 2006

2. The Evolution of Logic Programming (LP) - 1 Computational logic has evolved to meet the challenges of non-monotonic reasoning in order to represent knowledge which is all of: Computational logic has evolved to meet the challenges of non-monotonic reasoning in order to represent knowledge which is all of: IncompleteIncomplete ContradictoryContradictory RevisableRevisable Dynamic vs. StaticDynamic vs. Static

3. The Evolution of Logic Programming - 2 Programs reason with incomplete knowledge Programs reason with incomplete knowledge Programs revise their knowledge in face of contradiction Programs revise their knowledge in face of contradiction Programs self-update and evolve to become different Programs self-update and evolve to become different Programs can have several distinct futures Programs can have several distinct futures

4. Challenges for reasoning in LP New challenges are emerging from these LP capabilities: New challenges are emerging from these LP capabilities: What is the best evolution for such a program?What is the best evolution for such a program? How can a program simulate and reason about future states?How can a program simulate and reason about future states? How can a program decide and prefer one future state over another?How can a program decide and prefer one future state over another? What practical problems can such systems solve? What practical problems can such systems solve?

5. Differential Diagnosis (DD) - 1 In medicine, DD is the systematic method used to identify diseases: In medicine, DD is the systematic method used to identify diseases: The physician observes the patient’s symptoms, medical history and available examinationsThe physician observes the patient’s symptoms, medical history and available examinations The most likely causes are then listedThe most likely causes are then listed The physician performs additional examinations and tests in order to defeat the relevant possibilities and obtain the single most likely diagnosisThe physician performs additional examinations and tests in order to defeat the relevant possibilities and obtain the single most likely diagnosis

6. Differential Diagnosis - 2 The knowledge of the physician evolves as more information is gathered about the patient The knowledge of the physician evolves as more information is gathered about the patient The physician is able to abduce (hypothesize) the most likely causes from his medical knowledge The physician is able to abduce (hypothesize) the most likely causes from his medical knowledge Analysis of hypotheses and diagnostic preferences lead to further examinations and, hopefully, to the most logical choice for a diagnosis Analysis of hypotheses and diagnostic preferences lead to further examinations and, hopefully, to the most logical choice for a diagnosis Is it possible to automate such reasoning processes through LP?

7. Differential Diagnosis: An Example A patient shows up at the dentist with signs of pain upon teeth percussion. Expected causes are: A patient shows up at the dentist with signs of pain upon teeth percussion. Expected causes are: Periapical lesion (endodontic or periodontal source)Periapical lesion (endodontic or periodontal source) Horizontal fracture of the root and/or crownHorizontal fracture of the root and/or crown Vertical fracture of the root and/or crownVertical fracture of the root and/or crown Several additional examinations can be conducted to determine the exact cause, namely: Several additional examinations can be conducted to determine the exact cause, namely: X-Ray for determination of radiolucency or fracture tracesX-Ray for determination of radiolucency or fracture traces X-Ray for determination of periapical lesion sourceX-Ray for determination of periapical lesion source Check for tooth mobilityCheck for tooth mobility Measurement of gingival pocketsMeasurement of gingival pockets

8. How to put it all together? Cutting-edge LP techniques have lead to working implementations for each separate topic Cutting-edge LP techniques have lead to working implementations for each separate topic How to integrate all these different technologies into a unified and powerful reasoning system? How to integrate all these different technologies into a unified and powerful reasoning system? New abstractions are neededNew abstractions are needed Empirical testing is vital to understand the new propertiesEmpirical testing is vital to understand the new properties

9. The ACORDA system ACORDA is a prospective LP system: ACORDA is a prospective LP system: Capable of self-updatingCapable of self-updating For the ongoing observations, it can abduce their most likely explanations, each a possible scenarioFor the ongoing observations, it can abduce their most likely explanations, each a possible scenario Capable of preferring among explanationsCapable of preferring among explanations Can simulate the consequences of committing to each most relevant explanatory scenarioCan simulate the consequences of committing to each most relevant explanatory scenario Performs experiments in order to choose and commit, if possible, to a single explanationPerforms experiments in order to choose and commit, if possible, to a single explanation

10. ACORDA concepts: observables - 1 Observations are modelled in ACORDA by the relation observable/4 : Observations are modelled in ACORDA by the relation observable/4 : observable(Observer, Observed, Observation, TruthValue) observable(Observer, Observed, Observation, TruthValue) These represent internally triggered observations the system wants to explain or satisfy These represent internally triggered observations the system wants to explain or satisfy They can also stand for observations of the system on the outside environment, or from an oracle They can also stand for observations of the system on the outside environment, or from an oracle

11. ACORDA concepts: observables - 2 These are all valid examples of observations: These are all valid examples of observations: observable(prog, prog, tooth_ache, true) observable(prog, battery, low_battery, false) observable(player, prog, checkmate, unknown) Internal observations can be automatically triggered via the on_observable/4 relation Internal observations can be automatically triggered via the on_observable/4 relation At each reasoning step, ACORDA attempts to satisfy the set of observations triggered by active on_observable/4 literals At each reasoning step, ACORDA attempts to satisfy the set of observations triggered by active on_observable/4 literals

12. ACORDA concepts: abducibles - 1 Abductive extensions to a theory, i.e. the possible explanations to given observations, are modelled by abducible literals Abductive extensions to a theory, i.e. the possible explanations to given observations, are modelled by abducible literals They are represented via expect/1 clauses: They are represented via expect/1 clauses: expect(rain) ← cloudy expect(beach) ← sunny, not work expect(travel) ← holidays, expect(money) rain, beach, travel and money are the abducible literals rain, beach, travel and money are the abducible literals

13. ACORDA concepts: abducibles - 2 Expectations can be countered by expect_not/1 clauses: Expectations can be countered by expect_not/1 clauses: expect_not(sleep) ← deadline(tomorrow) expect_not(coffee) ← blood_pressure_high An abducible is confirmed only if it is expected, but not ‘expect_not’: An abducible is confirmed only if it is expected, but not ‘expect_not’: confirm(A) ← expect(A), not expect_not(A) Abducibles are taken to be mutually exclusive, so each possible choice contains a single explanation Abducibles are taken to be mutually exclusive, so each possible choice contains a single explanation

14. ACORDA concepts: preferences Sets of abducibles may be coded as a single abducible representing the set Sets of abducibles may be coded as a single abducible representing the set One may embed a theory of a priori preferences among the abducibles in ACORDA One may embed a theory of a priori preferences among the abducibles in ACORDA The preferences are modelled via the operator <|, as shown below: The preferences are modelled via the operator <|, as shown below: coffee <| tea ← sleepy rain <| snow ← not temp_less_than(0)

15. ACORDA concepts: integrity constraints (ICs) The reasoning mechanisms of ACORDA are also guided by integrity constraints, that may not be violated in any future state The reasoning mechanisms of ACORDA are also guided by integrity constraints, that may not be violated in any future state These constraints are a strong form of delimiting the space of possible hypotheses that ACORDA can explore These constraints are a strong form of delimiting the space of possible hypotheses that ACORDA can explore The following are examples of ICs: The following are examples of ICs: false ← relaxed, work false ← expect(move_forward), battery(0)

16. ACORDA concepts: simulation - 1 Simulation towards satisfaction of a given observation first proceeds by launching a top- down derivation proof procedure, e.g. XSB-Prolog Simulation towards satisfaction of a given observation first proceeds by launching a top- down derivation proof procedure, e.g. XSB-Prolog Each abducible supporting the derivation tree for the observation represents one possible choice scenario for the system Each abducible supporting the derivation tree for the observation represents one possible choice scenario for the system Disconfirmation and preference rules may defeat several of these abducibles Disconfirmation and preference rules may defeat several of these abducibles If only a single abducible remains, it is the choice to which the system will commit If only a single abducible remains, it is the choice to which the system will commit However, often simulations will result in more than a single possible explanation However, often simulations will result in more than a single possible explanation

17. ACORDA concepts: simulation - 2 A simple example of a multiple scenario simulation: A simple example of a multiple scenario simulation: drink ← tea. drink ← coffee. tea ← confirm(tea). coffee ← confirm(coffee). expect(tea).expect(coffee). expect_not(coffee) ← blood_pressure_high. coffee <| tea ← sleepy. confirm(A) ← expect(A), not expect_not(A).

18. ACORDA concepts: oracles - 1 When more than one explanation remains after a simulation, ACORDA activates other mechanisms to enact a choice When more than one explanation remains after a simulation, ACORDA activates other mechanisms to enact a choice The simulation is relaunched, this time allowing the posing of external questions to Oracles The simulation is relaunched, this time allowing the posing of external questions to Oracles The Oracles stand for systems which ACORDA can query to support the confirmation or disconfirmation of some of the hypotheses The Oracles stand for systems which ACORDA can query to support the confirmation or disconfirmation of some of the hypotheses Newly acquired information can eventually be used to defeat some or all of the hypotheses – or activate new ones – and possibly enact a choice Newly acquired information can eventually be used to defeat some or all of the hypotheses – or activate new ones – and possibly enact a choice

19. ACORDA concepts: oracles - 2 Oracles can represent any kind of external system: questions to the user, or to a set of sensors, remote databases, other reasoning systems, etc. Oracles can represent any kind of external system: questions to the user, or to a set of sensors, remote databases, other reasoning systems, etc. Oracles can be integrated into ACORDA via observable/4 clauses, just like regular observations, but with special preconditions that are activated only when the system is unable to choose by itself Oracles can be integrated into ACORDA via observable/4 clauses, just like regular observations, but with special preconditions that are activated only when the system is unable to choose by itself Oracles open up new unexplored paths in the simulation’s derivation tree Oracles open up new unexplored paths in the simulation’s derivation tree

20. Diagnosis computational model

21. Differential Diagnosis in ACORDA - 1 Declarative modelling of the dentistry use case: Declarative modelling of the dentistry use case: on_observable(prog, prog, percussion_pain_cause) ← percussion_pain. percussion_pain_cause ← periapical_lesion. percussion_pain_cause ← horizontal_fracture. percussion_pain_cause ← vertical_fracture. The knowledge theory describes several possible reasons for the symptom of percussion pain The knowledge theory describes several possible reasons for the symptom of percussion pain The internal program-to-program generated observation, to explain the cause of percussion pain, will be triggered by updating the symptom into the system The internal program-to-program generated observation, to explain the cause of percussion pain, will be triggered by updating the symptom into the system

22. Differential Diagnosis in ACORDA - 2 Each diagnostic hypothesis can be expressed as an abducible in the system: Each diagnostic hypothesis can be expressed as an abducible in the system: expect(periapical_lesion) ← profound_caries. expect(periapical_lesion) ← on_observable(percussion_pain_cause). Expectations can be based on further rules, and may also depend on the very observations which are active (e.g. periapical lesion is expected because it is a likely reason for causing percussion pain) Expectations can be based on further rules, and may also depend on the very observations which are active (e.g. periapical lesion is expected because it is a likely reason for causing percussion pain)

23. Differential Diagnosis in ACORDA - 3 Each abducible has also some rules accounting for its disconfirmation: Each abducible has also some rules accounting for its disconfirmation: expect_not(periapical_lesion) ← fracture_traces, not radiolucency. fracture_traces, not radiolucency. expect_not(horizontal_fracture) ← radiolucency, not fracture_traces. radiolucency, not fracture_traces. expect_not(vertical_fracture) ← radiolucency, not fracture_traces. radiolucency, not fracture_traces. The initial symptoms do not include any of these literals, so all relevant explanations remain open. The initial symptoms do not include any of these literals, so all relevant explanations remain open.

24. Differential Diagnosis in ACORDA - 4 There are also preference rules involving some of the hypotheses: There are also preference rules involving some of the hypotheses: horizontal_fracture <| vertical_fracture ← low_mobility. low_mobility. vertical_fracture <| horizontal_fracture ← high_mobility. high_mobility. Once again, the initial symptoms do not contain the necessary conditions for activating these preferences. Once again, the initial symptoms do not contain the necessary conditions for activating these preferences.

25. Differential Diagnosis in ACORDA - 5 The available examinations are also included in the knowledge theory of the system: The available examinations are also included in the knowledge theory of the system: radiolucency ← observable(prog, xray, radiolucency). radiolucency ← observable(prog, xray, radiolucency). fracture_traces ← observable(prog, xray, fracture_traces). fracture_traces ← observable(prog, xray, fracture_traces). high_mobility ← observable(prog, mobility_check, high_mobility). high_mobility ← observable(prog, mobility_check, high_mobility). low_mobility ← low_mobility ← observable(prog, mobility_check, low_mobility). observable(prog, mobility_check, low_mobility). Each examination is a query to an adequate oracle. Each examination is a query to an adequate oracle.

26. Interactive Results with ACORDA Having modelled the situation, the prospective reasoning can be triggered by updating the literal percussion_pain into the system. Having modelled the situation, the prospective reasoning can be triggered by updating the literal percussion_pain into the system. Reference Reference Gonçalo Lopes, L. M. Pereira Prospective Programming with ACORDA Prospective Programming with ACORDA in Empirically Successful Computerized Reasoning (ESCoR'06) workshop at The 3rd Intl. J. Conf.on Automated Reasoning (IJCAR'06), Seattle, USA, August 21, 2006. Empirically Successful Computerized ReasoningThe 3rd Intl. J. Conf.on Automated ReasoningEmpirically Successful Computerized ReasoningThe 3rd Intl. J. Conf.on Automated Reasoning

27. [interactive robot demo] interactive robot demointeractive robot demo