Introduction to Truth Maintenance Systems A Truth Maintenance

Introduction to Truth Maintenance Systems A Truth Maintenance System (TMS) is a PS module responsible for: 1. 2. 3. 4. 5. Enforcing logical relations among beliefs. Generating explanations for conclusions. Finding solutions to search problems Supporting default reasoning. Identifying causes for failure and recover from inconsistencies. The TMS / IE relationship is the following: Justifications, assumptions Inference Engine TMS Beliefs, contradictions Problem Solver

1. Enforcement of logical relations (constrains) among beliefs. Every AI problem which is not completely specified requires search. Search utilizes assumptions, which may eventually change. Changing assumptions requires updating consequences of beliefs. Re-derivation of those consequences is most often not desirable, therefore we need a mechanism to maintain and update relations among beliefs. Example: If (cs-501) and (math-218) then (cs-570). If (cs-570) and (CIT-core-completed) then (TMS-related-capstone). If (TMS-related-capstone) then (AI-experience). The following are relations among beliefs following from these statements: (AI-experience) if (TMS-related-capstone) if (cs-570), (CIT-core-completed). etc. Beliefs can be viewed as propositional variables, and a TMS can be viewed as a mechanism for processing large collections of logical relations on propositional variables.

2. Generation of explanations. Solving problems is what PSs do. However, often solutions are not enough the PS is expected to provide an explanation for the proposed solution so that the user can identify the cause of a problem if something goes wrong. To provide explanations, a TMS uses cached inferences. The fundamental assumption behind this idea is that caching inferences once is more beneficial than running inference rules that have generated these inferences more than once. Example Q: Shall I have an AI experience after completing the CIT program? A: Yes, because of the TMS related capstone. Q: What do I need to take a TMS related capstone? A: CS-570 and completed core. Note: There are different types of TMSs that provide different ways of explaining conclusions (JTMS vs ATMS). In this example, explaining conclusions in terms of their immediate predecessors works much better.

3. Finding solutions to search problems. Consider the following graph B A D C E Assume you want to color the nodes so that every node is red, or green, or yellow, and adjacent nodes are of different colors. Let "1" means "red", "2" means "green", and "3" means "yellow". Then, the following set of constraints describe this problem: A 1 or A 2 or A 3 B 1 or B 2 or B 3 C 1 or C 2 D 1 or D 2 or D 3 E 1 or E 2 not (A 1 and B 1) not (A 2 and B 2) not (A 3 and B 3) not (A 1 and C 1) not (A 2 and C 2) not (A 3 and C 3) not (B 1 and D 1) not (B 2 and D 2) not (B 3 and D 3) not (D 1 and E 1) not (D 2 and E 2) not (D 3 and E 3) not (C 1 and E 1) not (C 2 and E 2) not (C 3 and E 3)

To find a solution that satisfies all of the constraints, we can use search: A is red A is green B is red B is green B is yellow C is red C is green C is yellow D is red D is green D is yellow E is red E is green E is yellow A is yellow

4. Default reasoning and TMS Many real-world problems cannot be completely specified. That is, the PS must make conclusions based on incomplete information. Typically the assumption under which such conclusions are drawn is that X is true unless there is an evidence to the contrary. This is known as the “Closed-World Assumption” (CWA). Notice that the CWA helps us limit the underlying search space by assuming only a certain choice and ignoring the others. The reasoning scheme that utilizes this assumption is called “default (or non-monotonic) reasoning”. Example: Consider the following knowledge base Bird(tom) and not Abnormal(tom) Can_fly(tom) Penguin(tom) Abnormal(tom) Ostrich(tom) Abnormal(tom) Bird(tom) ----------------------Under the CWA, we assume not Abnormal(tom) (because there is no evidence that Tom is abnormal). Therefore, we can derive can_fly(tom). Non-monotonic TMS supports this type of reasoning.

5. Identifying causes for failures and recovering from inconsistencies. Inconsistencies among beliefs in the KB are always possible, especially if the PS makes its conclusions based on insufficient information. The most common reasons for inconsistencies or other failures are the following: -- Wrong data. Example: “Outside temperature is 320 degrees. ” -- Impossible constraints. Example: (Big-house and Cheap-house and Nice-house). -- Non-monotonic inference. PS is forced to “jump” to a conclusion, because of the lack of information, or lack of time to derive the conclusion. -- Contradictions due to inconsistent data, conclusions contradicting the existing data, or inconsistent assumptions. -- Dynamic data. When the domain evolves, the new domain state may be considerably different from the previous domain state, and inferences made in the previous state may no longer be valid. Cashed dependences among beliefs that TMS maintains help identify the reason for an inconsistency, and a mechanism, called “dependency-directed backtracking” allows the TMS to recover from it. Example: see book, figures 6. 1 – 6. 4

How the TMS and the IE communicate? The PS works with: – assertions (facts, beliefs, conclusions, hypotheses); – inference rules; – procedures. Each one of these is assigned a TMS node. Example: N 1: (rule (student ? x) (assert (and (underpaid ? x) (overworked ? x)))) N 2: (student Bob) Note that the IE and the TMS treat nodes differently. Given N 1 and N 2, the IE can infer N 3: (and (underpaid Bob) (overworked Bob)) This is possible because the IE threats nodes as logical formulas, while the TMS treats nodes as propositional variables.

TMS nodes Different types of TMSs support different types of nodes. Here are the basic ones: Ø Premise nodes. These are always true. Ø Contradiction nodes. These are always false. Ø Assumption nodes. These are nodes, which the IE wants to believe no matter whether or not they are supported by the existing evidence. Ø (Regular) nodes. These are nodes which are believed only if there is a valid reason for that. Each node has a label associated with it. The contents and the structure of the label depends on the type of TMS. In the simplest case, it may only indicate whether a node is believed (: IN) or not believed (: OUT). Nodes are complex data structures, where different node properties are stored. Labels are just one of those properties. Other properties are node type (premise, assumption, etc. ), node support (justifications, antecedents), node consequences, etc.

TMS justifications Once a new node, N 3, is created by the IE, it can be reported to the TMS together with the fact that it follows from N 1, N 2 and MP. This is recorded in the following form, called the justification: (N 3 Modus-Ponens N 2 N 1) Here N 3 is called the consequent, Modus-Ponens is the informant, N 1 and N 2 are the antecedents of the justification. That is, justifications record relations among beliefs (N 1, N 2 and N 3 in this case), and therefore can be used for explaining consequents and identifying causes for inconsistencies. The general format of justifications is the following: (<consequent> <informant>. <antecedents>)

TMS dependency networks Nodes and justifications form a dependency network. Here is an example network: Node Justifications for Node; one of them is selected to be Node's "support", i. e the reason for Node to be believed ("IN"). Node's consequences; these are justifications for other nodes of the network, for which Node is an antecedent. See figures 6. 8 and 6. 9 for examples.

TMS / IE interaction Responsibilities of the IE: Responsibilities of the TMS: 1. 2. 3. 4. Adds assertions and justifications. Makes premises and assumptions, Retracts assumptions. Provides advise on handling contradictions 2. 3. 4. Cashes beliefs and consequences and maintains labels. Detects contradictions. Performed belief revision. Generates explanations.

Propositional specification of a TMS As we have already seen, TMS nodes are propositional variables. Therefore, we can view TMS justifications as propositional formulas (implications) of the form: N 1 & N 2 & … & Ni Nj Here N 1, N 2, …, Ni, Nj are positive literals, therefore this implication is a Horn formula. A TMS can be viewed as a collection of Horn formulas. There exist polynomial time inference procedures for Horn formulas knowledge bases. For example, forward chaining -- by just applying MP, we can derive all formulas that logically follow from the KB. This makes it possible for a TMS to answer a variety of queries about the current set of nodes and justifications. The most fundamental query is whether a node logically follows from a given TMS state.

Families of TMSs There are several families of TMSs, which differ in the representation scheme they use and the functionality they support: 1. 2. 3. 4. 5. 6. Justification-based TMSs. The language used is limited to Horn formulas. Logic-based TMSs. These use a full propositional logic language. Assumption-based TMSs. Language limited to Horn formulas, but several alternatives (contexts) can be explored at the same time. Non-monotonic JTMSs. Language limited to Horn formulas, but allow non -monotonic justifications, thus making it possible to implement default reasoning. Clause Management Systems. Their representational power is equivalent to LTMSs, but like ATMSs can support several contexts at the same time. Contradiction-tolerant TMSs. Language limited to Horn formulas, but support non-monotonic and plausible reasoning and deal explicitly with contradictions in a single context.