NL-Soar Comprehension

Summary

Comprehension in NL-Soar involves constructing models of the utterance which represent the grammatical structure and the semantic situation. The model of grammatical structure is referred to as an utterance model or u-model and the model of the semantics situation is a situation model or s-model . These models are constructed using operators called u-constructors (or u-model-constructors) and s-constructors (or s-model-constructors). Each u- or s- model constructor is learned during deliberate processing, and once learned, executes in a problem-space called Top . (The problem-space is a basic Soar term to describe a defined collection of knowledge, usually relating to particular operators. For more information see Unified Theories of Cognition (1990). Newell, Allen. Harvard Press, Cambridge, MA or the Soar Users Manual .) The deliberate processing used to learn these operators is itself a collection of problem-spaces, organized in a goal hierarchy that allows NL-Soar to build the proposal, implementation, and termination of the operator independently.

Problem-Space Overview

This documentation is organized according to the various problem-spaces involved during the construction of s- and u-model-constructors. The deliberation problem-space hierarchy looks roughly as seen below. Click on the problem space name to see the operators and elaboration knowledge in that space.

Operator Hierarchy

The operator hierarchy can be reached from here.

Processing Overview

The problem space hierarchy shown above is the mechanism by which word-by-word comprehension is accomplished in NL-Soar. Processing can be divided into recognitional and non-recognitional components. Recognitional comprehension occurs via u-construct and s-construct operators which build utterance and situation/discourse model structures (respectively) on a word-by-word basis, without impasse. This recognitional capability is acquired from learning over impasses on the learn-language operator, as outlined below.

It is important to note that u-constructors, s-constructors and learn-language operators are the top-space language operators, i.e. each fires only in the virtual-top-space. The virtual-top-space is Soar's actual top-space in systems organized in the Neo-PEACTIDM style. In traditional, or Michigan-style, systems, search control is provided as part of NL-Soar that defines the bottom-most task problem space on the goal stack as the virtual-top-space. For other styles of system, search control can be defined to allow for interleaving of top-space language and task operators as appropriate.

Building a constructor in NL-Soar proceeds from an unusual configuration of the goal stack. When building a u-constructor, for example, the language spaces look like this (an s-constructor is analogous):

The operator no-change on the learn-language operator is responded to using the Create-operator space. Note that Create-operator copies relevant structure from the virtual-top space, effectively walling off the learning process from changes to the top-state structures that may occur while in the impasse (but for exceptions to this apparent loss of reactivity, see blippability).

Knowledge in Create-operator is responsible for gensyming a new, unique u-constructor token (u-constructor11 above). This token is then selected and an operator no-change occurs, and is responded to using U-construct. Thus, results returned to Create-operator form the basis of the implementation of the u-constructor.

U-construct exists to ensure atomaticity in the implementation of the u-constructor. The result returned from U-construct constitutes the complete set of changes to the model structures that is the implementation of the new u-constructor. Thus, U-construct acts as a mechanism for packaging these changes which are made individually and sequentially within the space. Note that U-construct operators (link and snip) make their model changes but only after the changes have been shown to be valid. Also note that Create-operator and U-construct share state; this is critical because it means that any result returned to U-construct will form the basis for both proposal conditions AND implementation conditions.

The state no-change in U-construct is responded to by the Generator space, which finds the links, snips, or empty operator that eventually make up the actual implementation of the u-constructor. When a link or snip has passed its constraints (done in subspaces not shown above) it is proposed in U-construct and its implementation there changes the local A/R set (shared with Create-operator).

When all the links and snips that can be made, have been made by repeated descent into the Generator and lower spaces, a final foray into Generator results in an exhaustion operator. Exhaustion results in the appearance of the ^annotation construction-done on Create-operator's state. This, in turn, results in the return-operator proposing the new u-constructor in the virtual-top state, terminating the learn-language impasse.

Note that the resolution of the impasse on learn-language is an operator proposal for the new u-constructor. Thus the proposal chunk gets built when this result is returned. Since the implementation has already been built during the processing that leads to the proposal, the atomaticity of the resulting u-constructor is preserved at the top-level. In other words, if for any reason the construction of the u-constructor is interrupted, there will be no top-level proposal. If the proposal chunk is built then and the u-constructor is selected, its implementation is guaranteed to complete.

This page written by Jill Fain Lehman (jef@cs.cmu.edu) and Han Ming Ong (hanming@cs.cmu.edu)

Updated by Julie Van Dyke (vandyke@cs.cmu.edu), August, 1997