Go backward to Default knowledge in Soar.
Go up to Top.
Go forward to User Interface.

Encoding A Task in Soar
***********************

Encoding a task in Soar requires three stages: mapping the problem
description into the Problem Space Computational Model (PSCM), mapping the
PSCM description into the abstract Symbol-Level Computational Model (SLCM),
and then finally mapping the abstract SLCM on to the actual syntax of Soar.
The prior discussions of the Blocks World in Chapters *Note The Problem Space
Level:: and See Semantics of the Symbol Level emphasized the PSCM and
abstract SLCM.  In this chapter we map the pseudo-productions for the Blocks
World developed in Chapter See Semantics of the Symbol Level onto Soar.
This requires mapping the abstract descriptions of productions on to Soar's
syntax and deciding on the representations that will be used for the problem
spaces, states, and operators employed in the task.

Our approach will parallel the earlier presentations on encoding a task,
where the knowledge is organized by relevant PSCM level functions.  The basis
for the second stage is a set of templates for productions that perform the
various PSCM operations. 

In implementing a task, a decision must be made as to whether the task is
executed by manipulating and sensing an external environment, or through
internal simulation.  Often the decision is made by the task specification
itself, such as if Soar is being used to control a mobile robot.  But for
many tasks, especially those implemented as research projects, it is up to
the user to decide.  For example, in solving the Blocks World, do the blocks
exist outside of Soar, possibly in a simulator or on a table being viewed by
cameras?  Or is the problem a "mental" exercise for Soar, where it only
manipulates internal representations of blocks and it has direct and complete
control of their existence?  The first case requires the use of the input and
output facilities described in Chapter *Note Adding Input and Output
Routines::.

In this chapter we present an internal implementation of the Blocks World
where the goal is to place block A on top of B, and B on top of C, which in
turn must be on the table.  This presentation includes productions for all of
the required knowledge.  We will also present extensions to the original
description of the Blocks World in which we demonstrate all of the common
subgoals that arise during a task.  In these sections we will include
solutions to common problems that arise in Soar.  Many of the interface
functions from Chapter See User Interface are included in traces to
demonstrate their common uses.

Throughout this chapter we will include actual productions.  Each of these
productions has a name. We have created a set of conventions for naming in an
attempt to make it easy to determine the purpose of a production based on its
name.  The convention for naming productions is based on the following
template:

[context]*[PSCM function]*[PSCM object type]*[name(s)]

The [context] describes the general context in which this production is
applicable, usually the name of the relevant goal.  All default productions
have default as the context name. 

The [PSCM object type] is the type of context object that is affected by the
production, being either goal, problem-space, state, or operator.  The [PSCM
function] is the PSCM function performed by the production: proposal,
comparison, selection, refinement, evaluation, testing, application,
termination, and detection.  The [name(s)] is the the name of the PSCM object
the production is about, or some other descriptive term for the objects being
augmented.

Menu

Task representation
Starting Soar
Initialization of Soar
Proposal of the operator to perform the task
Subgoal creation for operator application
Problem space proposal for subgoal
Problem space refinement
Proposal of the initial state
Operator proposal
Operator comparison
Operator application
Operator termination
Task operator termination
Monitoring the problem solving
Using lookahead search