Inconsistency Proofs for ASP: The ASP-DRUPE Format
Mario Alviano, Carmine Dodaro, Johannes K. Fichte, Markus Hecher,, Tobias Philipp, Jakob Rath

TL;DR
This paper introduces ASP-DRUPE, a new proof format for verifying inconsistency in Answer Set Programming, based on RUP, with correctness proof and implementation in the wasp solver.
Contribution
It develops ASP-DRUPE, a novel proof format for ASP inconsistency, adapting RUP for logic programs, and demonstrates its integration and correctness.
Findings
ASP-DRUPE is correct and sound.
Implemented in the wasp solver.
Facilitates formal verification of ASP inconsistency.
Abstract
Answer Set Programming (ASP) solvers are highly-tuned and complex procedures that implicitly solve the consistency problem, i.e., deciding whether a logic program admits an answer set. Verifying whether a claimed answer set is formally a correct answer set of the program can be decided in polynomial time for (normal) programs. However, it is far from immediate to verify whether a program that is claimed to be inconsistent, indeed does not admit any answer sets. In this paper, we address this problem and develop the new proof format ASP-DRUPE for propositional, disjunctive logic programs, including weight and choice rules. ASP-DRUPE is based on the Reverse Unit Propagation (RUP) format designed for Boolean satisfiability. We establish correctness of ASP-DRUPE and discuss how to integrate it into modern ASP solvers. Later, we provide an implementation of ASP-DRUPE into the wasp solver for…
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
\jdate
March 2003
\pagerangeLABEL:firstpage–LABEL:lastpage
Inconsistency Proofs for ASP:
The ASP-DRUPE Format
Mario Alviano
University of Calabria
Italy
Carmine Dodaro
University of Calabria
Italy
Johannes K. Fichte
TU Dresden
Germany
Markus Hecher
TU Wien
Austria
Tobias Philipp
secunet Security Networks AG
Germany
Jakob Rath
TU Wien
Austria
(2003)
Abstract
Answer Set Programming (ASP) solvers are highly-tuned and complex procedures that implicitly solve the consistency problem, i.e., deciding whether a logic program admits an answer set. Verifying whether a claimed answer set is formally a correct answer set of the program can be decided in polynomial time for (normal) programs. However, it is far from immediate to verify whether a program that is claimed to be inconsistent, indeed does not admit any answer sets. In this paper, we address this problem and develop the new proof format ASP-DRUPE for propositional, disjunctive logic programs, including weight and choice rules. ASP-DRUPE is based on the Reverse Unit Propagation (RUP) format designed for Boolean satisfiability. We establish correctness of ASP-DRUPE and discuss how to integrate it into modern ASP solvers. Later, we provide an implementation of ASP-DRUPE into the wasp solver for normal logic programs.
doi:
S1471068401001193
keywords:
ASP, RUP proofs, inconsistency proofs
1 Introduction
Answer Set Programming (ASP) [Brewka et al. (2011)] is a logic-based declarative modeling language and problem solving framework [Gebser et al. (2012)] for hard computational problems and an active research area in artificial intelligence (AI) and knowledge representation and reasoning. It has been applied both in academia [Balduccini et al. (2006), Gebser et al. (2010), Gebser et al. (2011)] and industry [Gebser et al. (2011), Guziolowski et al. (2013), Ricca et al. (2012)]. In propositional ASP questions are encoded by atoms combined into rules and constraints which form a logic program. Solutions to the program consist of sets of atoms called answer sets; if no solutions exist then the program is inconsistent.
Knowledge representation languages like ASP are usually considered explainable AI, as they are based on deduction, which is an explainable procedure. For example, we can easily explain answer sets of a normal logic program in terms of program reducts and fixpoint operators [Liu et al. (2010)]. In this case, we may argue that answer sets are self-explanatory, and therefore ASP systems providing answer sets are explainable AI systems. However, modern ASP systems do not provide any explanation for inconsistent programs; there is no witness that can be checked or evidence of the correctness of the refutation of the input program. Hence, even if inconsistency of logic programs is anyhow explainable with mathematical rigour, ASP systems are essentially black-boxes in this case, and just report the absence of answer sets. We believe that adding inconsistency proofs in ASP systems is important to make them explainable for inconsistent programs, but also provides auditability for consistent programs. Thanks to a duality result in the literature [Pearce (1999)], such inconsistency proofs for ASP can be also used as a certificate for the validity of some formulas of intuitionistic logic and other intermediate logics. A further application of these inconsistency proofs is query answering in ASP, which is usually achieved by inconsistency checks. There, the goal is to provide a witness for cautiously true answers of a given query.
Modern ASP solvers have been highly influenced by SAT solvers, which solve the Boolean satisfiability problem and are often based on conflict-driven clause learning [Silva and Sakallah (1999)]. Typically, ASP solvers aim for computing an answer set of a given program, and therefore solve the consistency problem that asks whether a given program has an answer set. This problem is on the second level of the polynomial hierarchy when allowing arbitrary propositional disjunctive programs as input and on the first level when restricting to disjunction-free programs [Truszczyński (2011)]. As already stated, while consistency of a program can be easily verified given such a computed answer set, verifying whether a solver correctly outputted that a program is inconsistent, is not immediate. Given that ASP solvers are also used for critical applications [Gebser et al. (2018), Haubelt et al. (2018)], their correctness is of utter importance.
When looking at SAT solvers, various techniques have been developed to ensure correctness of unsatisfiability, such as clausal proof variants [Gelder (2008), Goldberg and Novikov (2003)] based on clauses that have RUP (reverse unit propagation) and RAT (Resolution Asymmetric Tautology) property. These proof formats share verifiability in polynomial time in the size of the proof and input formula and can be tightly coupled with modern solving techniques. A solver outputs such a proof during solving. Thereby, the correctness of solving can be verified by a relatively simple method for every input instance. While there are variants of these proofs for various problems, such as extensions to verify the validity of quantified Boolean formulas [Heule et al. (2013), Wetzler et al. (2014)] (QRAT [Heule et al. (2014)] and QRAT+ [Lonsing and Egly (2018)]), to our knowledge such a format is not yet available for verifying ASP solvers.
One approach to certify inconsistency of a given normal program is to translate the program into a SAT formula in polynomial time [Lin and Zhao (2003), Janhunen (2006)] and obtain a proof from a SAT solver, e.g., via a RAT-based proof format, to verify that indeed the program is inconsistent. Unfortunately, this approach does not take the techniques into account that are employed by state-of-the-art ASP solvers and therefore seem to lack efficiency and scalability. Further, this is still not a suitable technique for disjunctive programs, nor to verify whether internally the ASP solver is able to correctly explain the obtained result.
We follow this line of research and establish the following novel results for ASP:
We present the proof format ASP-DRUPE based on RUP for logic programs given in SModels [Syrjänen (2000)] or ASPIF [Gebser et al. (2016)] (restricted to ASP without theory reasoning) input format including disjunctive programs and show its correctness. 2. 2.
We provide an algorithm for verifying that a given solving trace in the ASP-DRUPE format is indeed a valid proof for inconsistency of the input program. This algorithm works in polynomial time in the size of the given solving trace. 3. 3.
We illustrate on an abstract ASP solving algorithm how one can integrate ASP-DRUPE into state-of-the-art ASP solvers like clasp [Gebser et al. (2012)] and wasp [Alviano et al. (2015)]. 4. 4.
We provide an implementation in a variant of wasp, where ASP-DRUPE is integrated for normal ASP. This variant of wasp is able to not only explain inconsistency for inconsistent logic programs, but also provides auditability in case of consistency for verifying whether the provided answer set was indeed correctly obtained.
Related Work.
Heule et al. [Heule et al. (2013)] presented a proof format based on the RAT property and subsequently a program to validate solving traces in this format [Wetzler et al. (2014)]. Extended resolution allows to polynomially simulate the DRAT format [Kiesl et al. (2018)] and vice-versa [Wetzler et al. (2014)]. Many advanced techniques, such as XOR reasoning [Philipp and Rebola-Pardo (2016)] as well as symmetry breaking [Heule et al. (2015)] can be expressed in DRAT and efficient, verified checkers based on RAT have been developed [Cruz-Filipe et al. (2017)]. Further, RAT is also available for QBF [Heule et al. (2014)] and has been extended to cover a more powerful redundancy property [Lonsing and Egly (2018)].
2 Preliminaries
2.1 Answer Set Programming (ASP)
We follow standard definitions of propositional ASP [Brewka et al. (2011)] and use rules defined by the SModels [Syrjänen (2000)] or ASPIF [Gebser et al. (2016)] (restricted to ASP without theory reasoning) input format, which is widely supported by modern ASP solvers. In particular, let , , be non-negative integers such that , , , propositional atoms, , , , non-negative integers. A choice rule is an expression of the form , a disjunctive rule is of the form , and a weight rule is of the form , where . A rule is either a disjunctive, a choice, or a weight rule. A (disjunctive logic) program is a finite set of rules. For a rule , we let , , , and is a set of literals, i.e., an atom or the negation thereof. We denote the sets of atoms occurring in a rule or in a program by and . For a weight rule , let map literal to its weight in rule if for , or if for , and to [math] otherwise. Further, let for a set of literals and let be its bound. A normal (logic) program is a disjunctive program with for every . The positive dependency digraph of is the digraph defined on the set of atoms, where for every rule two atoms and are joined by an edge . We denote the set of all cycles (loops) in by . A program is called tight, if . While we allow programs with loops that might also involve atoms of weight rules, we consider weight rules only as a compact representation of a set of normal rules, similar to the definition of stable models in related work [Bomanson et al. (2016)]. In other words, we do not consider advanced semantics concerning recursive weight rules (recursive aggregates). In case of solvers with different semantics, one can restrict the input language to disregard recursive weight rules, which is also in accordance with the latest ASP-Core-2.03c standard [Calimeri et al. (2015)]. This restriction is motivated by a lack of consensus on the interpretation of recursive weight rules [Ferraris (2011), Faber et al. (2011), Gelfond and Zhang (2014), Pelov et al. (2007), Son and Pontelli (2007)].
2.2 Solving Logic Programs
Let be a given program, be a rule, and . We define the set of induced bodies with in the head by the singleton if is a choice rule, by if is a disjunctive rule, and by the union over for every (subset-minimal) set of literals such that , if is a weight rule. This allows us to define , and . A variable assignment is either or , where variable is either an atom, or an induced body, or a fresh atom that does not occur in . For a variable assignment , is the complementary variable assignment of , i.e., if and if . An assignment is a set of variable assignments, where , , and such that . For a set of literals, we define the induced assignment . A nogood is an assignment, which is not allowed, where refers to the empty nogood. Given a set of nogoods. We define the least fixpoint of unit propagated nogoods by the fixpoint computation , and for . Nogood is a consequence using unit propagation (UP) of set , denoted by , if . An assignment satisfies a set of nogoods (written ) if for every , we have . Set of nogoods is a consequence of a set of nogoods (denoted by ) if every assignment, which contains a variable assignment for all variables in , that satisfies also satisfies . The set of completion nogoods [Clark (1977), Gebser et al. (2012)] is defined by , where
[TABLE]
Note that in practice, current ASP solvers do not fully compute . Instead, these solvers partially compute and add relevant nogoods lazily during solving [Alviano et al. (2018)].
Then, if is tight the set is an answer-set if and only if there is a satisfying assignment for [Fages (1994), Gebser et al. (2012)]. The set of external bodies of program and set of atoms are given by [Gebser et al. (2012)]. We define the loop nogood for an atom on a loop by . For a logic program , the set is an answer set if and only if there is a satisfying assignment for , where [Lin and Zhao (2003), Faber (2005)].
3 ASP-DRUPE: RUP-like Format for Proof Logging
Inspired by RUP-style unsatisfiability proofs in the field of Boolean satisfiability solving [Goldberg and Novikov (2003)], we aim for a proof of inconsistency of a program. Since modern ASP solvers use Clark’s completion [Clark (1977)] to transform a program into a set of nogoods, we do so as well. Our aimed proof then has the following features:
Existence of a simple verification algorithm. In order to increase confidence in the correctness of results, the algorithm that verifies the proof has to be fairly easy to understand and to implement. 2. 2.
Low complexity. The proof is verifiable in polynomial time in its length and the size of the completion nogoods. 3. 3.
Integrability into solvers that employ Conflict-Driven Nogood Learning (CDNL). The proof can stepwise be outputted during solving with minimal impact on the solving algorithm and hence the solver.
The method works as follows: We run the solver on the set of completion nogoods for given input program . The solver outputs either an answer set or that has no answer set and a proof . We pass together with to the verifier in order to validate whether the solver’s assessment is in accordance with its outputted proof.
3.1 The Proof Format for Logic Programs
The basic idea of clausal proofs for SAT is the following: One starts with the input formula in CNF (given as a set of clauses). Every step of the proof denotes an addition or deletion of a clause to/from the set of clauses. For additions, the condition is to only add clauses that are a logical consequence of the current set of clauses and that it can be checked easily, e.g., use only unit propagation.
For our format ASP-DRUPE, we consider Clark’s completion as the initial set of nogoods corresponding to the input program . Besides addition and deletion of nogoods, we need proof steps that model how the solver excludes unfounded sets (loops).
Example 1
Consider program , which is inconsistent. contains only the positive loop , whose external support is given by the set of rules, and thus . Set induces two possible loop nogoods, and .
We describe the proof format ASP-DRUPE for logic programs and adapt the RUP property [Goldberg and Novikov (2003)] to nogoods as follows.
Definition 1** (nogood RUP)**
Let be a set of nogoods. Then, a nogood is RUP (reverse unit propagable) for if , i.e., we can derive using only unit propagation.
A proof step is a triple , where denotes the type of the step, is an assignment, and is an atom or . The type indicates whether the step is an addition (), a completion rule addition (), a completion support addition (), an extension (), a deletion (), or a loop addition (). A proof sequence for a logic program is a finite sequence of proof steps. Initially, a proof sequence gets associated with a set of nogoods. Note that although the set might be exponential in the size of the program , body definitions for body variables that do not occur in the proof are never materialized. Then, each proof step for subsequently transforms into the induced set of nogoods, formally defined below. An ASP-DRUPE derivation is a proof sequence that allows for RUP-like rules for ASP and includes both deletion and extension. In an ASP-DRUPE derivation each step has to satisfy a condition depending on its type as follows:
An addition inserts a nogood that is RUP for . 2. 2.
A completion rule addition inserts a nogood . 3. 3.
A completion support addition inserts a nogood if . 4. 4.
An extension introduces a definition that renders nogood equivalent to a fresh atom , i.e., does not appear in . Formally, this rule represents the set \mathsf{ext}(a,\delta)\,\mathrel{\mathop{:}}=\big{\{}\delta\cup\{\mathbf{F}a\}\big{\}}\cup\big{\{}\{\mathbf{T}a,\overline{l}\}\mid l\in\delta\big{\}} of extension nogoods. 5. 5.
A deletion represents the deletion of from . 6. 6.
A loop addition111There could be an exponential number of external bodies involving weight rules. However, both clasp and wasp treat weight rules differently [Alviano et al. (2015)]. Alternatively, one could easily modify the loop addition type to list also involved external bodies (as in the completion support addition type), which we did not for the sake of readability. inserts a loop nogood for a loop .
Given an ASP-DRUPE derivation , we define the set of nogoods induced by step as the result of applying proof steps to the initial completion body definitions for . For our inductive definition in the following, we use multiset semantics for additions and deletions of nogoods, and write for the multiset sum.
[TABLE]
Then, we say that an ASP-DRUPE derivation is an ASP-DRUPE proof for the inconsistency of if it actually derives inconsistency for , formally, . Note that might be exponential in the input program size, in the worst case. However, there is no need to materialize the set , as, intuitively, this set of body definitions only ensures that every induced body has a reserved auxiliary atom that can be used to “address” the body in a compact way. In an actual implementation of a solver that uses ASP-DRUPE, one needs to specify these used auxiliary atoms anyway, cf. Section 5, where implementational specifications of ASP-DRUPE are described.
Example 2
Consider program from Example 1 and loop , which induces loop nogood . Then, the proof sequence is an ASP-DRUPE proof for the inconsistency of with
[TABLE]
We show that the proof step is correct, i.e., that is RUP for . To this end, we need to derive from by unit propagation. With the nogood , we derive the unit nogood . With we now get . With these unit nogoods, reduces to .
3.2 Correctness of ASP-DRUPE
Next, we establish soundness and completeness of the ASP-DRUPE format.
Lemma 1** (Invariants)**
Let be a logic program and be a finite ASP-DRUPE derivation for program . Moreover, let be the accumulated set of nogoods introduced by the extension rules in for all . Then, the following holds: .
Proof 3.1** (Proof (Sketch).).**
We proceed by induction over the length of the derivation. For the base case, we have . Hence, and the claim holds trivially. For the induction step, we assume that the statement holds for length and consider step . It remains to do a case distinction for the type:
Deletion with : Immediately, we have . Thus, transitivity of and the induction hypothesis establishes this case. 2. 2.
Addition with : Since is RUP for , we know that is a logical consequence of . The remaining steps to draw the conclusion are similar to the deletion step case. 3. 3.
Completion Rule Addition with : Since the resulting nogood is contained in , the result follows. 4. 4.
Completion Support Addition with : Since the resulting nogood is contained in , the result follows. 5. 5.
Extension with : According to the induction hypothesis we have . Then, , since is a fresh variable and . As is monotone, and , we know that . It then follows that . 6. 6.
Loop addition with : By definition nogood is already contained in , which immediately establishes this case. ∎
Theorem 3.2** (Soundness and Completeness).**
Let be a logic program. Then, is inconsistent if and only if there is an ASP-DRUPE proof for .
Proof 3.3** (Proof (Sketch).).**
Let be a logic program. “”: Assume there is an ASP-DRUPE proof of . By definition, there is a finite sequence of proof steps such that and is inconsistent. From Lemma 1, we obtain that is inconsistent. As consists of extension nogoods with disjoint variables, we know that is inconsistent. We conclude from an earlier result [Gebser et al. (2012), Theorem 5.4] that is inconsistent. “”: Suppose is inconsistent. According to earlier work [Gebser et al. (2012), Theorem 5.4], we know that is inconsistent. RUP is complete [Gelder (2008), Goldberg and Novikov (2003)], which means that for every propositional, unsatisfiable formula there is a RUP proof for . Hence, we can construct an ASP-DRUPE proof for as follows: (i) Output all completion rule additions for and completion support additions for . (ii) Generate loop addition steps for all loops . (iii) Transform into a propositional formula by inverting all nogoods. (iv) Construct and use a RUP proof for . Then, output addition rules accordingly, where again all clauses need to be inverted to obtain addition proof steps using nogoods.
Note that in the only-if direction of the proof, one can also use RAT [Wetzler et al. (2014)] proofs without deletion information and afterwards translate RAT steps into extended resolution steps [Kiesl et al. (2018)].
Listing 1 presents the ASP-DRUPE checker, that decides whether a given ASP-DRUPE proof is correct. The input to the checker is both the original program and the proof . To check the proof, we encode into nogoods and then check each statement sequentially.
Lemma 3.4**.**
For a given logic program and an ASP-DRUPE derivation , the ASP-DRUPE-Checker runs in time at most .
Corollary 3.5**.**
Given a logic program and an ASP-DRUPE derivation . Then, the ASP-DRUPE-Checker is correct, i.e., it outputs Success if and only if is an ASP-DRUPE proof for the inconsistency of .
3.3 Extension to Optimization
Next, we briefly mention how to verify cost optimization. To this end, an optimization rule is an expression of the form \operatorname{\mathrel{\mathchoice{\reflectbox{\displaystyle\rightsquigarrow}}{\reflectbox{\textstyle\rightsquigarrow}}{\reflectbox{\scriptstyle\rightsquigarrow}}{\reflectbox{\scriptscriptstyle\rightsquigarrow}}}}l_{1}[w_{1}], where is a literal. Intuitively this indicates that if an assignment satisfies , then this results in costs . Overall, one aims to minimize the total costs, i.e., the goal is to deliver an answer set of minimal total costs. Therefore, if one wants to verify, whether a given answer set candidate is indeed an answer set of minimal costs, we foresee the following extension to ASP-DRUPE, where such a proof consists of the following two parts. (i) An answer set that shows a solution with costs exists. (ii) An ASP-DRUPE proof that shows that the program restricted to costs is inconsistent. Note that for disjunctive programs already the first part also needed to contain a second proof showing that indeed there cannot be an unfounded set for the provided answer set. Further, it is not immediate, how this extends to unsatisfiable cores. Hence, so far it only applies to progression based approaches.
4 Integrating ASP-DRUPE Proofs into a Solver
In the following, we describe the CDNL-ASP algorithm for logic programs that we use as a basis for our theoretical model. Afterwards, we describe how proof logging can be integrated. In other words, during the run of an ASP solver, we immediately print the corresponding ASP-DRUPE rules that are needed later for verification in case the ASP solver concludes that the program is inconsistent. A typical CDNL-based ASP solver (cf., Listing 2) relies on unit propagation, since this is a rather simple and efficient way of concluding consequences. Thereby it keeps a set of nogoods, a current assignment , and a decision level . In a loop it applies NogoodPropagation [Gebser et al. (2012), page 101] consisting of unit propagation and loop propagation (using UnfoundedSet [Gebser et al. (2012), page 104]) whenever suited. Then, if there is some nogood that is not satisfied, either the program is inconsistent (at decision level 0) or ConflictAnalysis [Gebser et al. (2012), page 108] triggers backtracking to an earlier decision level, followed by the learning of a conflict nogood . Otherwise, if all nogoods in are satisfied and all the variables are assigned, an answer set is found, and otherwise some free variable is selected (Select).
Listings 2 and 3 contain a prototypical CDNL-based ASP solver that is extended by proof logging, where the changes for proof logging are highlighted in red. We use the element operator () to determine whether an element is in a sequence, and denote the concatenation of two proofs by the operator as follows: . The idea is to start with an empty ASP-DRUPE derivation. Whenever a new nogood, or loop nogood is learned and added to accordingly, this results in an added addition or loop addition proof step, respectively. Note that in Listing 3 we add completion rule addition steps and completion support addition steps, whenever unit propagation (or conflicts) involve rules in or , respectively. In particular, Lines 3 and 3 take care of adding involved parts of the completion to the proof (if needed) accordingly. At the end, when the ASP solver concludes inconsistency, the proof is returned including the empty nogood as last nogood. Note that advanced techniques (see, e.g., [Gebser et al. (2012)]) like forgetting of learned clauses and restarting of the ASP solver can also be implemented using deletion rules with ASP-DRUPE.
As it turns out, preprocessing in ASP is less sophisticated as for SAT. In the literature, CDNL-based ASP solvers often use preprocessing techniques [Gebser et al. (2008)] similar to SAT solvers, i.e., SatElite-like [Eén and Biere (2005)] operations as variable and nogood elimination. For simple preprocessing operations restricted to variable and nogood elimination ASP-DRUPE suffices. Note that if Clark’s completion is exponential in the program size due to weight rules, also propagators [Alviano et al. (2018)] are supported. For details we refer to the implementation in Section 4.1.
Example 4.6** (CDNL-ASP-DRUPE).**
We continue the previous Example 2 and indicate a possible CDNL-ASP-DRUPE run on that leads to the exemplary ASP-DRUPE proof given above. We use the notation ( to indicate that was assigned true (false) at decision level .
Initially, nothing can be propagated. 2. 2.
After the decision , unit propagation derives only . 3. 3.
After the second decision , we eventually derive and by unit propagation. Thus we discover the unfounded set , and add the loop nogood . 4. 4.
The loop nogood immediately leads to a conflict, and conflict analysis learns the nogood . 5. 5.
We backtrack to decision level 1, and after propagation, make the decision . We arrive at another conflict, and learn . 6. 6.
After backtracking, a conflict appears at decision level 1, and we learn . 7. 7.
We backtrack to decision level 0, and decide on . After arriving at a conflict almost immediately, we learn . 8. 8.
We backtrack once more, and finally arrive at a conflict at decision level 0, returning INCONSISTENT along with an ASP*-*DRUPE proof. Note that the proof given in Example 2 is slightly simplified in that we only include those steps of types and that are actually used.
4.1 Implementation of ASP-DRUPE in wasp solver
We provide an implementation of ASP-DRUPE within the wasp [Alviano et al. (2015)] solver that is available on github222The repository can be found at https://github.com/alviano/wasp/tree/unsatproof.. The solver prints a proof for inconsistency in the file proof.log if the solver gets passed the program options - -disable-simplifications - -proof-log=proof.log. Actually wasp prints an ASP-DRUPE derivation also in the positive case of consistency. This derivation can still be used to verify whether the nogoods learned by the solver are correct. Currently, proof logging is restricted to normal programs and we do not yet support recursive weight rules due to discrepancy among different semantics as discussed in the preliminaries. Moreover, we had to introduce a normalized form because of several (in-processing) simplifications that would otherwise require major refactoring to isolate. Just to mention one of these simplifications, a rule of the form is replaced by the integrity constraint . While these simplifications are required to achieve efficient computation, they alter the completion of the input program. Therefore, wasp cannot log in the proof the auxiliary atoms required to keep the completion compact. The problem is circumvented by introducing a normalized form such that the completion can be compactly computed without introducing any auxiliary atoms.
A program is in short-body normalized form if for each atom either , or for any body , we have . Any normal program can be transformed into short-body normalized form in linear time by introducing a linear number of auxiliary atoms (in the program size). This normalized form allows us to get rid of auxiliary variables for bodies , i.e., we can set , and replace in by , and in by . For simplification and increased readability of a compact resulting proof log, we further do not use neither completion rule addition, nor completion support addition types. Instead, we assume that the checker is aware of the completion from the beginning. In this respect, we have to observe that for weight rules, completion might be exponential in the program size. Therefore, we require that the checker is equipped with a propagator [Alviano et al. (2018)] for drawing conclusions by unit-propagation on parts of the completion associated with weight rules. We provide an implementation of such a checker tool as well333Both the checker tool and a tool for bringing normal logic programs in short-body normalized form can be found at https://github.com/alviano/python/tree/master/asp-proof..
5 ASP-DRUPE Implementational Specifications
Next, we discuss the specific format description of ASP-DRUPE that we think can be commonly used in ASP solvers. To this end, we assume a program and a set of fresh atoms, where we have one fresh atom for each induced body in . Further, let be an injective mapping of atoms to a unique positive integer such that , and . Note that for atoms this can be (partly) already provided by the input format. However, for technical reasons, we assume such a mapping also for atom , where , as these integers will then correspond to fresh atoms. We define in the following an SModels-like [Syrjänen (2000)] output format of strings for a given program , which is ready for the checker to parse. Actually, the output format is “line-based”, i.e., it is even ASPIF-like [Gebser et al. (2016)]. However, ASP-DRUPE still supports ASP only, and not ASP solving with theory reasoning. To this end, let the truth value mapping map a variable assignment to an integer different from 0, where a positive integer represents an atom and a negative integer a negated atom.
[TABLE]
Then, the ASP-DRUPE output format is a sequence of strings, where each element in the sequence corresponds to one rule in an ASP-DRUPE derivation and is terminated by character “0”. Each part of an element in the sequence is separated by a white space (␣). We indicate other strings constants by . Then, element of the sequence for is of the following form.
- •
A body definition string is of the form such that , , , . Further, we require that for some . Finally, for the string corresponds to the proof step , where . The technical purpose of is to specify the fresh body variable for a body .
- •
An addition string is of the form such that , which corresponds to proof step .
- •
A completion rule addition string is of the form such that and , which relates to proof step .
- •
A completion support addition string is of the form such that and for , which corresponds to proof step .
- •
An extension string is of the form such that , , , , which corresponds to proof step .
- •
A deletion string is of the form such that , which corresponds to proof step .
- •
A loop addition string is of the form such that , , , which corresponds to proof step .
- •
An unfounded set addition string is of the form such that , which then corresponds to proof step .
Next, we define how to obtain the ASP-DRUPE output format of a given ASP-DRUPE derivation . To this end, we define , which transforms a proof step into a string for , by slight abuse of notation.
[TABLE]
Since fresh body atoms require introduction using extension proof steps in advance, we assume , where for . Finally, let . As a simplification, one can leave out additional, unused body definition strings.
Example 5.7**.**
Consider the ASP-DRUPE proof for inconsistency of from Example 2 and assume the dictionary in the program input assigns , , , , and . We extend this to the necessary bodies: , , , , , , , and . Figure 1 corresponds to . Note that we use body definitions for required body variables.
6 Conclusion & Future Work
ASP solvers are highly-tuned decision procedures that are widely applied in academia and industry. In this paper, we considered how to ensure that if an ASP solver outputs that a program has no answer set then the solver is indeed right. Similar to unsat certificates in SAT solvers, we propose an approach that augments the inconsistency answer of an ASP solver with a certificate of inconsistency. This approach allows the use of unverified, efficient ASP solvers while guaranteeing that a particular run of an ASP solver has been correct.
To this end, we developed a new proof format called ASP-DRUPE. It allows several types of proof steps: (RUP) addition that models nogood learning, completion rule addition and completion support addition for adding completion rules on demand, deletion that models nogood forgetting, extension that allows to infer new definitions and loop addition that adds nogoods to forbid assignments that do not correspond to answer sets. ASP-DRUPE supports formula simplification methods that can be obtained by learning entailed nogoods, nogood deletion as well as extended resolution. We established that ASP-DRUPE is sound and complete for logic programs and can be used effectively, i.e., a program is inconsistent if and only if a ASP-DRUPE proof of exists and that we can check an ASP-DRUPE proof in polynomial time of the proof length. Further, we demonstrated how to augment CDNL-based solvers with proof logging. It is in our interest for future work to continue this line of research. Potential next steps include the study of theory reasoning towards covering the full ASPIF intermediate format.
Finally, we would like to say a few words about RAT-style proofs. The combination of nogood deletion, loop, and RAT addition results in an inconsistent proof system in which we can infer a conflict although a non-tight program is consistent. This stems from the situation that clauses that are RAT with respect to are not necessarily RAT with respect to . Although it was recently shown that extended resolution simulates DRAT [Kiesl et al. (2018)], we are unaware whether ASP-DRUPE can be extended to RAT such that each rule application can be checked in polynomial time, which we believe is an interesting question for future work.
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1Alviano et al . (2015) Alviano, M. , Dodaro, C. , Leone, N. , and Ricca, F. 2015. Advances in WASP. In LPNMR 2015 . LNCS, vol. 9345. Springer, 40–54.
- 2Alviano et al . (2018) Alviano, M. , Dodaro, C. , and Maratea, M. 2018. Shared aggregate sets in answer set programming. TPLP 18, 3-4, 301–318.
- 3Balduccini et al . (2006) Balduccini, M. , Gelfond, M. , and Nogueira, M. 2006. Answer set based design of knowledge systems. Ann. Math. Artif. Intell. 47, 1-2, 183–219.
- 4Bomanson et al . (2016) Bomanson, J. , Gebser, M. , Janhunen, T. , Kaufmann, B. , and Schaub, T. 2016. Answer set programming modulo acyclicity. Fundam. Inform. 147, 1, 63–91.
- 5Brewka et al . (2011) Brewka, G. , Eiter, T. , and Truszczyński, M. 2011. Answer set programming at a glance. Communications of the ACM 54, 12, 92–103.
- 6Calimeri et al . (2015) Calimeri, F. , Faber, W. , Gebser, M. , Ianni, G. , Kaminski, R. , Krennwallner, T. , Leone, N. , Ricca, F. , and Schaub, T. 2015. ASP-core-2 input language format.
- 7Clark (1977) Clark, K. L. 1977. Negation as failure. In Symposium on Logic and Data Bases 1977 . Advances in Data Base Theory. Plemum Press, 293–322.
- 8Cruz-Filipe et al . (2017) Cruz-Filipe, L. , Heule, M. J. H. , Jr., W. A. H. , Kaufmann, M. , and Schneider-Kamp, P. 2017. Efficient certified RAT verification. In CADE 2017 . LNCS, vol. 10395. Springer, 220–236.
