OpenCog Technical Information

From OpenCog

related pages: Projects | Ideas | BuildingOpenCog | Development standards

Further detailed documentation about OpenCog will be posted here in beginning in July 2008.

Beware: this page a placeholder until time is found to post more complete documentation!


OpenCog and its relation to the Novamente Cognition Engine

The initial OpenCog code consists of a basic framework extracted (and abstracted) from the Novamente Cognition Engine codebase, plus various AI tools developed in the course of working on the NCE. The OpenCog framework is designed to be usable to build a wide variety of differing types of AGI systems. As OpenCog develops, it is expected to progressively diverge from its roots in the NCE.

The OpenCog Prime cognitive architecture, to be built using the OpenCog framework, is based on integrative approaches which are similar to those found in the Novamente Cognition Engine. OpenCog Prime is intended to be only one of many possible cognitive architectures which may be implemented using the OpenCog framework.

Initial Applications

But what will OpenCog do?

OpenCog is fundamentally a framework, plus core components implemented within this framework. OpenCog can be used to do a variety of different things, including narrow-AI tasks. It's our hope that OpenCog will be used to build many systems, both narrow-AI and AGI, with widely differing orientations and capabilities.

We have inclinations about the first systems to build using OpenCog; we're particularly interested in

  1. Natural language conversation that is based on real understanding (NOT just chat-bot type stuff)
  2. Control of agents in online virtual worlds

OpenCog is in no way restricted to these two domains; they simply represent the founders' initial ideas for application-building using OpenCog.

Key Components of the Framework


The Atom (weighted, labeled node and link) representation used in the Novamente Cognition Engine, and briefly described in the paper "An Integrative Architecture for General Intelligence" at the Novamente website, will be supplied in OpenCog via an object called libAtomSpace.

libAtomSpace is a dynamic library which offers the AtomSpace API. It will have various internal components (to be described in detail here later) including an AtomTable, a TimeServer (providing efficient indexing of Atoms by time), SpaceServer (dealing with 2D spatial environments), etc. underneath, and will provide saving and loading as well as importing/exporting Atoms in OpenCog-XML.


The main component of the OpenCog framework is something called the CogServer.

This is the foundational server upon which OpenCog applications will be built.

It will:

  • Include an AtomSpace
  • Offer the notion of a cycle, which will be broken down into request processing and background tasks (the latter may also be called MindAgents). The former allow query processing, although there won't be any sophisticated scheduling in place (MindAgents need to have small cycle times).
  • Offer services through either a web services approach or a RESTful API (we currently lean toward the latter, as it's simpler).

The rationale for splitting the AtomSpace from the CogServer is that the AtomSpace is useful in itself for module development, automated testing, and for people learning about OpenCog. Link to the libAtomSpace and you can use it in your own executable.

CogServer is needed because, while an AtomSpace as a simple object is useful, most OpenCog applications will use it in similar ways: as a persistent knowledge store upon which requests are processed.

Initially, CogServer will expose the AtomSpace API as web services or REST. This is mostly toyish, but useful for testing and debugging tools. Real OpenCog applications will extend the API for their needs.

We still need to do the detailed design for the CogServer's API, including how to extend/customize it for individual applications, how to implement request handlers, etc.

Combo Interpreter and Procedure Execution Framework

Atoms are best for representing declarative knowledge (though they may also be used for representing procedural knowledge declaratively, which is sometimes useful).

For procedural knowledge, the initial tool to be integrated into OpenCog is the Combo language framework, developed by Moshe Looks and others within Novamente LLC, and utilized by the MOSES program learning algorithm.

Along with the interpreter, a ProcedureRepository object must be added to libAtomSpace to support coordinated storage of declarative and procedural knowledge.

Integration of Peripheral, External Tools

It would be nifty to see speech-to-text and text-to-speech tools integrated with OpenCog. This may not have a lot of deep AI value, but it's fun. No specific plans for this have been made though -- it won't be in the initial release.

Integration with Virtual Worlds and Robots

Virtual Worlds

It would be great to see a proxy created to allow OpenCog based systems to control agents in virtual worlds.

One way to achieve this would be to adapt the AGISim framework to OpenCog. AGISim has been used to interface the Novamente Cognition Engine with the CrystalSpace game engine, but it could also be used to interface with other virtual world frameworks such as Second Life or Multiverse.


Integration with physical robots is under way; OpenCog has been used with the Aldebaran Robotics Nao humanoid robot, via ROS. Another possibility is to use the PyRo python library.

AI Tools being Integrated into the Framework

We are not sure how much integration we'll get done before the initial release. But here are some tools that have been worked on since 2008.

Probabilistic Logic Networks

PLN is a complex and sophisticated approach to probabilistic inference, with numerous inspirations including Pei Wang's NARS system and Peter Walley's imprecise probability theory.

The math of PLN is described in a book titled "Probabilistic Logic Networks" to be released by Springer later this year (authors: Ben Goertzel, Matthew Ikle', Izabela Goertzel, Ari Heljakka).

Code implementing certain aspects of PLN (created at Novamente LLC) will be integrated into OpenCog, though nothing near a full PLN implementation initially.


MOSES is an algorithm for probabilistic evolutionary program learning, developed by Moshe Looks in the course of his 2006 PhD thesis, and described in his dissertation at

A version of MOSES is already open-sourced and available at Google Code, and in a prior version was integrated with the Novamente Cognition Engine, so integration with OpenCog is not expected to be problematic, but will still require effort.

A somewhat extended version of MOSES has been developed internally at Novamente LLC and will likely be open-sourced and integrated with OpenCog at some point.


A different algorithm serving the same basic purpose of MOSES, and integrable with MOSES in various ways, this is a speculative, possibly interesting algorithm conceived in 2008 by Ben Goertzel with a view toward working around certain shortcomings that MOSES may possess. A document on Pleasure has been uploaded to the Google Groups page associated with the OpenCog Google Group.

With luck, someone will implement Pleasure and integrate it with the OpenCog framework.


RelEx is a computational linguistics framework, built at Novamente LLC on top of the CMU Link Parser, which attempts to translate English sentences into Atoms of the type used in OpenCog.

It is actually not developed according to the "philosophy of AI" principles held by the OpenCog founders -- we would rather see language capability emerge naturally from an AI system's engagement with humans, as opposed to being programmed in.

However, there may be some value in proceeding by initially programming in linguistic capability and then letting it adapt over time based on system experience; an argument for this perspective is made in the paper "A Pragmatic Path Toward Endowing Virtually-Embodied AIs with Human-Level Linguistic Capability," which is linked to here.

Also, of course, it is anticipated that OpenCog may be utilized by individuals with a different AI philosophy, which may be more agreeable to the RelEx approach.

A NL generation framework based on RelEx is under development at Novamente LLC, and may or may not ever get finished; if it does, it will likely get integrated into OpenCog.

Economic Attention Allocation

Given a large AtomTable, how do MindAgents know which Atoms to pay attention to?

One system for solving this problem is to assign Atoms importance values (which may come in various flavors, e.g. ShortTermImportance and LongTermImportance) and then create a MindAgent whose job is to update these according to the system's needs in terms of its goals.

Some thoughts on an economics-based approach to this are given in this paper, and a variant of this may get implemented in OpenCog.


Work is proceeding on improving DeSTIN (a type of HTM)for use with OpenCog, and the OpenCog team has taken the lead in porting DeSTIN to CUDA for increased performance using GPGPU hardware.


OpenPsi, based on MicroPsi, provides goal creation for Embodiment.