[ACT-R-users] Need capability to change chunk type when new slots are added to an existing chunk

Mon Feb 9 17:53:17 EST 2009

I had heard rumors that there was a way to access the new slots in a
subsequent production. Thanks for the sample code! One question -- your
second example using production compilation leads to creation of a
regular production (not P*) called PRODUCTION1 that references the
"new-slot" of the "content" chunk in the imaginal buffer. Since this is
not a P* production and the "new-slot" slot name is not passed in as a
variable via the goal chunk as in the first example, it doesn't seem
like this production should work. Am I missing something?

With respect to creating new chunk types, it is true that a mechanism
for creating productions capable of processing the new chunk types would
also be needed. Our primary use would be to specialize a chunk into a
pre-defined chunk subtype consistent with the added slot(s).  

With respect to having "extra" slots, there are a couple of reasons for
not wanting to have "extra" slots in chunks to handle all the possible
construction forms: 1) these "extra" slots can interfere with subsequent
processing by matching to productions when they shouldn't (i.e. we'd
like the "extra" slots to be restricted to appropriate chunk subtypes),
and 2) in general, it is not possible to handle all the possible
construction alternatives in a single construction, nor is it desirable.
For example, the verb "give" also comes in verb-particle constructions
like "give up", "give in" and "give out" in addition to the normal
ditransitive forms. Trying to create very general chunk types with lots
of slots to handle all the possibilities would dilute the constructions
in inappropriate ways. For example, having slots for arguments like "the
napkin" and "off the table" in the case of constructions for
intransitive verbs like "sneeze" in order to handle the special (an
infrequent) caused-motion use, would effectively eliminate the concept
of an intransitive verb. And if modifier (or adjunct) slots as well as
arguments slots are included in construction chunks, then the number of
such slots in undetermined (e.g. "he hiked up the hill, over the top,
down the back, thru the woods..."). In fact, in the case of modifiers,
we may want to add slots to a construction chunk without (essentially)
changing the chunk type.  

The model currently makes extensive use of chunk types organized into a
chunk type hierarchy. In general, the more specific the chunk type in a
buffer that matches a production, the higher the utility of the
production. It is to take advantage of this capability that we would
like to have specialized chunk types. If a new slot is added to an
existing chunk (based on the input) and the type of that chunk is
specialized to a more specific (pre-defined) chunk type as a result,
then productions matching the specialization can fire and are likely to
lead to better representations. 

Jerry

-----Original Message-----
From: Dan Bothell [mailto:db30 at andrew.cmu.edu] 
Sent: Monday, February 09, 2009 11:29 AM
To: act-r-users at act-r.psy.cmu.edu
Cc: Ball, Jerry T Civ USAF AFMC 711 HPW/RHAC
Subject: Re: [ACT-R-users] Need capability to change chunk type when new
slots are added to an existing chunk

I'm not sure I entirely follow what you are proposing.  It is in fact
possible to access slots which have been added to a chunk via a p*
through
other productions.  The key to doing so is that either those slots must
be
accessed via the abstractions in a p* or the production must be created
after the slot has been added to the chunk-type.

Attached is a simple example showing both situations - a production 
accessing a
newly created slot of a chunk in a test through p* and a production
which 
gets
learned via production compilation specifically referring to a newly 
created slot.
It's not an elegant model, but it does show that new slots can be
accessed 
and
directly incorporated into productions.

What I'm not quite getting is why you need to be able to access those
slots in productions which you're writing.  If you know what those extra
slots are to write them into a production why can't you just put them
into
the chunk-type definition up front?

There is essentially no penalty for a chunk having "extra" slots which
are
empty and it is possible for chunk-types to be structured in a hierarchy
so that you can have general as well as specific productions handling 
things.

The question I have is how does changing the chunk-type actually solve
the issue?  How could you write productions which referenced the new 
chunk-type
unless you also knew its name and in fact all of its slots in advance,
and 
if
you know that, why do you need p* to create the slots?

I'm not saying that I oppose such a mechanism, but I'm just not sure
what
exactly it solves and how exactly it's intended to operate.

Perhaps your proposed mechanism could be a topic for discussion at the
workshop before Cognitive Science.

Dan

--On Monday, February 09, 2009 11:33 AM -0500 "Ball, Jerry T Civ USAF
AFMC 
711 HPW/RHAC" <Jerry.Ball at mesa.afmc.af.mil> wrote:

>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> Jerry
>
>
>
> Jerry T. Ball
>
> Senior Research Psychologist
>
> Human Effectiveness Directorate
>
> 711th Human Performance Wing
>
> US Air Force Research Laboratory
>
> 6030 South Kent Street, Mesa, AZ 85212
>
> PH: 480-988-6561 ext 678; DSN: 474-6678
>
> Jerry.Ball at mesa.afmc.af.mil
>
> www.DoubleRTheory.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>