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

[Dan Bothell]

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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: using-new-slots.lisp
Type: application/octet-stream
Size: 4627 bytes
Desc: not available
URL: <http://mailman.srv.cs.cmu.edu/pipermail/act-r-users/attachments/20090209/5edd8bb8/attachment.obj>