OpenCogPrime:Concretely-Implemented Mind Dynamics

From OpenCog

Concretely-Implemented Mind Dynamics

The "cognitive dynamics" in a OCP system may be considered on two levels:

  1. the dynamics explicitly programmed into the source-code (these are the Concretely-Implemented Mind Dynamics, or CIMDynamics)
  2. the dynamics that are intended to emerge through the system's self-organizing dynamics, based on the cooperative activity of the CIMDynamics on the shared AtomSpace

Most of the material in these Wiki pages has to do with the particular CIMDynamics in the OCP system. In this section we will simply give some generalities about the CIMDynamics as abstract processes and as software processes, which are largely independent of the actual AI contents of the CIMDynamics.

In practice the CIMDynamics involved in a OCP system are fairly stereotyped in form, although diverse in the actual dynamics they induce.

As noted above, CIMDynamics could be coded in Combo and represented as grounded SchemaNodes, but in the current codebase they're hardcoded as C++ objects, for reasons of efficiency and (secondarily) programmer-convenience.

We return here to the trichotomy of cognitive processes presented in Cognitive Architecture Overview, in which OCP cognitive processes may be divided into:

In practical terms, these may be considered as three categories of CIMDynamic.

Control Process CIMDynamics are hard to stereotype. Examples are:

  • the process of "homeostatic parameter adaptation" of the parameters associated with the various other CIMDynamics
  • the CIMDynamics concerned with the execution of schemata in the ActiveSchemaPool

Control Processes tend to focus on a limited and specialized subset of Atoms or other entities, and carry out specialized "mechanical" operations on them (e.g. adjusting parameters, interpreting schemata). To an extent, this may be considered a "grab bag" category containing CIMDynamics that are not global or focused cognitive processes according to the definitions of the latter two categories. However, it is a nontrivial observation about the OCP system that the CIMDynamics that are not global or focused cognitive processes are all explicitly concerned with "control" in some sense.

Global and Focused Cognitive Process CIMDynamics all have a common aspect to their structure. Then, there are aspects in which Global versus Focused CIMDynamics diverge from each other in stereotyped ways. (And finally, of course, there are aspects in which particular CIMDynamics differ from each other, or they would not be different!)

In most cases, the process undertaken by a Global or Focused CIMDynamic involves two parts: a selection process and a main process. Schematically, such a CIMDynamic typically looks something like this:

  1. Grab a bunch of Atoms that it is judged will be useful to process, according to some selection process
  2. Do something with these Atoms, possibly together with previously grabbed ones (this is what we sometimes call the main process of the CIM-Dynamic)
  3. Go back to step 1

Of course, this way of breaking down dynamics is, like caching and multipart AtomSpaces, an artifact of the implementation of mind on von Neumann hardware. In a massively parallel system one would still have CIMDynamics but their construction would be different than what's described here, even if the AI effect were basically the same. Webmind 2000 used a somewhat different framework for structuring (its analogue of) CIMDynamics, because it tried to more closely mimic how CIMDynamics would be implemented on a parallel machine.

The major difference between Global and Focused cognitive processes lies in the selection process. In the case of a Global process, the selection process is very broad, typically yielding a whole AtomTable, or a very significant subset of one. On the other hand, in the case of a Focused process, the selection process is very narrow, yielding only a small number of Atoms, which can then be processed more intensively (and expensively, on a per-Atom basis).

Selection Processes

Formally, selection processes may be considered as part of the space of mappings

Selection-Process [ AtomSpace —> AtomSpace]

That is, they take in a large AtomSpace (for instance an AtomTable, in the implementation), and output a potentially smaller AtomSpace (the set of Atoms selected).

The selection processes we use now, in practice, can be understood as compositions of simpler selection processes of various types.

First, we have selection processes that may be termed high-level restrictions. For example:

  • The selection process that selects only the live atoms from a MultipartAtomspace
  • The selection process that selects only the atoms in a particular part of a MultipartAtomspace
  • The selection process that selects only the live or proxy atoms from a MultipartAtomspace
  • The selection process that selects only the live atoms in a particular part of a MultipartAtomspace

High-level restrictions make their choices based only on which part of a caching structure, and/or which part of a multipart structure, an atom lives in.

Then we have type-based restrictions, selection processes that pick only atoms of certain types (e.g. only nodes, or only binary Links, or only WordNodes, etc.) The key thing is that a type-based restriction makes its choices based only on relationship type or node type.

The above sorts of selection processes are used by both Global and Focused cognitive processes. That is, a cognitive process considered Global may still restrict itself to only live Atoms, or to only live Links, etc. The key point is that a Global process is iterating through a whole AtomTable or a huge fraction thereof and carrying out some cheap process on each Atom it visits — so its selection processes tend to be pretty simplistic and surface-level, not related to Atom "contents."

Then we have selection processes that may be termed fitness-oriented selectors, which are utilized by Focused cognitive processes. For example:

  • The process that picks one atom from a set with a probability based on some numerical quantity associated with the atom (e.g elements of TruthValue or AttentionValue)
  • The process that picks two atoms from a set, independently, with the probability of each choice based on some numerical quantities associated with that individual atom (e.g. elements of TruthValue or AttentionValue)

There are also more specific selection processes, which choose for example Atoms obeying some particular combination of relationships in relation to some other Atoms; say choosing only Atoms that inherit from some given Atom already being processed. There is a notion, described in the PLN book, of an Atom Structure Template — this is basically just a predicate that applies to Atoms, such as



( (Inheritance X cat) AND (Evaluation eats(X,cheese) ).tv

which is a template that matches everything that inherits from cat and eats cheese. Templates like this may be used to select Atoms from the AtomTable, which gives a much more refined selection than the above, more generic sorts of selection process.

All the SelectionProcesses in use in OCP now are obtained by composing a fitness-oriented selector with a type-based restriction with a high-level restriction. Let's call these standard selection processes. And all the CIMDynamics in use in OCP right now may be understood as composing Schema with standard selection processes.

What CIMDynamics Do With Selected Atoms

So, what do practical CIMDynamics look like in OCP today? As noted above, the meat of the CIMDynamics will be described in following chapters: they are a diverse bunch, as befits the richness of the emergent cognitive processes to which they are designed to collectively give rise.. In terms of their use of standard selection processes, however, some generalizations are possible. One way to say it is that there is a selection process that chooses some Atoms, and then a main process that takes these Atoms output by the selection process as input and

  • Sometimes gives other Atoms as output.
  • Sometimes modifies some of the numerical parameters associated with the input Atoms
  • Sometimes deletes the input Atoms


The next point to be made is more software architecture oriented. It is not convenient for OCP to do all its work directly via the action of MindAgent objects embodying CIMDynamics. In the NCE we found it necessary to augment the MindAgent framework with an additional scheduling mechanism that we call the Task framework. In essence, this is a ticketing system, designed to handle cases where MindAgents or Schema spawn one-off tasks to be executed — things that need to be done only once, rather that repeatedly and iteratively as with the things embodied in MindAgents. This does not yet exist in OCP as of July 2008, but it will need to.

For instance, grab the most important Atoms from the AtomSpace and do shallow PLN reasoning to derive immediate conclusions from them is a natural job for a MindAgent. But do search to find entities that satisfy this particular predicate P is a natural job for a Task. When a Task is created it is submitted to the TaskScheduler and then put in a queue behind any other Tasks with higher priority.

What one sees here is that, in the current implementation, practical issues have pushed us into making a number of distinctions that are not conceptually fundamental. We distinguish between MindAgents, Tasks and Schema; and in the current (July 2008) codebase, MindAgents and Tasks embody their operational code in separately-coded C++ rather than including internal schemata. When we move to a system in which MindAgents and Tasks contain pointers to SchemaNodes inside (which will be possible once we create a more efficient schema execution framework) then the definitions of MindAgent and Task will refer purely to scheduling. A MindAgent will be defined as a Schema that is executed by the system in every system cycle, and a Task will be defined as a Schema that has been put in the Tasks queue.