ACORDA for Prospective Logic Programming

1
ACORDA for ProspectiveLogic 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
• Incomplete
• Contradictory
• Revisable
• Dynamic vs. Static

3
The Evolution of Logic Programming - 2

• Programs reason with incomplete knowledge
• Programs revise their knowledge in face of
  contradiction
• Programs self-update and evolve to become
  different
• Programs can have several distinct futures

4
Challenges for reasoning in LP

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

5
Differential Diagnosis (DD) - 1

• In medicine, DD is the systematic method used to
  identify diseases
• The physician observes the patients symptoms,
  medical history and available examinations
• The 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
  diagnosis

6
Differential Diagnosis - 2

• 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
• 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
• Periapical lesion (endodontic or periodontal
  source)
• Horizontal fracture of the root and/or crown
• Vertical fracture of the root and/or crown
• Several additional examinations can be conducted
  to determine the exact cause, namely
• X-Ray for determination of radiolucency or
  fracture traces
• X-Ray for determination of periapical lesion
  source
• Check for tooth mobility
• Measurement of gingival pockets

8
How to put it all together?

• 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?
• New abstractions are needed
• Empirical testing is vital to understand the new
  properties

9
The ACORDA system

• ACORDA is a prospective LP system
• Capable of self-updating
• For the ongoing observations, it can abduce their
  most likely explanations, each a possible
  scenario
• Capable of preferring among explanations
• Can simulate the consequences of committing to
  each most relevant explanatory scenario
• Performs 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
• observable(Observer, Observed, Observation,
  TruthValue)
• 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

11
ACORDA concepts observables - 2

• 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
• 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
• 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

13
ACORDA concepts abducibles - 2

• 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
• confirm(A) ? expect(A), not expect_not(A)
• 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
• One may embed a theory of a priori preferences
  among the abducibles in ACORDA
• The preferences are modelled via the operator lt,
  as shown below
• coffee lt tea ? sleepy
• rain lt 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
• These constraints are a strong form of delimiting
  the space of possible hypotheses that ACORDA can
  explore
• 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
• 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
• 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

17
ACORDA concepts simulation - 2

• 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 lt 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
• 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
• 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 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
  simulations derivation tree

20
Diagnosis computational model
21
Differential Diagnosis in ACORDA - 1

• 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 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
• 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)

23
Differential Diagnosis in ACORDA - 3

• Each abducible has also some rules accounting for
  its disconfirmation
• expect_not(periapical_lesion) ?
• fracture_traces, not radiolucency.
• expect_not(horizontal_fracture) ?
• radiolucency, not fracture_traces.
• expect_not(vertical_fracture) ?
• radiolucency, not fracture_traces.
• 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
• horizontal_fracture lt vertical_fracture ?
• low_mobility.
• vertical_fracture lt horizontal_fracture ?
• high_mobility.
• 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
• radiolucency ? observable(prog, xray,
  radiolucency).
• fracture_traces ? observable(prog,
  xray, fracture_traces).
• high_mobility ?
  observable(prog, mobility_check, high_mobility).
• low_mobility ?
• observable(prog, mobility_check,
  low_mobility).
• 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.
• Reference
• Gonçalo Lopes, L. M. Pereira
• 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.

27

• interactive robot demo