Working memory
==============

Working memory contains the data representing Soar's current progress on all
of its goals.  It contains the current goals, problem spaces, states,
operators, and their substructure.

The data in working memory is organized into entities called *objects*.  An
object consists of a symbol, called its *identifier*, and *augmentations*,
which are attribute-value pairs.  Augmentations are the primitive
representational unit out of which all other representations are built and
will sometimes be referred to as *working memory elements*.

An identifier is a unique symbol, created when the object is first added to
working memory.  The actual names of identifiers are created by Soar, and
consist of a single letter followed by a string of digits, such as G37 or
O1022.  A *constant* is an atom.  Even if a constant "looks like" an
identifier, it will not act like an identifier in terms of matching.  A
constant is printed surrounded by vertical bars whenever there is a
possibility of confusing it with an identifier: |G37| is a constant while G37
is an identifier.  In semantic net terms, an identifier is a node and an
attribute is a link to a value. If a value is a constant, then it is a
terminal node with no links.

An augmentation contains the identifier of the object it augments, an
{attribute}, and a *value*.  Attributes and values can be either constants or
identifiers of other objects. An object can have multiple augmentations with
the same attribute and different values, creating a simple set
representation.  However, working memory is itself a set, so there cannot be
two augmentations with the same identifier, attribute, and value.

There is no predefined relationship between objects in working memory and
"real objects" in the outside world.  Objects in working memory may refer to
real objects, such as BLOCK A; a feature of an object, such as the color RED;
a relation between objects, such as ONTOP; classes of objects, such as
BLOCKS; etc.

Working memory supports the PSCM selection functions by maintaining a stack
of goal contexts, called the *context stack*.  Each goal context is
represented simply by augmentations of a goal object for the current problem
space, state, and operator. These three augmentations are called *context
slots* and the values of the context slots are called *context objects*.  A
goal can have any number of augmentations, but the problem space, state, and
operator augmentations are determined slightly differently than other
augmentations in working memory.

Figure ? provides a graphical depiction of a context for the Blocks World.
The circles denote identifiers, the arrows denote attributes, and the boxes
denote constant values.  The goal is the left-most circle, and it has
augmentations for the three context slots: problem-space, state, and
operator.  The values of each of these slots is an identifier with additional
augmentations.  For example, the operator has three augmentations
(moving-block, destination, and name), two of which have values that are
shared by augmentations of the state.

An augmentation is directional and provides an access *link* from the
identifier to the value.  The objects that are linked to an identifier are
called its *substructure*. Thus, the state in Figure ? is linked to the goal,
and the block with name A and color Red is linked to both the state and the
operator, and is thus linked indirectly to the goal.  All data in working
memory are linked directly or indirectly to the context stack.