opencog-dev team mailing list archive

["Joel Pitt" <joel.pitt@xxxxxxxxx>]

On Fri, Oct 17, 2008 at 12:13 AM, Ari Heljakka
<ari.heljakka@xxxxxxxxxxxxxx> wrote:
>>> From my understanding of the code, the validate methods don't actually
>>
>> check the order of < L2, L1 > is invalid. Just that the types are
>> correct since it only checks one handle/Vertex at a time and I don't
>> see how it would share any binding information between calls to
>> weak_atom...
>
> Correct.

Would it not make sense to try and validate the order and that they
fit. Or would this be too costly?

>> [1] whereas the o2iMeta functions DO ensure that the
>> shared atoms of links are correct, but I could be completely wrong.
>> I'm confused about whether these output-to-input functions can be used
>> for forward chaining too.
>
> o2i function do check the variable consistency, but the method for doing
> that is rather tightly integrated with the whole binding scheme.
>
> Basically, you don't actually check for consistency in the o2i approach at
> all; instead, you start out with the correct formula with variables (eg.
> DeductionRule($1=>$2, $2->$3) and then create a new instance of the whole
> Rule (or rather, the BITNode that embodies the Rule) by binding one of the
> variables to some Atom, eg. resulting in DeductionRule($1=>MyAtom,
> MyAtom->$3). This way, consistency is guaranteed. This does cost space and
> time for cloning the BITNodes, but then again ensuring consistency across
> large trees by other means is a hairy problem.

So you're saying that in order to check the consistency we need to
wrap the Rule in a BITNode and use that? Does that BITNode then
represent the result of the rule application (sorry if this is
exceedingly basic, I just want to confirm that my understanding is
correct)?

If the BITNode is the result, then for forward chaining, could I just
make a BITNode with the rule but without a specific target and still
use it for checking rule variable consistency?

> I believe an analogic solution can be used for fw chaining, but it's
> possible you can find something else, too, which is simpler and works for fw
> chaining only.

I think it'd be preferable to try and reuse the same code for forward
chaining if it is possible. That requires me getting a better grasp of
things - but I need to do that anyway.

J