Proceedings of the 3rd Workshop on Scalable Natural Language Understanding, pages 49–56,
New York City, June 2006. c©2006 Association for Computational Linguistics
Scaling Construction Grammar up to Production Systems: 
the Situated Constructional Interpretation Model 
 
Guilaume Pitel 
Langue et Dialogue 
LORIA 
BP239 5400 Nancy, France 
Guillaume.Pitel@gmail.com 
 
 
 
 
Abstract 
While a great effort has concerned the de-
velopment of fuly integrated modular un-
derstanding systems, few researches have 
focused on the problem of unifying exist-
ing linguistic formalisms with cognitive 
processing models. The Situated Construc-
tional Interpretation Model is one of these 
attempts. In this model, the notion of “con-
struction” has been adapted in order to be 
able to mimic the behavior of Production 
Systems. The Construction Grammar ap-
proach establishes a model of the relations 
between linguistic forms and meaning, by 
the mean of constructions. The latter can be 
considered as pairings from a topologically 
structured space to an unstructured space, 
in some way a special kind of production 
rules. 
1Introduction 
Accounting for pragmatical and cognitive phe-
nomena in a linguistic formalism is a challenging 
task whose resolution would be of great benefit for 
many fields of linguistics, especially those dealing 
with interpretation in a context. In domains such as 
practical dialogue or embodied understanding, 
there would be a real gain in dealing with envi-
ronment data the same way one deals with linguis-
tic data. These kinds of systems currently need ad 
hoc heuristics or representations. These heuristics 
are implemented in modules that are often impos-
sible to reuse for another task than the one they 
were developed for. This point particularly con-
cerns phenomena that lay at the interface of lin-
guistics and general cognition, such as vagueness 
(Ballweg, 1983), reference resolution (Brown-
Schmidt, 203; Reboul, 199), or modeling of 
cognitive representations (Langacker, 1983; 
Talmy, 198). 
Similarly, accounting for linguistic phenomena 
in a psychologically motivated model is far from 
simple. The attempts in that direction are often 
limited to simple phenomena, because all linguistic 
formalisms rely on principles slightly or totally 
different from those of cognitive architectures. 
The definitive solution to this problem is proba-
bly stil far from reach, but nevertheless, I think 
that the maturity of cognitive linguistics and the 
consequent emergence of language analyzers con-
nected to cognitive architectures is an excellent 
direction toward a unified theory mixing linguistic 
and psychological models. The Embodied Con-
struction Grammar or ECG (Bergen, 203) and its 
analyzer (Bryant, 203) are a god example of 
such an effort, even though it does not go beyond 
the linguistic layer since mental simulation is left 
to a mental simulation module based on the notion 
of x-schema (Narayanan, 201). 
Consequently, I try to propose a model that con-
ciliates a linguistic theory with a cognitive archi-
tecture. The choice of the linguistic theory 
naturally goes to Construction Grammar (Filmore, 
198; Kay 202) and Frame Semantics (Filmore, 
1982), due to the parallel one can draw between a 
production rule and a construction, and the cogni-
49
tive architecture is, obviously, the family of Pro-
duction Systems (Newell, 190; Anderson, 193). 
Moreover, since many pragmatical models rely on 
topologically structured representation, I introduce 
the notion of context, a notion that has never been 
adapted to these theories in order to organize data 
in “storages” structured in disimilar ways. 
1.1 Typical Problem 
Consider a situation where a user can command a 
software to manipulate some very simple objects 
(colored geometrical objects of various sizes). The 
user may say (a) “Put the small red square on the 
left”, (b) “Remove the small red square on the left” 
or (c) “Move the small red square on the left”. 
First, these three uterances may involve differ-
ent parsing depending on the actual environment of 
the uterance, at least for those with “put” and 
“move”. Second, the “square” targeted by the user 
may be a rectangle in the actual software represen-
tation, with slightly different width and height. It 
may also be relatively small compared to other red 
squares, but biger than other objects, and rela-
tively red compared to other non-square objects. 
Imagine what happens in the different situations 
ilustrated in Figure 1. In situation 1, for instance, 
(a) would not be understandable, since the small 
square is already on the left, while (c) could lead to 
the one argument sense of “move”, i.e. “move 
something somewhere else”, not to the two argu-
ments version “move something somewhere” (ac-
tually, the one-argument sense is an implicit 
understanding of the destination allowed by 
“move”, so the difference should not be lexical-
ized). In situation 2, (b) and (c) would lead to two 
different interpretations of the referring expression 
“the small red square on the left”: in (b), it refers to 
the square in the center (with a posible wavering), 
while it preferably refers to the square on the right 
in (c). In situation 3, (c) may be interpreted with 
the one argument sense of “move”, and wil target 
the square on the left since it is the smallest, but 
there should be a strong hesitation, since the other 
square is not that biger, and the two arguments 
sense of “move” is intuitively preferred. At the 
same time (a) wil target the square on the right, 
which is relatively small compared to the neigh-
boring circles, but would raise incomprehension if 
the circles were mising. 
In general, in order to take those facts into ac-
count, it is necessary either to produce all posible 
analyzes at each layer of the interpretation (which 
is quite problematic if it is desirable to allow for 
imperfect analyzes), or to allow two-ways interac-
tions between the layers of interpretation (for in-
stance, the pragmatic layer talking back to the 
semantic layer about the fact that the original posi-
tion of an object is the same as the requested desti-
nation, which may indicate a wrong analysis). 
My proposal is to allow for a generic capacity of 
interaction between the states of the interpretation 
(speaking about states is better than about layers 
since the latter presuposes something about the 
organizing of the interpretation), based on a unified 
operation between all the posible states. More 
specifically, the idea is to merge the notions from 
construction grammar and productions systems. 
1.2 Merging Construction Grammar and 
Production Systems 
Merging a linguistic analyzer with a cognitive 
processing model may seem a bit useless since 
they do not share the same objective. Linguistic 
analyzer’s goal is to provide a formal model for the 
representation of linguistic knowledge, accordingly 
to linguistic observations. Cognitive models, on the 
other hand, aim at helping the modeling of real 
cognitive processing, in order to compare theoreti-
cal model of perception processing with real data 
from experiments. Cognitive models like produc-
tion systems being Turing-equivalent, they typi-
cally do not lack of any expressiveness, meaning 
that anything one can describe with any linguistic 
representation could be implemented within a cog-
nitive model (hopefuly, since linguistic compe-
tence is part of the cognitive competence). 
 
Figure 1: Some situations involving different 
understandings (without color). 
50
However, to my knowledge, no attempt to try 
describing a linguistic competence within a cogni-
tive model has gone a long way. Existing re-
searches on that topic have focused on very narrow 
problems, and what is more important, have been 
tightened to very small lexicons (Emond, 197; 
Ball, 203; Fowles-Winkler and Michaelis, 205). 
My analysis of this problem is that production 
systems are to permisive to allow a human to 
describe a grammar with a reasonable effort. More 
specifically, all generalization links that exist be-
tween grammar rules should be encoded in some 
explicit way in a production system. 
Furthermore, linguistic formalisms are designed 
in such way to only express all posible human 
languages. In other words, a linguistic formalism is 
successful when it is flexible enough to describe all 
linguistic phenomena, while being human-readable 
enough to allow for a large-scale grammar devel-
opment. As a consequence, linguistic formalisms 
are to restrictive to allow dealing with cognitive 
processes like the ones described using production 
systems. 
Puting together a linguistic formalism and a 
model of pragmatical and cognitive processing 
implies to make a choice among all the current 
theories. Given the large predominance of produc-
tion systems in cognitive modeling, it seems quit-
natural to chose them as the cognitive model. The 
choice for the linguistic formalism is more open. 
Previous attempts of linguistic modeling in cogni-
tive models have used 
! 
X
 theory, categorical gram-
mar or construction grammar. My pick has been 
the construction grammar because it shares some 
interesting features with production systems, and 
and because it deals directly with semantic, con-
trary to other grammatical theories. Particularly, 
constructions are pairing between to poles: form 
and meaning, this is very similar to the notion of a 
production taking one input from a chunk, and 
producing its output into another one. 
1.3 Example of procesing 
In such an approach, what should happen when 
interpreting “move the smal square on the left” in 
situation 3 on the Figure 1?  The first step of the 
analysis (simplified for sake of clarity), ilustrated 
in Figure 3, shows how “move” produces a predi-
cate that encompasses a Cause-Motion schema, 
itself evoking a Source-Path-Goal (SPG) and a 
Force-Action (FA) schema. The CxMove construc-
tion adds a constraint about the fact that source and 
goal should differ. 
After this, two constructions CxImperative can 
conect, through their theme role, the referents 
evoked by the RefExp shemas (each construction 
being one posible interpretation) with the source 
of the Source-Path-Goal. The CxImperative encap-
sulates the predicate in a Request schema. Another 
construction can conect the goal of the Source-
Path-Goal with the Spatial-P produced from “on 
the left”, with the predicate modified by the con-
struction that tok its RefExp from “the small 
square”. 
At this point, the “mental simulation” required 
to resolve the referents can start. This step is ilus-
trated in a very simplified way in Figure 2. The 
complete process is described in (Pitel, 204; Pitel 
Figure 2: Mental simulation of the reference 
resolution 
 
Move the smal square on the left 
Cause-
Motion 
Ref-Exp Spatial-P 
Ref-Exp 
CxMove 
CxRefExpSp 
CxSpatialP 
Visual Context 
Resolution Context 1 
Resolution Context 2 
 
Figure 3: First step of analysis, the global 
construction (Imperative) is not active yet. 
SPG 
FA 
51
& Sansonet, 203) and processes potential refer-
ents through several sorting steps, one for each 
referential predicate (here: square and smal in 
Resolution Context 1 from the two-arguments 
move interpretation; square, smal and on the left 
in Resolution Context 2 from the other one). The 
process is described with the kind of constructions 
defined by the SCIM. 
2Basic Notions of the SCIM 
The Situated Constructional Interpretation model 
(SCIM) describes how information can be proc-
essed in a way that is both linguistically and psy-
chologically plausible. It relies on three notions: 
schemas are for low-level data description, con-
texts are for describing the organization of in-
stances of schemas, and s-constructions represent 
the mean to process data. Eventually, a SCIM-
based interpretation system wil run instances of s-
constructions that take and produce instances of 
schemas situated in instances of contexts. These 
three notions are partly inherited from the ECG. 
2.1 Schemas 
Schemas are constrained, typed features struc-
tures, with an inheritance mechanism and no type 
disjunction. Schemas are a kind of data type. They 
describe complex structures of information used to 
represent the state of the runing interpretation. As 
shown in Figure 4, schemas are defined with three 
blocks: 
 inherits schema-name
1
, …  which specifies 
from which schema(s) this one inherits from. a 
specific case of the schema x, it inherits all of 
its properties (roles and constraints). 
 roles, which specifies a list of roles, con-
strained to a given schema type or atomic type 
(Integer, Boolean, String, or user-defined 
enumerations of symbols). 
 constraints, which specify the constraints that 
must be verified in order for an instance of the 
schema to be a valid one. A constraint can be a 
predicate if the role has an atomic type, or an 
identification constraint (asserting that two 
roles must share the same value), or a filer 
constraint with a constant value. 
An instance of schema is moreover described 
by values attached to its roles (some or all of them 
may be left underspecified), a unique identifier, a 
positive value representing its informative capac-
ity, a percentage of trust level, and the list of its 
parents’ identifiers. A parent of an instance of 
schema is an instance of schema “used” in the 
process that led to its production. It is thus posi-
ble, in a s-construction, to know hether two given 
instances of schema are somehow related to each 
other in the interpretation process. 
 
schema <schema-id> 
inherits <schema-id
0
, .., schema-id
n
> 
Roles 
[?]<local-type-id>:<atomic-type-id> 
[?]<local-context-id>:<context-id>[@<local-context-id>] 
[?]<local-schema-id>:<schema-id>[@<local-context-id>] 
Constraints 
<bolean-operation>(<constraint
0
>, .., <constraint
n
>) 
<role-id> ← <atomic-value>|<function>(<atomic-
value>,…) 
<role-id> ↔ <role-id>|<C-function>(<role-id>) 
<role-id> = <role-id> 
<bolean-predicate>(<role-id
0
>, .., <role-id
n
>) 
 
a <role-id> is one of: 
 self (optional if not used alone) 
 <local-type-id> 
 <local-context-id> 
 <local-schema-id> 
 <inherited-schema>*<inherited-role-id> 
 <role-id>.<sub-role-id> 
 
Figure 4: Schema definition formalism. 
 
From the production systems perspective, sche-
mas define the type of features that can be attached 
to a category. Basically, in that point of view, an 
instance of schema is a chunk and roles are slots. 
Schemas hierarchy  
Schemas can inherit roles and constraints from 
other schemas. That means that schemas are orga-
nized in a multiple inheritance hierarchy. In order 
to avoid ambiguity in role access, inherited roles 
must be accessed through an inheritance path. For 
instance, accessing the role color in a schema 
Square, if the hierarchy is Fig-
ureRectangleSquare, and where the color role 
is declared in the Figure schema, would be realized 
through this kind of path: Rectangle*Figure*color. 
52
Inheritance also means that an instance of 
schema S can be unified with a role whose type is 
R if S = R or if R is one of the parents of S. 
One problem with this approach of inheritance is 
that, in order to fulfil the Liskov substitution prin-
ciple (Liskov, 198), it is sometimes necesary to 
use unatural type hierarchies (stating that Square 
doesn’t inherit from Rectangle, for instance). I am 
very mindful about this problem, since such a dis-
crepancy is quite tedious for a model that aims to 
approximate the human way of processing infor-
mation, but this problem is out of the scope of this 
paper
1
. 
Constraints 
A schema declaration contains a set of constraints 
that must be satisfied in order for an instance of 
this schema to be considered valid. Constraints are 
specified with six basic forms:  
 Type constraints on roles. 
 Boolean operation (OR, NOT, NAND,…) 
conecting several constraints. 
 Filer constraint symbolized by a single arrow 
(←) specifies that a constant, atomic value 
must fil the role in an instance. 
 Identification constraint, symbolized by a 
double-headed arrow (↔), specifies that both 
sides of the constraint must unify, that is, all 
roles’ values must be compatible with each 
other. 
 An equality constraint (=) that constrains two 
roles to refer to the same instance. 
 A boolean predicate constraint can be as-
serted between any number of roles. 
Another kind of constraint, on the places occu-
pied by instances of schema in context, wil be ex-
plained in the section about s-constructions, as wil 
                                                             
1
 We consider that this problem could be solved by the ap-
proach caled “Points of View Theory” (which is not related to 
inter-person points of view), proposed by Pitel (204). In this 
theory, there is no type hierarchy, and the ability to substitute 
a representation by another is described by rules that can take 
the dynamic context into acount. In this aproach, types do 
not represent concepts, but points of view on perceptions (in 
the wide meaning), and transition from one point of view to 
the other is context-dependent. 
the role of interrogation marks in the schema dec-
laration formalism. 
2.2 Contexts 
A context declaration is a description of a container 
that can hold instances of schemas. In other words, 
it describes a space (including the topology part 
that can be specified by a set of relations and op-
erations) that can contain pointers to instances of 
schemas at given places. 
The notion of context inherits all of the proper-
ties of the notion of schema. Actually, a context is 
really a kind of schema and, as a consequence, a 
schema’s role can be restricted to be a context. A 
declaration of context adds three more blocks to 
the declaration of a schema, as shown in Figure 5: 
 places declare a list of opaque types (the inter-
nal structure of the type is hiden in the im-
plementation) that describe an acceptable 
position in the context. Instances of schema (or 
context) that wil be contained in an instance 
of this context wil be linked with a position 
whose type is one (and only one) of the de-
clared places. Examples of places are: point, 
segment, multi-segment, line, box, disc, … 
context <context-id> 
inherits <context-id
0
, .., context-id
n
> 
Roles 
 / idem schemas roles 
Constraints 
 / idem schemas constraints 
Places 
 <place-id> 
Relations 
 <relation-id(<place-id>, <place-id>,..)> ↦  <type-id> 
 / for instance: before(point, point) ↦  Bolean 
Operations 
 <operation-id>(<place-id>, <place-id>,..) ↦  <place-id> 
 / for instance: intersection(segment, segment) ↦  segment 
Figure 5: Context definition formalism 
 
 relations are functions that associate a value in 
an atomic domain from one or more places. 
Relations define constraints on the positions of 
a set of instances of schema. For instance, one 
can define a precedence relation in a linear 
context. 
53
 operations are functions that associate a posi-
tion from one or more positions. For instance, 
a union of segments is an operation. 
Terminologically, an instance of schema (or 
context) located in a context, that is, an instance 
with a place, wil be called a situated instance, 
whereas an instance of schema (or context) simply 
conected to another instance by a role wil just be 
called a role instance. 
The only explicit equivalent to contexts in ECG 
is the notion of space, which describes Fau-
conier's mental spaces (Fauconier, 1985). Im-
plicit contexts are however used in Construction 
Grammar: the form pole, which stores instances of 
schemas representing linguistic data in a linear 
space, and the unstructured meaning pole. 
 
s-construction <s-construction-id> 
inherits <s-construction-id
0
, …, s-construction-id
n
> 
roles / idem schema's roles 
constructional 
 <local-s-constr-id>: <s-construction-id> 
constituents 
 <local-ctx-id>: <context-id>[@<local-ctx-id>]/I|O|IO 
 <local-constit-id>: <schema-id>[@<local-ctx-id>]/I|O|IO 
constraints 
 / idem schemas constraints, plus : 
 / a role-id can be marked as muted: ?<role-id> 
 / a place-id is either a <local-constit-id> or the result of a 
context operation like: 
 / <local-ctx-id>.<context-operation-id>(<place-id>, ..) 
 <role-id> ⊂ <role-id> / right hand side must be parent 
 <local-ctx-id>.<context-relation-id>(<place-id>, ..) 
 OUT(<local-constit-id>) / remove the situated instance 
Figure 6: S-construction definition formalism 
2.3 S-constructions 
S-constructions are situated constructions, that is, 
constructions that describe the relations between 
several instances of schemas located in structured 
contexts. As for the notion of context, the notion of 
s-construction is derived from the schemas, be-
cause the s-construction itself can hold informa-
tion. Besides that, the declaration of a s-
construction contains: 
 A constructional block that describes the 
other instances of s-constructions this s-
construction relies on. The block contains a 
list of label: s-construction-name declara-
tions. Any restriction on the constituents of 
those instances of s-construction is de-
scribed as a constraint on label.constituent 
in the constraints block. 
 
 A constituents block that describes the in-
stances of contexts and schemas constrained 
by the s-construction (note that the meaning 
of constituents is different than in ECG). 
The declaration of those constituents speci-
fies whether the instance must preexist 
and/or whether it may be created or speci-
fied by the s-construction’s constraints. 
From a production system point of view, it 
means that we describe which instances are 
in the input, and which one are produced. 
S-constructions hierarchy  
Like schemas, s-constructions are organized in a 
multiple inheritance hierarchy. Moreover, s-
constructions benefit from a mechanism of con-
structional dependence, held by the constructional 
block. Those two notions are, to some extent, re-
dundant. Indeed, inheriting from a s-construction is 
equivalent to having an instance of this s-
construction in the constructional block. However, 
one can have two different instances of the same s-
construction in the constructional block, whereas it 
is imposible to inherit twice from the same s-
construction. Moreover, it is posible to add a 
negative semantics in the constructional block, in 
order to assert that some instance of s-construction 
must not have occurred to satisfy the s-
construction’s conditions. 
The constructional block is thus more powerful 
than the classical inheritance relation, but as for the 
schemas hierarchy, it is not within the scope of this 
paper to discus about the inheritance relations be-
tween s-constructions. A declaration of s-
construction is thus, from that point of view, in 
conformance with the standard view shared in con-
struction grammars. 
Situated aspects of s-constructions 
A s-construction can “chose” instances of sche-
mas, given positional constraints in the context 
where the instances of schemas are stored. Then, 
the s-construction wil “create” new instances of 
context or schemas, or wil specify some previ-
ously underspecified role’s value. S-constructions 
54
can conect together more than two instances of 
schema. To that extent, it differs from ECG's con-
struction (ECG's way of doing so makes use of an 
evoke block). 
The specification of structural constraints is very 
similar to the other constraints. A structural con-
straint loks like this: context-id.relation(roles-in-
context-id). Basically, a context relation is consid-
ered as a bolean predicate constraint. The main 
difference is that, instead of specifying the roles, 
such a constraint specifies the place of the instance 
of schema referred to by the role. 
Dynamic aspects 
The bigest gap between productions systems and 
construction grammar is the difference between the 
dynamic nature of productions versus the declara-
tive nature of linguistic constructions. For instance, 
a typical rule in a production system (from the 
ACT-R tutorial) would be represented in Figure 7. 
In order to take this posibility into account, it is 
necessary to introduce at some point some impera-
tive features in the s-construction. 
Imperative features are introduced through sev-
eral mechanisms. The first one is about role in-
stances, the second one is about situated instances 
and the third one is about specifying constituents 
acting as inputs and/or outputs. 
 
ACT-R declaration English description 
(p start  
  =goal> If the goal is 
 ISA count-from  to count from 
 start =num1  the number =num1 
 step start  and the step is start 
=> Then 
  =goal>  change the goal 
 step counting  to note that one is now counting 
  +retrieval>  and request a retrieval 
 ISA count-order  of a count-order fact 
 first =num1  for the number that folows 
=num1 
)  
Figure 7: Example of ACT-R rule with a value 
changing 
 Mutable roles. In the roles blocks, they are 
specified by a question mark (?).  If a role is 
marked as mutable in a schema declaration, 
then it can be accessed through two means in a 
s-construction constraint. The usual way con-
strains the state of the role instance before the 
application of the s-construction, the mutated 
way constrains the state of the role instance af-
ter the application of the s-construction. 
 Removable situated instances. The constraint 
OUT(<constituent-id>) specifies that the situ-
ated instance must be marked as not being pre-
sent anymore in its context, after execution of 
the s-construction. 
  Input and/or output constituents. Each con-
stituent of a s-construction is marked with a 
symbol /I or /O, stating whether the situated 
instance should be present before and whether 
it wil be modified. 
3Computational Aspects 
Given the characteristics of the SCIM, its expres-
siveness and its procedural orientation, one canot 
occult the problems that it raises from the compu-
tational point of view. Building an implementation 
of the Situated Constructional Interpretation Model 
definitely means to give up the idea of conducting 
a complete exploration of the search space. 
The main problem is that two s-constructions 
may lead to contradictory constraints. In other 
words, one must keep track of all the decisions and 
explore all the posibilities. 
The problem is even worse with mutable in-
stances, since some constraints may be satisfied at 
some moment in one posible interpretation, while 
being unsatisfied at another moment. This time 
dependence must be handled very carefuly, and 
adds some complexity to the procesing of con-
straints. 
However, the model also presents some interest-
ing features, computationally speaking. For in-
stance, it is quite easy to add a weighting layer to 
the SCIM, in order to simulate expectation, infor-
mational potential, or execution cost. Such a layer 
could be trained to learn how to lead to the best 
interpretations at a minimal cost. 
4Conclusion 
In this paper I propose and describe a model of 
interpretation both linguistically and psychologi-
cally motivated. This model allows describing a 
construction grammar as well as a production sys-
tem, with three basic notions: schemas, contexts 
55
and s-constructions. Aplications for such a model 
are wide, from more integrated dialogue systems to 
a unified theory of cognition and language. 
A longer description of the processing architec-
ture would be necessary in order to really confront 
the hypotheses I made in the section “Computa-
tional aspects”, but nevertheless, one can already 
draw a parallel between this model with a spatial 
structuring of information, and the structure that 
neuromimetic models can handle. Also, incomplete 
exploration of the search space, guided by a 
cost/gain approach, has previously been proposed 
as a plausible model of processing for human cog-
nition. More than computational efficiency, the 
goal of this model is to propose a formalism that 
would be easier to use both for linguistic and cog-
nitive modeling, in order to observe and act on the 
simulated processing of language and other cogni-
tive functions. 
Many of the claims in this paper have yet to be 
proved through the implementation of the SCIM, 
and cognitive modeling using the system. Since 
many processing models have been made both on 
construction grammar and production systems, 
important researches should be easy enough to re-
use in the SCIM. 

References 
John R. Anderson (193). Rules of the Mind. Erlbaum, 
Hilsdale, NJ. 
Jery T. Bal (203). Beginings of a language compre-
hension module in ACT-R 5.0. In F. Detje, D. Do-
erner, & H. Schaub (Eds.), In Procedings of the 
Fifth International Conference on Cognitive Model-
ing (p. 231-232). Bamberg, Germany: Universitats-
Verlag Bamberg. 
Joachim Balweg (1983). Vaguenes or context-
dependence? supervaluation revisited in a semantics 
based on scales. In T. T. Balmer and M. Pinkal, edi-
tors, Aproaching Vaguenes, pages 59-78. North 
Holand, Amsterdam. 
Benjamin K. Bergen & Nancy Chang (203). Embodied 
construction gramar in simulation-based language 
understanding. In J.-O. Ostman and M. Fried, editors, 
Construction Gramar(s): Cognitive and Cros-
Language Dimensions. John Benjamins, 
Sarah Brown-Schmidt & Michael K. Tanenhaus (203). 
Referential domains and the interpretation of refer-
ring expresions in interactive conversation. In Proc. 
of Diabruck 203, Seventh Workshop on the Seman-
tics and Pragmatics of Dialogue (SEMDIAL). 
Johno Bryant (203). Constructional analysis. Master's 
thesis, University of California at Berkeley, 
Bruno Emond (197). Modeling natural language com-
prehension and anaphora resolution with ACT-R. In 
Procedings of the Fourth Anual ACT-R Workshop 
(p. 1-8). Pitsburgh, PA: Department of Psychology, 
Carnegie Melon University. 
Fauconier, G. (1985). Mental Spaces: Aspects of 
Meaning Construction in Natural Language. MIT 
Pres/Bradford, Cambridge, Mas. and London. 
Filmore, C. J. (1982). Frame Semantics. In L. S. 
of Korea, editor, Linguistic in the Morning Calm, 
pages 11-38. Hanshin, Seoul. 
Filmore, C. J. (198). The Mechanisms of Construction 
Gramar. Berkeley Linguistics Society, 14:0 35—5. 
Ana M. Fowles-Winkler & Laura Michaelis (205) An 
ACT-R model of sentence sorting with argument 
structure constuctions. In the Procedings of the Lin-
guistic Society of America Anual Meting, January 
7, 205, Oakland, CA. 
Kay, P. (202). An informal sketch of a formal architec-
ture for construction gramar. Gramars, 5:0 1—
19. 
Langacker, R. W. (1987). Foundations of Cognitive 
Gramar, volume 1. Stanford University Pres. 
Liskov, B. (198). Data abstraction and hierarchy. 
SIGPLAN Notices, 230 (5), 198. 
Newel, A. (190). Unified Theories of Cognition. Har-
vard University Pres, Cambridge, MA. 
Pitel, G. and Sansonet, J.-P. (203) Unified Represen-
tation of Typological, Absolute and Relational Predi-
cates. In Procedings of PACLING’03. Avail. on first 
author web page. 
Pitel, G. (204). MICO: la notion de construction située 
pour un modèle d’interprétation et de résolution de la 
réference pour le dialogue finalisé. PhD Thesis, Uni-
versité Paris XI. 
Reboul, A. (199). Reference, agrement, evolving ref-
erence and the theory of mental representation. In 
M. Coene, W. D. Mulder, P. Dendale, and 
Y. D'Hulst, Eds. Studia Linguisticae in honorem Lil-
ianae Tasmowski, pages 601—616. Unipres, Pa-
dova. 
Talmy, L. (198). Force dynamics in language and 
cognition. Cognitive Science, 12:0 49—10. 
