Problem-Space: (Virtual-)Top-ps [NL-Comprehension]

PROBLEM SPACE: (V)IRTUAL TOP

Result type: Operator Proposal

Problem Space Overview:

This is not necessarily the actual top problem space in the Soar stack (That's why this space could be also be called virtual-top problem space). NL-Soar assumes, in good neo-PEACTIDM fashion, that all of its top-level operators fire in the top space. This allows for all i/o and task/NL interaction to be mediated via the top space, as the neo-PEACTIDM model specifies.

Unfortunately, not all Soar systems are written in this fashion. In particular, some use the "Michigan" style, in which high-level goals and deep goal stacks can persist for long periods. In such systems, kicking out the top task operator to let NL-Soar have the top operator slot would destroy a lot of task state, much of which might not be recoverable. Even if it were recoverable, the task system will not have the necessary productions to do so, because NL-Soar could return control to the task in a situation not anticipated in the task's top-level productions.

The solution we have adopted is to allow NL-Soar to "pretend" that any appropriate problem space is really the top space, so that its top-level operators can fire there. Doing this required two modifications to NL-Soar:

Top-level NL-Soar operators can be proposed in any state marked with a ^language-ops-allowed yes attribute. This gives some flexibility to the task/NL interaction. For example, if only the top state has this flag, then we get a neo-PEACTIDM style NL-Soar. If only the bottom state gets the flag, then NL-Soar will fit cleanly into a "Michigan" style system, because it will not interfere with the task's goal stack. Other, more conditional, arrangements allow for more specific control of when task and NL operations can take place.
Every state marked with ^language-ops-allowed yes must also have a ^top-state attribute that points to the top state. This allows NL-Soar operators to have access to a single state for partial results even if they fire in different task spaces (as they may). Note that one consequence of this is that chunks built when NL-Soar is using the actual top state will be different than ones when NL-Soar operators fire in task sub-spaces, because in the former case the ^state and the ^top-state will be the same. This may cut down on transfer of chunks to some extent, but it will not cause any serious harm.

Thus, whether or not this state is the actual top state or the virtual top state, depends crucially on the style in which a Soar system was written when that system is integrated with NL-Soar.

Problem Space Proposal:

For systems written in Neo-PEACTIDM style, the (real) top problem space is proposed whenever the top goal is there.
For systems written in Michigan style, the (virtual) top problem space for NL-Soar is proposed in response to an operator-no-change impasse of an dummy operator in the real top space.

Initial state:

For systems written in Neo-PEACTIDM style, comprehension will augment the top-state S1 with the following attributes:
1. ^adjacency-info. Used primarily for generating the correct conditions for links and beads. Used also during constraints checking.
2. ^assigners. Part of the A/R set.
3. ^attended-auditory-input. The phonological buffer.
4. ^attended-speaker user. Indicates which speaker is being attended to.
5. ^build-semantics yes/no For turning semantics on and off.
6. ^for-formatting. Information needed for outputting the tree structure of the utterance model.
7. ^for-sem-formatting. Information needed for outputting the tree structure of the situation model
  .
8. ^io-state. A copy of ^top-state to accommodate Tacair code with inconsistent reference.
9. ^language-flag. Set to the value of the language being processed. Somewhat like a global nl-tasking flag.
10. ^language-ops-allowed yes. Indicates that language operators are allowed to get proposed and selected.
11. ^lexical-access-allowed yes. An obsolete attribute for accessing the lexicon. May be needed again for implementation of "re-access" or generation.
12. ^linkable. Used primarily for generating the correct conditions for links and beads.
13. ^lc-blippability-selection blippable-lc-operator. Indicates whether NL-Soar is in a blippable or non-blippable mode.
14. ^name initial-state. The name of the state.
15. ^new-lang-info. Holds all the CS structures for use during dialogue. S-constructors augment this attribute as LCS are instatiated.
16. ^nl-radio.
17. ^ordering-info. Used to determine which word to remove from the A/R set when there are more than 2 words competing for the same position in the set.
18. ^receivers. Part of the A/R set.
19. ^receivers-ids dummy. Indicates the root of a fully connected u-model. It could have three values; initially, the utterance model starts out empty, and this attribute is given the default value 'dummy'. Later on, if the u-model is fully connected, then the root of the tree will be the only value. If the u-model is a forest, there will be a micro-impasse since this is a uni-value attribute and this attribute will absent from the state.
20. ^segment segment7. Will be used for reference resolution.
21. ^sem-receivers-ids. Same as receivers-ids above, but for the s-model.
22. ^semassigners. For the semantics A/R set.
23. ^semlinkable. Like linkable above, but for semantics.
24. ^semreceivers. For the semantics A/R set.
25. ^sentence. Holds the words in the phonological buffer.
26. ^shared-nl-state-owner. This attribute appears only on the states of the real top space and the create-operator space. It indicates that these spaces have their own copy of the A/R set.
27. ^tasking. Annotating the operator currently being built. Used to mediate between comprehension, and generation problem-spaces.
28. ^tasking-annotation. Values can be u-model-constructor , s-model-constructor , s-realize , and all other top level operators. All these values are proposed when the operators are proposed and allowed to tie on this uni-attribute. Search control mirroring the top-space operator search control chooses the value and allows the appropriate operator to be constructed.
29. ^top-state S1. Points to the state of the real top problem space. Notice the value of this attribute is actually the state itself since the top space for NL-soar is the real top space in this case.
30. ^xval. For phonological buffer.
For systems written in Michigan style, the state S2 will have only three attribute-value pairs:
1. ^language-ops-allowed yes. Indicates that language operators are allowed in this space.
2. ^top-state S1. Points to the state of the real top problem space.
3. ^io-state S1. same as ^top-state.
The state of the real top space, S1, contains all the attribute-value pairs documented above for systems written in Neo-PEACTIDM style except for:
1. ^language-ops-allowed. This is because language operators are not allowed in the top space of systems written in Michigan style.
2. ^name. (don't think this attribute really matters)
3. ^segment. (will be dealt with later)

Operators in Problem Space:

Search control:

An empty u-constructor is always worse than any non-empty constructor. All empty u-constructors are indifferent. All different u-constructors are indifferent. Identical u-constructors with more word-id coverage are prefered, else they are indifferent.

All different s-constructors are indifferent. Identical s-constructors with more word-id coverage are prefered, else they are indifferent. U-constructors are indifferent to s-constructors.

The access operator has the best perference (which doesn't really matter because this will always be the first operator to execute before other operators are made available). The Learn-Language operator has the best preference. But u/s-constructors are better than other PEACTIDM operators (top*c*model-comprehend-over-other-peactidm), which means they are better than the LL operator.

Productions in the directory called top.

Back to the problem-space hierarchy.

This page written by Han Ming Ong (hanming@cs.cmu.edu) Updated by Julie Van Dyke (vandyke@cs.cmu.edu), August 1997