Inconsistency Robustness in Logic Programs
Inconsistency robustness is “information system performance in the face of continually pervasive inconsistencies.” A fundamental principle of Inconsistency Robustness is to make contradictions explicit so that arguments for and against propositions can be formalized. This paper explores the role of Inconsistency Robustness in the history and theory of Logic Programs. Robert Kowalski put forward a bold thesis: “Looking back on our early discoveries, I value most the discovery that computation could be subsumed by deduction.” However, mathematical logic cannot always infer computational steps because computational systems make use of arbitration for determining which message is processed next by a recipient that is sent multiple messages concurrently. Since reception orders are in general indeterminate, they cannot be inferred from prior information by mathematical logic alone. Therefore mathematical logic cannot in general implement computation. Over the course of history, the term “Functional Program” has grown more precise and technical as the field has matured. “Logic Program” should be on a similar trajectory. Accordingly, “Logic Program” should have a general precise characterization. In the fall of 1972, different characterizations of Logic Programs that have continued to this day: * A Logic Program uses Horn-Clause syntax for forward and backward chaining * Each computational step (according to Actor Model) of a Logic Program is deductively inferred (e.g. in Direct Logic). The above examples are illustrative of how issues of inconsistency robustness have repeatedly arisen in Logic Programs.
💡 Research Summary
The paper “Inconsistency Robustness in Logic Programs” investigates how persistent contradictions can be handled explicitly within logic programming, proposing a paradigm called “Inconsistency Robustness.” The author begins by recalling Robert Kowalski’s celebrated claim that computation can be subsumed by deduction, and then challenges this view by pointing out that mathematical logic alone cannot determine the order in which concurrently sent messages are processed. Because reception order is generally indeterminate, a purely deductive system cannot faithfully implement many computational steps, especially those that rely on arbitration among competing inputs.
Two major strands of logic programming that emerged around the fall of 1972 are contrasted. The first, “Procedural Interpretation,” treats Horn‑clause syntax as a program and relies on forward and backward chaining as the sole inference mechanism. The second, “Procedural Embedding,” embeds logical sentences into procedural constructs so that each computational step is a logical inference (e.g., via the Actor model or Direct Logic). The author argues that the second approach is more general, preserves the natural structure of propositions, and avoids the artificial flattening imposed by Horn‑clause normal forms.
A central critique is directed at classical logic’s explosion principle—here labeled IGOR (Inconsistency in Garbage Out Reduction). In classical systems, a contradiction (Φ ∧ ¬Φ) entails any proposition Ψ, which makes contradictions “game‑stoppers.” The paper shows that this principle, together with the law of excluded middle, is unsuitable for systems that must operate on inconsistent data (e.g., climate models, neuroscience theories). Consequently, the author promotes paraconsistent alternatives, focusing on Direct Logic and its “Inconsistency‑Robust” variant. These logics allow contradictions to be present without collapsing the inference process, thereby supporting reasoning in pervasively inconsistent domains.
The Actor model is introduced as a computational framework that naturally captures nondeterministic message ordering. Each actor processes messages asynchronously; the order of arrival cannot be deduced from prior knowledge, which means that any logical account of computation must accommodate this indeterminacy. By coupling Actor semantics with Direct Logic, each computational step can be both a logical inference and a concrete execution event, satisfying the robustness requirement.
Historical case studies are examined in depth. Planner (1969‑1971) is presented as an early hybrid language that procedurally embedded logical implications: forward chaining asserts q when p is asserted, backward chaining sets a goal p when goal q is desired, and vice‑versa for negated literals. Micro‑Planner, a Lisp‑based lightweight implementation, added practical optimizations such as backtracking, unique‑name assumptions, and a closed‑world “negation as failure” mechanism. These systems demonstrated that procedural embedding can preserve logical meaning while delivering efficient execution on the limited hardware of the era.
The paper then critiques resolution‑based theorem proving, which was championed by Kowalski and others as the uniform proof procedure for logic programs. While resolution is sound for consistent theories, the author shows that in the presence of contradictions it can derive propositions via invalid arguments (e.g., using the rule Ψ → Ψ ∨ Φ). The “set‑of‑support” strategy, intended to limit resolution to relevant clauses, still suffers from hidden overlaps in vocabulary that can mislead the prover into spurious derivations. Thus, resolution alone is not inconsistency‑robust.
In conclusion, the author asserts that a robust logic programming framework must (1) make contradictions explicit, (2) employ a non‑explosive logic such as Inconsistency‑Robust Direct Logic, and (3) integrate a computational model like the Actor model that respects nondeterministic message ordering. Procedural embedding, rather than pure Horn‑clause resolution, is advocated as the path forward for building systems that can reason effectively in domains where inconsistency is the norm rather than the exception. The paper calls for future research to develop languages and runtimes that embody these principles, thereby extending the original vision of computation‑as‑deduction into a truly robust, real‑world setting.
Comments & Academic Discussion
Loading comments...
Leave a Comment