ImplicationLink
From OpenCog
An ImplicationLink is used by OpenCog to express if...then... relations. The structure of an ImplicationLink is a set of predicates to be anded together (disjunct normal form), followed by one or more implicands. ImplicationLinks may contain variables that are bound for the scope of the implication. They should be thought of as expressions in first-order logic; i.e. VariableNodes may only be grounded by nodes, not links; grounding by links is discussed below.
ImplicationLinks encode basic logical implication P->Q, i.e. if P then Q as:
ImplicationLink P Q
where P is the predicate and Q is the implicand. ImplicationLinks can also be thought of as graph re-write rules: if graph P is observed, then graph Q is created.
Contents |
Example
Consider the English language sentence "Fido is a dog". A dependency parse of this sentence would result in the dependency graph "_subj(be,Fido) _obj(be,dog)". Suppose that, given this dependency parse, we want to conclude that "isa(dog,Fido)". In FrameNet notion, this would be:
# IF _subj(be,$var0) ^ _obj(be,$var1) THEN isa($var1, $var0)
When written out in OpenCog format, this becomes an ImplicationLink
ImplicationLink
AndLink
EvaluationLink
PredicateNode "_subj"
ListLink
ConceptNode "be"
VariableNode "$var0"
EvaluationLink
PredicateNode "_obj"
ListLink
ConceptNode "be"
VariableNode "$var1"
EvaluationLink
PredicateNode "isa"
ListLink
VariableNode "$var1"
VariableNode "$var0"
Note that each triple was expressed in terms of EvaluationLinks. A perl script that will convert the first, short form, into the second, can be found in the source tree, at opencog/nlp/triples/rules-to-implications.pl. Additional documentation can be found in opencog/nlp/triples/README
Evaluation
OpenCog has both a chainer and a generic evaluator. The chainer is PLN; see that page for details (As of 2011, PLN is broken and non-functional). The generic evaluator is the pattern matcher. It can be invoked from C++ or from the scheme shell. The BindLink page provides details.
The pattern matcher uses "crisp boolean logic" to determine if a predicate pattern match has occurred. Thus, the predicate pattern must have truth values set to non-zero values. The NotLink can be used to reject a match; thus, if a NotLink is present in the predicate, the indicated clause must be absent, or, if present, it must evaluate to 'false'.
Callouts to C++/scheme code can be done by using ExecutionLinks.
Propagating Truth Values
Note that the overall structure of the ImplicationLink is of the form
ImplicationLink
P
Q
and so can be thought of as being much like the expression P->Q from first-order logic. However, in OpenCog, truth values have far more complex structures; there are various ways in which a truth value on P should be propagated to Q.
By default, when the pattern matcher instantiates Q, it copies/propagates the truth value from the grounding of P in a 'crisp' fashion. In order to provide a more complex calculation of truth values, the ExecutionLink should be used. Thus, for example:
ImplicationLink
P
ExecutionLink
GroundedSchemaNode "some-tv-and-sti-function"
ListLink
Q_1
Q_2
...
Assuming that pattern P is found, then graphs Q_1, Q_2, etc. would be created, and passed to the function "some-tv-and-sti-function" as the first and second arguments. This function can then alter Q_1, Q_2, ... as desired, such as altering the associated truth values or attention values, or creating yet other graphs, or performing any functions or procedures whatsoever.
Second-Order Logic
ImplicationLinks should be thought of as expressions in first-order logic; i.e. VariableNodes may only be grounded by nodes, not links. The restriction to first-order logic is to avoid the infinitely recursive expressions that can appear in second-order logic, and thus avoid potential infinite loops that would occur when they're evaluated. Note that its impractical to determine when an expression might be recursive: this is equivalent to the Turing halting problem.
Note that this caveat doesn't apply to PLN.
