NL-SOAR: GENERATION

Problem-Space Overview

• (Virtual-)Top
  • X-create-Operator
    • Sr-construct
      • Sr-generator
        • Construct-lexical-expression
          • Map-sem-to-lex
            • Imagine
    • Srcompletion

  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 generation is accomplished in NL-Soar. Processing can be divided into recognitional and non-recognitional components. Recognitional comprehension occurs via select-semobj and s-realize operators which select and realize (respectively) semantic objects as output sentences 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 s-realize, select-semobj, 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 an s-realize operator, for example, the language spaces look like this:

  • P: Virtual-Top
  • S: S_i
  • O: learn-language
    • P: X-create-operator
    • S: S_j
    • O: S-realize11
      • P: Sr-construct
      • S: S_j
        • P: Sr-generator
        • S: S_k
        • O: Sr-generate-op
          • P: Construct-lexical-expression
          • S: S_x
          • O: Pick-head
            • P: Map-sem-to-lex
            • S: S_y
            • O: imagine-head
              • P: imagine
              • S: S_z
              • O: learn-language
                • COMPREHENSION GOAL-STACK
  Note that comprehension is embedded in nlg: the nlc goal stack is subsumed in nlg. This is so that the same lexical and syntactic properties and constraints can be brought to bear in realizing utterances via nlg as in analyzing them via nlc. The operator no-change on the top-level learn-language operator is responded to using the X-create-operator space, which is analogous to nlc's create-operator space. Note that X-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 X-create-operator is responsible for gensyming a new, unique s-realize-op token (s-realize11 above). This token is then selected and an operator no-change occurs, and is responded to using Sr-construct. Thus, results returned to X-create-operator form the basis of the implementation of the s-realize operator.

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

  The state no-change in Sr-construct is responded to by the Sr-generator space, which finds the realize, access, and u-construct operators that eventually make up the actual implementation of the s-realize operator. When such operators have passed its constraints (done in subspaces not shown above) they are proposed in Sr-construct and their implementations there change the local A/R set (shared with X-create-operator).

  When all the changes that can be made, have been made by repeated descent into the Sr-generator and lower spaces, a final foray into Sr-generator results in an exhaustion operator.

  (discussion of bundling )

  Exhaustion results in the appearance of the ^annotation construction-done on X-create-operator's state. This, in turn, results in the return-operator proposing the new s-realize operator 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 s-realize operator. 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 s-realize operator is preserved at the top-level. In other words, if for any reason the construction of the s-realize operator is interrupted, there will be no top-level proposal. If the proposal chunk is built then and the s-realize operator is selected, its implementation is guaranteed to complete.

  This page written by Deryle Lonsdale based on the corresponding nlc one.