# Events

## Overview

Events in XCEDE are merely time intervals annotated with arbitrary metadata. This component can be used to represent several types of behavioral data, statistics calculated on time series data, or any other metadata whose proper interpretation requires that it be associated with a particular interval in time.

An XCEDE event consists of the following:

onset

  The onset (in seconds) of the time interval.

duration

  The duration (in seconds) of the time interval.

type

  Usage of this field is user-specified

name

  Usage of this field is user-specified

units

  The units of the onset and duration fields. This field is optional, and it is recommended that users of the schema prescribe an implicit unit of measurement and use it consistently. In that case, this field may be considered informational only.

values

  A value adds named metadata to this event.

The following instance shows how each of these fields may be populated.

Event elements are stored within the `<data>` element of an `<acquisition>`. The `<data>` element should be of type events_t (using `xsi:type` — see examples below).

All onsets are relative to an arbitrary time reference. Typically, time 0 (zero) could mean the start of data acquisition. An event list may be interpreted as concurrent with data in other `<acquisition>` elements (which could be other event lists). If so, the same time reference should be used in all concurrent acquisition data.

There is no ordering constraint on events in a list. Applications should depend on using the `<onset>` elements to order the events chronologically if they so desire.

An optional `<params>` element may precede the first event in a list, and this element stores arbitrary metadata (using the same `<value>` element used above) that apply to all events in the list.

## Examples

An event timeline

Consider the timeline shown in , representing stimuli and responses in a neuroimaging study. We show in how the first 5 seconds' worth of the events might be represented in XCEDE.

XCEDE Events example - stimulus/response data

Each stimulus and each response are stored as separate event elements. Note that all the visual events appear first in the XCEDE file, then the audio events, and then the response event. This ordering is arbitrary, and the events could easily have been presented in chronological (or random!) order. The semantic interpretation of the events within an event list must not depend on their document order.

Stimulus and response data are not the only appropriate content to represent in XCEDE events. shows how quality assurance (QA) statistics for each volume/timepoint in an fMRI scan can be stored as events. Note that the time reference for the onsets is arbitrary, but if the `acquisition` containing the event data is contained within the same `episode` as other time-locked data, it should be assumed that the time reference is the same for all `acquisitions` within the `episode`, unless otherwise explicitly specified. So, for example, this QA data might be associated with MR image data in the same `episode`, and time 0 (zero) would by default be assumed to have the same meaning in both sets of data.

XCEDE Events example - QA data