|
KEEPING THE
SYNTACTIC AND
SEMANTIC
MODELS
CONSISTENT
|
Overview
This page discusses how the syntactic (u-model) and the semantic (s-model) models are kept in synchronization
with each other and how one model can affect the construction of the other.
The changes discussed here were implemented for the 9701 release of nl-soar.
Why are the 2 models constructed separately?
First a reminder of why the s-model and u-model are not constructed within the same operator - i.e why we don't build comprehension operators that build both
syntactic and semantic models simultaneously.
If this were the case it would be easier to keep the two models consistent.
U-models and s-models are built separately because :-
- this will allow more chunk transfer especially between syntactic construction and syntactic generation.
- of the desired 'operator size' of constructors. A combined
comprehension operator might be too 'big' in a reactive domain such as TacAir.
- in Tacair it is sometimes possible and desirable (because of
speed issues) to turn syntactic comprehension off and only build semantic models.
The order of processing.
In the 9701 version of nl-soar an ordering of processing was imposed so that
the u-model is always built before the s-model. During the building of a
s-constructor, the u-model is consulted to make sure that both the existing
s-model and any proposed changes to the s-model are consistent with syntax.
If the s-model was to be built before the u-model then the s-constructor would
be checking consistency with an incomplete or out of date u-model.
Even if, at a particular stage of sentence processing, a chunked up
s-constructor operator is able to fire, a u-constructor learn language will
be preferred.
In order to impose this order changes had to be made to how u and s learn
language operators are imposed.
See top.force-syntax-before-semantics.soar .
Changes in the building of the u-constructor.
There are NO changes in the u-constructor building process. The process proceeds
as in previous versions of nl-soar without concern for the existing s-model.
In the future it might be possible to add code which does consult the
existing s-model (e.g. in search control) but, because of the imposed order
described above, the s-model will not be up to date (it will not incorporate
the most recent word).
Changes in the building of the s-constructor.
Most of the work in keeping the two models in synchronization are done whilst
building the s-model. The s-model could check consistency in three ways :-
- 1. By checking the consistency of the existing s-model with the newly
built u-model.
Here for more details
- 2. By checking that any proposed changes (i.e new fuses) in the s-model
are consistent with the newly build u-model.
Here for more details
- 3. By, during the constraint checking of a new fuse, ascertaining
semantically that a link in the u-model is incorrect. For a preliminary
implementation of this, click
here for more details
This page written by Mark H. Smith, April 1997.