The Control of Event-File Management

Abstract

According to the Theory of Event Coding, both perceived and self-produced events are coded by binding codes of the features of these events into event files. Here I argue that distinguishing between the actual binding process and the retrieval of event files is empirically difficult but theoretically important. As a first step towards disentangling these processes, I provide a brief overview of what the available evidence tells us with respect to the control of the binding process and the control of the retrieval process. I argue that there is not much evidence for selectivity of the binding process: Various kinds of stimuli and actions seem to be spontaneously integrated under various conditions, and there is increasing evidence that emotions, task instructions, and task context are coded into event files as well. On the other hand, there is increasing evidence for a high degree of selectivity of the retrieval process, suggesting that most if not all observations of effective impact on event files reflect an impact on retrieval, but not binding proper. I conclude by pointing out open questions and issues.

Keywords: Action; Action and perception; Event cognition.

Figure 1

A. Basic components of the original event-file design introduced by Hommel (1998). Participants carry out two responses in each trial. A cue informs them whether the first response consists in pressing a left or a right key. They are to prepare the cued response but wait for the first stimulus (S1) to carry it out. Note that the features of S1 are entirely unrelated to the identity of R1, S1 merely functions as a go-signal. About a second or so later, the second stimulus (S2) appears. One feature of S2 signals the identity of R2, in this case the shape (the mapping in this example is X: right keypress; O: left keypress). B. The theoretical assumption of event-file theory. Presentation of S1 leads to the coding of the features of this stimulus, the shape “X” and the vertical “top” location in this example, and of the features of the corresponding response, “right” in this example. These three features, in addition to possible other (e.g., contextual or affective) features, are integrated into one event file, indicated in green. As soon S2 appears and R2 is selected and programmed, the corresponding features of S2 (“O” and “top”) and R2 (“left”) will be integrated the same way as those of S1 and R1, indicated in red. More importantly, however, is the fact that the combinations of S1/R1 and S2/R2 overlap with respect to the feature “top”. Even though this feature is actually irrelevant in this task, it will tend to retrieve event files that include the same feature, such as the one including the S1/R1 features (shown in green). This in turn will activate the included codes, which leads to a confusion regarding the shape and the response. Resolving this conflict takes time, which leads to worse performance in all conditions in which feature overlap between S1/R1 and S2/R2 exists but is incomplete—the so-called partial-repetition costs. Conditions with no overlap do not lead to this kind of retrieval and conditions with complete overlap do not lead to feature conflict. Note that this figure is very selective: processing S1/R1 and S2/R2 will also lead to the retrieval of feature-overlapping event files from previous trials. This is assumed to create further noise and code conflict, but given that appropriate research designs make sure that all feature combinations are balanced across trials, these kinds of conflict should not create a systematic bias of the outcomes.