Have the backward chainer support URE rules without formula

[opencog]

Have the backward chainer support URE rules without formula

[ngeiswei]

Till this is fixed, the obvious workaround is to use a dummy formula.

[linas]

So, uhhh ... OpenPsi already does this. ... except differently. And it doesn't chain. Of course. Instead, it uses ECAN to spread attention around, and Hebbian links to preferentially encourage certain (forward) chaining directions instead of others.

I think it would be nice to migrate the backard-chainer URE rules, and the OpenPsi rules, so that they resemble one-another more closely, and, ideally, are fully compatible. Maybe that's not possible? Maybe that does not make sense? I recall adding BindLinks and VariableNodes to openpsi a few years ago, but I' not sure if those survived or got ripped out; I've lost touch with the openpsi design. Perhaps @amebel could comment?

[linas]

To be clear: what the backward chainer is calling "conclusion", openpsi is calling "goal". What backward chainer is calling "premise", openpsi calls "action". What backward chainer is calling "precondition", openpsi calls "context". So the wording is different. But the general idea is the same.

[linas]

In openpsi, to reach a "goal", one must take certain "actions". Its not always possible to take those actions; whether its possible or not depends on "context". So one moves backwards, trying to a sequence of actions that can be taken, that, when actually performed, cause the goals to be fulfilled.

Are backwards-chainer "premises" the same thing as openpsi "actions"? I claim they are. I do admit that this is a non-obvious claim that needs to be articulated, so if it sounds weird and wrong ... that's OK.

[linas]

More generally, I would like to be able to think of the backward chainer, and openpsi to both be understood as path-planners, or constraint-satisfaction-solvers. So, the chainer is trying to find a sequence of steps; those steps are a "proof" for a "theorem": they are a sequence of PLN rules that allow some conclusion to be deduced (or induced) from the premises. The chainer is trying to find a path through a set of rules, that connects the start to the end. The chainer is trying to find a path. But so is openpsi. Its trying to get to a goal, by applying a sequence of rules. Each rule has "actions" as a side-effect. What is possible, or not, is limited by constraints. Perhaps its harder for openpsi: the path is constrained. It needs to avoid certain intermediate states. (whereas PLN can take any path at all) In either case, the path is minimum length, and ideally it has no loops (right??? this is both obvious and not-obvious, because certain recursive algos are de-facto terminating loops.)

[ngeiswei]

I agree, there are striking resemblances between OpenPsi and the URE. The URE control mechanism is actually a specialized form of OpenPsi.

OpenPsi rules however are declarative and probabilistic, while URE rules are crisp and imperative. That doesn't mean OpenPsi and the URE can't be can't be unified in some ways, but, at least pragmatically, I think it makes more sense to have OpenPsi built on top of the URE, rather than unified. Just like the URE is built on top of the pattern matcher + unification. It seems to work well that way, other ways are possible of course.

[amebel]

@linas BindLinks are not used but, OpenPsiImplicator is basically a non atomese form of it.

@ngeiswei Assuming openpsi and ure have similar structure in representation and mechanism, at very high level, this issue is similar to what I mentioned here.

With regards to using ure in openpsi, ure could be the imperative engine that works over the declared openpsi-rules. By defining a rulebase that consume ImlicationLinks/PredictiveImplictionLinks and inheriting from an abstracted version of ActionSelection.h for defining a custom action-selector, it could be achieved. But, without breaking openpsi-rules into at the least the two types of structures mentioned in the linked issue, we might have to go the line of generating random goals, for the purpose of chaining.

[linas]

On a related note that probably deserves it's own issue number:

opencog/atomspace#2004 -- STV's and the pattern matcher have always had an uneasy co-existance. I'm thinking that perhaps there should be a single boolean true/false bit in the atom, and the pattern matcher would use that bit if and when it needed to actually access a boolean true/false. It would be up to the rules to toggle this bit, if needed. I think there is room in the C++ atom to store such a bit; it would speed computation by avoiding access to TV's.

opencog/atomspace#1893 -- On a different related note: URE rules should be able to, in general, manipulate any kind of values, not just truth values. That is, a rule would consist of a pattern to match, plus a function that grabs some values from somewhere in the pattern, does something with them, and puts them somewhere.

[noskill]

What currently is difference between:

BindLink
  <vardecl>
  AndLink
      <pattern>
      <premise-1>
      ...
      <premise-n>
  ExecutionOutputLink
    <formula>
    List
      <conclusion>

BindLink
  <vardecl>
  <pattern>
  ExecutionOutputLink
    <formula>
    List
      <conclusion>
      <premise-1>
      ...
      <premise-n>

if formula is dummy?

[ngeiswei]

The difference is that in the first case the URE will consider no premises, and in the second case it will consider n premises.