I've spent some time looking at the backwards chaining facility, trying to match it up with my requirements. I have a few observations, to do with the lifecycle of need-XXX facts.
When you declare a deftemplate to be backward-chaining enabled, rules are rewritten to produce need-XXX facts when the desired form of the deftemplate is not available. 1. How long should/do the need-XXX facts exist? 2. How do they react to changes in the facts that caused them to be asserted? Right now, upon assertion of a fact that can result in backwards chaining, the need-XXX fact is generated. That fact appears to be permanent...if no rule can generate the necessary fact, the need-XXX fact stays. If the base assertion that triggered the need-XXX is changed, the need-XXX is not retracted. In addition, once the need-XXX is satisfied, it is not removed. It is easy to write a retract that will get rid of the need-XXX once you satisfy it, but it is harder to remove the spurious ones whose base condition has changed. Something like the support for logical may be necessary, where the need-XXX is made to be dependent on the facts that produced it. Which leads to the next question -- what is the best practice for handling large numbers of varying queries? The top level of my RETE graph is disturbingly wide, and mostly occupied by defquery stuff. I wish there was another mechanism for indexing and accessing facts! RJ -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
