<p>Some thoughts:</p>
<p>Why did the logic program fail: The answer to &quot;<em>why&quot;</em> is of course <em>&quot;because there is no variable assignment that fulfills the constraints given by the Prolog program&quot;</em>.</p>
<p>This is evidently rather unhelpful, but it is exactly the case of the &quot;blue dog&quot;: there are no such thing (at least in the problem you model).</p>
<p>In fact the only acceptable answer to the blue dog problem is obtained when the system goes into full theorem-proving mode and outputs:</p>
<pre><code>blue(X) &lt;=&gt; ~dog(X)
</code></pre>
<p>or maybe just</p>
<pre><code>dog(X) =&gt; ~blue(X)
</code></pre>
<p>or maybe just</p>
<pre><code>blue(X) =&gt; ~dog(X)
</code></pre>
<p>depending on assumptions. &quot;There is no evidence of blue dogs&quot;. Which is true, as that's what the program states. So a &quot;why&quot; in this question is a demand to rewrite the program...</p>
<p>There may not <em>be</em> a good answer: <em>&quot;Why is there no x such that x² &lt; 0&quot;</em> is ill-posed and may have as answer <em>&quot;just because&quot;</em> or <em>&quot;because you are restricting yourself to the reals&quot;</em> or <em>&quot;because that 0 in the equation is just wrong&quot;</em>  ... so it depends very much.</p>
<p>To make a &quot;<em>why</em>&quot; more helpful, you will have to qualify this <em>&quot;why&quot;</em> somehow.  which may be done by structuring the program and extending the query so that additional information collecting during proof tree construction is bubbling up, but you will have to decide beforehand what information that is:</p>
<p><code>query(Sought, [Info1, Info2, Info3])</code></p>
<p>And this query will always succeed (for <code>query/2</code>, &quot;success&quot; no longer means &quot;success in finding a solution to the modeled problem&quot; but &quot;success in finishing the computation&quot;),</p>
<p>Variable <code>Sought</code> will be the reified answer of the actual query you want answered, i.e. one of the atoms <code>true</code> or <code>false</code> (and maybe <code>unknown</code> if you have had enough with two-valued logic) and <code>Info1, Info2, Info3</code> will be additional details to help you answer a <em>why something something</em> in case <code>Sought</code> is <code>false</code>.</p>
<p>Note that much of the time, the desire to ask &quot;why&quot; is down to the mix-up between the two distinct failures: &quot;failure in finding a solution to the modeled problem&quot; and &quot;failure in finishing the computation&quot;. For example, you want to apply <code>maplist/3</code> to two lists and expect this to work but erroneously the two lists are of different length: You will get <code>false</code> - but it will be a <code>false</code> from computation (in this case, due to a bug), not a <code>false</code> from modeling. Being heavy-handed with <code>assertion/1</code> may help here, but this is ugly in its own way.</p>
<p>In fact, compare with imperative or functional languages w/o logic programming parts: In the event of failure (maybe an exception?), what would be a corresponding &quot;why&quot;? It is unclear.</p>
<p><strong>Addendum</strong></p>
<p>This is a great question but the more I reflect on it, the more I think it can only be answer in a task-specific way: You must structure your logic program to be <code>why</code>-able, and you must decide what kind of information <code>why</code> should actually return. It <em>will</em> be something task-specific: something about missing information, &quot;if only this or that were true&quot; indications, where &quot;this or that&quot; are chosen from a dedicates set of predicates. This is of course expected, as there is no general way to make imperative or functional programs explain their results (or lack thereof) either.</p>
<p>I have looked a bit for papers on this (including IEEE Xplore and ACM Library), and have just found:</p>
<ul>
<li><a href="https://arxiv.org/abs/1402.0575" rel="nofollow noreferrer">Reasoning about Explanations for Negative Query Answers in DL-Lite</a> which is actually for Description Logics and uses <a href="https://en.wikipedia.org/wiki/Abductive_reasoning" rel="nofollow noreferrer">abductive reasoning</a>.</li>
<li><a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.71.9781" rel="nofollow noreferrer">WhyNot: Debugging Failed Queries in Large Knowledge Bases</a> which discusses a tool for <a href="https://en.wikipedia.org/wiki/Cyc" rel="nofollow noreferrer">Cyc</a>.</li>
<li>I also took a random look at the documentation for <a href="http://flora.sourceforge.net/documentation.html" rel="nofollow noreferrer">Flora-2</a> but they basically seem to say &quot;use the debugger&quot;. But debugging is just debugging, not explaining.</li>
</ul>
<p>There must be more.</p>
Reporting *why* a query failed in Prolog in a systematic way
<p>I'm looking for an approach, pattern, or built-in feature in Prolog that I can use to return <em>why</em> a set of predicates failed, at least as far as the predicates in the database are concerned. I'm trying to be able to say more than &quot;That is false&quot; when a user poses a query in a system.</p>
<p>For example, let's say I have two predicates.  <code>blue/1</code> is true if something is blue, and <code>dog/1</code> is true if something is a dog:</p>
<pre><code>blue(X) :- ...
dog(X) :- ...
</code></pre>
<p>If I pose the following query to Prolog and <code>foo</code> is a dog, but not blue, Prolog would normally just return &quot;false&quot;:</p>
<pre><code>? blue(foo), dog(foo)
false.
</code></pre>
<p>What I want is to find out <em>why</em> the conjunction of predicates was not true, even if it is an out of band call such as:</p>
<pre><code>? getReasonForFailure(X)
X = not(blue(foo))
</code></pre>
<p>I'm OK if the predicates have to be written in a certain way, I'm just looking for any approaches people have used.</p>
<p>The way I've done this to date, with some success, is by writing the predicates in a stylized way and using some helper predicates to find out the reason after the fact.  For example:</p>
<pre><code>blue(X) :-
    recordFailureReason(not(blue(X))),
    isBlue(X).
</code></pre>
<p>And then implementing recordFailureReason/1 such that it always remembers the &quot;reason&quot; that happened deepest in the stack. If a query fails, whatever failure happened the deepest is recorded as the &quot;best&quot; reason for failure. That heuristic works surprisingly well for many cases, but does require careful building of the predicates to work well.</p>
<p>Any ideas?  I'm willing to look outside of Prolog if there are predicate logic systems designed for this kind of analysis.</p>