OpenCogPrime:DefaultInference

From OpenCog
Jump to: navigation, search

First of all, here is what the PLN book has to say about default inference (in the chapter on Inference Control):




Inference control contains a great number of subtleties, only a small minority
 of which has been considered here. Before leaving the topic we will consider 
one additional aspect, lying at the borderline between inference control, PLN 
inference proper, and cognitive science. This is the notion of “default 
inheritance,” which plays a role in computational linguistics within the Word
 Grammar framework (Hudson 1984), and also plays a central role in various 
species of nonmonotonic “default logic” (Reiter, 1980; Delgrande and Schaub,
 2003). The treatment of default inference in PLN exemplifies how, in the PLN
 framework, judicious inference control and intelligent integration of PLN with
 other structures may be used to achieve things that, in other logic 
frameworks, need to be handled via explicit extension of the logic.


To exemplify the notion of default inheritance, consider the case of penguins,
 which do not fly, although they are a subclass of birds, which do fly. When 
one discovers a new type of penguin, say an Emperor penguin, one reasons 
initially that they do not fly – i.e., one reasons by reference to the new 
type’s immediate parent in the ontological hierarchy, rather than its 
grandparent. In some logical inference frameworks, the notion of hierarchy is 
primary and default inheritance of this nature is wired in at the inference 
rule level. But this is not the case with PLN – in PLN, correct treatment of 
default inheritance must come indirectly out of other mechanisms. Fortunately,
 this can be achieved in a fairly simple and natural way.


Consider the two inferences (expressed informally, as we are presenting a 
conceptual discussion not yet formalized in PLN terms)



A)

penguin --> fly <0>

bird --> penguin <.02>

|-

bird --> fly


B)

penguin --> bird <1>

bird --> fly <.9>

|-

penguin --> fly


The correct behavior according to the default inheritance idea is that, in a 
system that already knows at least a moderate amount about the flight behavior 
of birds and penguins, inference A should be accepted but inference B should 
not. That is, evidence about penguins should be included in determining whether
 birds can fly – even if there is already some general knowledge about the 
flight behavior of birds in the system. But evidence about birds in general 
should not be included in estimating whether penguins can fly, if there is 
already at least a moderate level of knowledge that in fact penguins are 
atypical birds in regard to flight.



But how can the choice of A over B be motivated in terms of PLN theory? The 
essence of the answer is simple: in case B the independence assumption at the 
heart of the deduction rule is a bad one. Within the scope of birds, being a 
penguin and being a flier are not at all independent. On the other hand, 
looking at A, we see that within the scope of penguins, being a bird and being 
a flier are independent. So the reason B is ruled out is that if there is even 
a moderate amount of knowledge about the truth-value of (penguin --> fly), this
 gives a hint that applying the deduction rule’s independence assumption in 
this case is badly wrong.


On the other hand, what if a mistake is made and the inference B is done 
anyway? In this case the outcome could be that the system erroneously increases
 its estimate of the strength of the statement that penguins can fly. On the 
other hand, the revision rule may come to the rescue here. If the prior 
strength of (penguin --> fly) is 0, and inference B yields a strength of .9 for
 the same proposition, then the special case of the revision rule that handles 
wildly different truth-value estimates may be triggered. If the 0 strength has 
much more confidence attached to it than the .9, then they won’t be merged 
together, because it will be assumed that the .9 is an observational or 
inference error. Either the .9 will be thrown out, or it will be provisionally 
held as an alternate, non-merged, low-confidence hypothesis, awaiting further 
validation or refutation.


What is more interesting, however, is to consider the implications of the 
default inference notion for inference control. It seems that the following may
 be a valuable inference control heuristic:




1.  Arrange terms in a hierarchy; e.g., by finding a spanning DAG of the terms 
in a knowledge base, satisfying certain criteria (e.g., maximizing total 
strength*confidence within a fixed limitation on the number of links).



2. When reasoning about a term, first do deductive reasoning involving the 
term’s immediate parents in the hierarchy, and then ascend the hierarchy, 
looking at each hierarchical level only at terms that were not visited at lower
 hierarchical levels.




This is precisely the “default reasoning” idea – but the key point is that in 
PLN it lives at the level of inference control, not inference rules or 
formulas. In PLN, default reasoning is a timesaving heuristic, not an 
elementary aspect of the logic itself. Rather, the practical viability of the 
default-reasoning inference-control heuristic is a consequence of various other 
elementary aspects of the logic, such as the ability to detect dependencies 
rendering the deduction rule inapplicable, and the way the revision rule deals 
with wildly disparate estimates.


What occurred to me a couple days ago is that one could perhaps formalize the above notion of “default inference by inference control” more rigorously ... and go a little further by articulating an explicit default inference rule based on the hierarchy mentioned there.


This could be done in a number of ways. For instance, one could define a notion of OntologicalInheritance, based on the spanning dag mentioned above.


One can build a default logic based on the spanning dag G, as follows. Suppose B lies below A in the dag G. And, suppose that, for predicate F, we have


F(A) <t>


meaning that F applies to A with truth value t. Then, we may say that “If ~F(B) is not known, then F(B)”. In other words, we may assume by default that B possesses the properties of the terms above it in the hierarchy.

More formally, we might propose a “default inference rule” such as:


IMPLICATION
   AND
      OntologicalInheritance B A
      Evaluation F A
      NOT
         Evaluation Known( NOT (Evaluation F B ) )
   Evaluation F B


There is no reason that a rule like this can’t be implemented within PLN. Note that implementing this rule within PLN gives you something nice, which is that all the relationships involved (OntologicalInheritance, Known, NOT, etc.) may be probabilistically quantified, so that the outcome of the inference rule may be probabilistically quantified.


The “Known” predicate is basically the K predicate from standard epistemic logic (K_a, where a is the reasoning system itself in this case.)


The hierarchy G needs to be periodically rebuilt as it is based on abstracting a dag from a graph of probabilistic logical relations. And, the results of the above default inference rule may be probabilistic and may be merged with the results of other inference rules.


The results from using this rule, in principle, should not be so different from if the rule were not present. However, the use of an ontological hierarchy in this way leads to a completely different dynamics of inference control, which in practice WILL lead to different results....


And, note finally that for this sort of ontological approach can also be used in the context of association spreading. In this case, it may take the form (for example) of ontology-based pruning of Assocation relationships. The Association between pigeon and flyer may be pruned because it is essentially redundant with a set of two Association relationships that are implicit in the hierarchy:

Association pigeon bird
Association pigeon flyer

Using an ontology-pruned set of Association links to guide inference that is partially based on ontology-driven default inference rules, provides an alternative approach to solving the frame problem, that doesn’t require introducing a notion of hierarchy into the underlying logic.