Problem space: generator

Operator Overview:

Each generate-operator operator is associated with an empty-op or a link operator that might eventually end up as the entire or a part of the u-constructor or s-constructor being constructed.

Operator Proposal:

The generate-operator operator associated with an empty-op operator is always proposed in the generator space. It is given a worse preference so that if a link or fuse is possible, it will be done. For non-empty u-constructors, NL-Soar looks at the A/R set and proposes the generate-operator operators associated with all the possible link relations. This is done with a simple match between assigners in a particular relation and receivers of the same relation. For example, if the sentence is "the man slept", the NP "the man" is on the receivers set in the Spec-IP relation, and the verb "slept" is on the assigners set in the Spec-IP relation. The generate-operator proposals look for these matches, while also hecking that the appropriate adjacency constraints are met. Consequently a word whose left-edge is not adjacent to the right-edge of another word can not be linked. This is true for the reverse case as well.

For u-constructors there are also a few specialized generate-operator proposals which are not based on the A/R set. These are for completing the projection of verbs: on for projecting to the IP and one for the CP-projection. The IP is projected using the downward-movement-projection pointer and the CP is projecting using the cp-projection pointer. The values for these pointers are assigned during lexical access.

The generate-operator proposals for S-constructors works quite differently because the semantic A/R set is set up differently. It is not possible in semantics to cleanly predict what category a particular receiver will receive its role from. For example, a THING could receive an internal role from either an ACTION, EVENT, or STATE. It could also receive the external role of a PROPERTY. It could additionally receive a role from any number of other categories providing there is sufficient knowledge to allow a semantic type coercion. Following the scheme used for u-constructors would cause the size of the Semantics A/R set to grow very quickly since every item would have to be a receiver of every other item. To solve this, we index items on the semreceivers set only under their own category and relax the constraint used in syntax that items must be in the A/R set in the same relation. To maintain the possibility for items to receive relations from any other, we generate all possible matches and rely on constraints to weed them out. Thus, the generate-operator proposals for fuse operators do not check for adjacent edges as is done with the syntactic link operators.

Generate-operator proposals for semantics differ from syntax in one additional way. The LCS of an item could have embedded psenses which may have their own embedded roles. For example, the verb "enter" has the psense GO which has an internal role with psense PATH which itself has an internal role of psense PLACE. In order to fill the embedded psense role, we have specialized productions to propose the appropriate fuse operators. These are needed because ordinarily only the root psense is indexed on the semantic A/R set so the embedded psenses would not be available to assign relations.

In addition to the above discussion of generate-operator proposals for semantic fuses, one additional specialized proposal exists for relative clauses: generator*propose-generate-operator*sem-link*non-ar-set*rel-clause . This proposal looks at the syntactic u-model to see if a relative clause exists. (Note this is rather different than the normal mechanism for keeping semantic and syntactic models in synchronization: normal fuse operators are proposed without regard for syntax and the compatibility is checked using the check-syntax constraint. )

The constraints for relative clauses have not been examined (so far they have not been required). The only constraints proposed for the clause-property fuse are dummy-constraint and a constraint that is specific to clause-properties which currently always passes (constraints*check-syntax*rel-clause*ok). Proposals for other constraints have been changed so they do not fire for clause-property roles.

The clause-property fuse is implemented in the same way as the property fuse.

Operator Application:

The search control in the generator space dictates that generate-operator(empty-op) is worse than generate-operator(link) or generate-operator(fuse) and that generate-operators(link) and generate-operators(fuse) are indifferent. Thus, if there is one or more acceptable non-empty generate-operator, one of them will be selected. Once a non-empty generate-operator is selected, there will be an immediate operator no-change impasse since NL-Soar does not know how to implement it. The constraints space will be selected to test if the link associated with the selected generate-operator operator is possible. If the link passes all the contraint tests, then it will be proposed and implemented in the u-constructor space.

On the other hand, if there is no generate-operator(link) operators, generate-operator(empty-op) will be selected and an operator no-change impasse will follow. The unconstraints space responds to this impasse and various beads will be proposed.

Operator Reconsider:

The operator is reconsidered when constraint checking annotates the operator with constraints-passed or failure.

Examples

For u-constructor

generate-operator(link(have.i--spec-->i.n))

For s-constructor

generate-operator(link(have.state--external-->i.thing))

Productions are in file: generator.generate-operator.soar

Back to the operator hierarchy.

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