<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="Street"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="PostalCode"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="State"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="address"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Arial;
color:windowtext;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>ACT-R 6 currently provides a
capability to add slots to an existing chunk using P* productions. However, it
does not provide a capability to change the type of the chunk to which the slot
is added in the process. This is problematic in that new slots added to an
existing chunk cannot be referred to in subsequent productions, since the chunk
type is inconsistent with the existence of the new slots. <o:p></o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>To see where this causes
problems in a model of language processing, consider the case of verbs like
"sneeze" which typically occur in sentences like "she
sneezed" where they project intransitive verb constructions. Such verbs
occasionally occur in larger "caused-motion" constructions as in
"she sneezed the napkin off the table" (this is an important area of
research in Construction Grammar). If the processing of the verb
"sneezed" leads to projection of an intransitive verb construction,
then when "the napkin" and "off the table" are processed,
there will be no slots in the intransitive verb construction into which these
constituents can be integrated. Using P* productions, slots can be created for
integrating "the napkin" and "off the table" into the
intransitive verb construction. However, in subsequent processing, these new
slots cannot be referenced since they aren't part of the chunk type definition
for intransitive verb construction chunks. Currently, the only way I know of to
handle this in ACT-R 6 is to create a new chunk type "caused-motion"
which contains the extra slots when "the napkin" and "off the
table" are processed, and then copy all the slot values from the
intransitive verb construction to the new caused-motion construction in
addition to integrating "the napkin" and "off the table"
into the new chunk. It would be computationally simpler to just add the slots
to the intransitive verb construction and change the chunk type to reflect the
additions, i.e. to caused-motion in this example. Besides being computationally
simpler, there are other reasons for preferring this approach. If the
intransitive verb construction is integrated into a larger linguistic unit,
then when the new caused-motion construction is created, all references to the
intransitive verb construction must be tracked down and replaced. For example,
in "she sat down and then she sneezed the napkin off the table" if
the intransitive verb construction projected by "sneezed" is
integrated as an argument of the conjunction "and then" prior to the
processing of "the napkin" and "off the table" (as in the
current model), then it will be necessary to replace the reference to the
intransitive verb construction with the reference to the caused-motion
construction. In general, this may require significant processing effort.<o:p></o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>Although important in
Construction Grammar, the use of an intransitive verb like "sneezed"
in the caused-motion construction is fairly uncommon. However, the need for a
capability to dynamically add slots to and adjust the chunk type of a chunk is
actually quite pervasive in language processing. Consider for example,
ditransitive verbs like "give". There are two distinct ways in which
ditransitive verbs are used, with an indirect object as in "he gave me the
book" and with a prepositional phrase argument as in "he gave the
book to me". At the time the verb is processed, which form will actually
occur is undetermined. Currently in our language model, a verb like
"gave" projects a ditransitive construction which contains slots for
both an indirect object and the "to" prepositional phrase. This
allows the model to handle both forms without having to create new chunks on
the fly for each case. With an ability to dynamically modify chunk types after
adding needed slots, the model could project the more likely chunk type given
the context and frequency of use (i.e. either indirect object or "to"
prepositional phrase") and still handle the alternative form when it
occurs, rather than having to provide slots for both possibilities in a single
construction. To support subsequent processing, we would like the chunk type to
accurately reflect the chunk. To the degree that this is not the case, problems
are likely to result. <o:p></o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>Verb-particle compounds
which are ubiquitous in English, provide another example of the need for this
capability. If the input is "he looked...", what construction should
the verb "looked" project? According to Longman's dictionary, the most
common use of "look" is in combination with "at" as in
"he looked at the book", but "look" also occurs in
combination with an adjective as in "he looked happy" and with a
range of different particles as in "look up", "look over",
"look for" where the meaning of the expression depends on the
combination of "look" and the preposition--indicating storage of
these verb-particle combinations as a unit in the mental lexicon. Besides
needing to store verb-particle combinations to determine meaning, the argument
expectations vary with each combination. Thus, we can say "he looked
up" or "he looked it up" or "he looked the name up" or
“he looked up the name” (and in spoken language “look it!”
is becoming more and more common) but not "he looked it at" or
"he looked the book at". To handle all these possibilities, some kind
of accommodation mechanism is needed which does not involve backtracking and is
unlikely to be a repair mechanism--given the ease with which humans process
such variability. At the processing of the verb "looked" the model
should project the construction which is the best candidate given the current
context and prior history of use, but the model must be prepared to accommodate
the subsequent input. Humans appear to be very good at handling this kind of
variability, typically being unaware that there are multiple possibilities at
each choice point. The ability to add slots to existing chunks using P*
productions, combined with a capability to dynamically adjust the chunk type of
the resulting chunk appears to provide just the needed capability. The
alternative of having to project new chunk types and copy over slot values and
adjust preceding references requires more computation than is likely to be
consistent with human language processing of such inputs.<o:p></o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>More generally, such a
mechanism would give ACT-R a functionally motivated capability to create new
chunk types, providing a learning mechanism that appears to be needed to
support the learning of new construction types during language acquisition. If
children do not come with a full construction ontology built in, then some
mechanism for extending previously learned constructions to novel constructions
is needed. Allowing for the addition of slots to existing chunks, combined with
a capability to modify the chunk type--when the linguistic input warrants it--perhaps
creating a new chunk type in the process, would provide just such a mechanism.<o:p></o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>Jerry<o:p></o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>Jerry T. Ball<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>Senior Research Psychologist<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>Human Effectiveness Directorate<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>711th Human Performance Wing<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>US Air Force Research Laboratory<o:p></o:p></span></font></p>
<p class=MsoPlainText><st1:address w:st="on"><st1:Street w:st="on"><font
size=2 face="Courier New"><span style='font-size:10.0pt'>6030 South Kent
Street</span></font></st1:Street>, <st1:City w:st="on">Mesa</st1:City>, <st1:State
w:st="on">AZ</st1:State> <st1:PostalCode w:st="on">85212</st1:PostalCode></st1:address><o:p></o:p></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>PH: 480-988-6561 ext 678; DSN: 474-6678<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>Jerry.Ball@mesa.afmc.af.mil<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>www.DoubleRTheory.com<o:p></o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'> <o:p></o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
</div>
</body>
</html>