From OpenCog
Jump to: navigation, search

Obsolete Documentation. This page describes an inference repository which no longer reflects how the current python-based PLN chainer actually works. If you can update this page so that it's correct for the current system, please do so. Otherwise, this page should probably be removed.

The Inference Node Repository (INRepository) is an object that stores inference nodes from BackInferenceTrees. Also from forward chaining. It means that future inferences can directly reuse partly sections of previous search trees (including if they weren't fully explored before). It could also be used to mine for patterns in inference (a la OpenCogPrime:AdaptiveInferenceControl). Both forward and backward chaining can reuse inference paths found by one another. The INRepository would also provide a more efficient way to run multiple inference processes in parallel, avoiding redundant explorations of paths.

The INRepository only stores a certain number of InferenceNodes. Specific instances of forward/backward chaining can be set to either use the shared INRepository or their own. There could also be multiple different types of inference in the system, using different PLN Rules, different data etc, which may best have their own repositories.

Data stored in the INRepository

  • a "reference" RuleProvider (so that different instances of inference can use the same C++ Rule objects, important)
  • a cache of BITNodes from many different PLN BackInferenceTrees. A least-recently-used cache would be a decent basic way to do this. To maintain current behaviour, it should expand in capacity when any currently active BITs expand, so they can reach the size they're each currently allowed to.
  • trail info (possibly stored separately from the BITNodes for various reasons)
  • various statistics
  • misc metadata useful in inferences

Data stored in each BITNodeRoot

The BITNodeRoots now only store metadata for a particular target/inference.

  • a pointer to an INRepository (possibly a shared one, possibly not).
  • a pointer to a rule provider (likewise).
  • a flag for whether it is using a shared or individual repository+RP. If individual, it deletes it all when it is deleted.
  • the expansion pool for this BIT, which only includes BITNodes that are actually relevant to this inference.
  • a map of the depth each BITNode has from this root
  • various statistics (to be kept for just that inference as well)