Re: [TED] Action-188, ISSUE: production rule systems have "difficulty" with recursive rules in RIF Core

I wonder if we are not missing the point, here... See comment below.

Gary Hallmark wrote:
> 
> A naive translation from RIF Core to a "generic" production rule 
> language might produce the following:
> 
> assert(factorial(0, 1))
> IF factorial(?x, ?y)
> THEN assert(factorial(?x + 1, (?x + 1) * ?y))
> 
> The problem with the naive translation is it will generate *all* 
> factorial facts:
> factorial(1 1)
> [...]
> ...etc....
> until memory is exhausted.  In other words, the naive translation using 
> forward chaining is not "goal directed".  In contrast, a backward 
> chaining implementation would start with a query such as:
> 
> :- factorial(4 ?out)
> 
> and may terminate after generating subgoals factorial(3 ?), factorial(2 
> ?), and factorial(1 ?).

So, the rules are correctly mapped into the production rule language 
(their semantics is preserved). Only, they may have undesirable effect 
if applied carelessly. But is that relevant to RIF?

You may also try to compute all the factorials until the memory is full 
by asking :- factorial(?in ?out) to your LP system, no? Similarly, you 
might compute the factorial of 4 with your PR engine by executing step 
by step, checking after each cycle if you have your answer and stopping 
when you have it.

The point, as many stressed, is that PR and LP are designed for 
different usage: PR engines are mostly not used to answer queries (which 
implies somehow backward chaining), and they do not usually have a query 
answering control strategy.

But, again, is that really relelvant to RIF?

More generally, to what degree should RIF be concerned with what systems 
  do with the rules they retrieve from a RIF document? The answer may 
range from: "not at all, provided that the semantics is preserved" - and 
recursion is not a problem in Core - to: "all the way to, and including 
making sure that retrieved rules can be run efficiently" - which might 
make sense for specific dialects; but probably not for Core.

Received on Tuesday, 19 December 2006 13:46:09 UTC