-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explain that both event_type and trial_type can be used #367
Comments
I would definitely welcome any content that talks about this. It may be worth putting things into context as well: this is a bit of an exaggeration maybe but users from fmri tend to code things in "trials" whereas EEG and MEG because of the higher temporal resolution and the possibility to add "triggers" in their data stream may code more things in events. I think that explaining both perspectives may be useful to make things more explicit. BTW: I may be on the side that the fMRI way of doing things is more wrong than the higher granularity of coding things into events (data reusability is lower when encoding just trials)... |
One of the difficulties with coding response time in a single trial row is that different paradigms encode response time relative to different anchor events (and it may not be the stimulus event). We have found cases of two related experiments from the same paradigm which reported it differently. Authors are sometimes not clear about what anchor they are using when calculating response times. Further for modalities such as EEG, presentations such as cues and instructions usually elicit responses, which are sometimes stronger than the actual stimulus presentation responses. If you are just analyzing a single dataset this all usually washes out. For cross-study analysis we have found it necessary to regress out the effects of these other presentations or the result is mush when the results from datasets are combined. Such regression is not possible if all of the presentations are not reported. |
In the BEP021 electrophysiology derivatives we have discussed how to describe annotations, and decided that it is not in scope for the specific BEP since the general standard for raw data already allows for sharing annotations in the events.tsv file, and the common derivatives specification already allows for documenting a process like "annotating" as
_desc-annotation_
as an entity in the data and events filename.For reference, this is discussed here https://docs.google.com/document/d/1PmcVs7vg7Th-cGC-UrX8rAhKUHIzOI-uIOh69_mvdlw/edit#heading=h.j3ffqf7um1ly
During a cleanup of the spec today we discussed that it would be good for the starter kit to contain some explanation that both
events
andtrials
are valid ways of thinking about and documenting the experiment, and henceevent_type
andtrial_type
can both be of value.For an experiment with a random number of events (for example multiple stimuli appearing prior to the subject giving a response) it makes sense to have many events (rows) in the events.tsv, with a limited number of columns each. In that case a stimulus would go on one line, and a response would go on another, distinguished by the
event_type
.For an experiment with a fixed number of events (like one stimulus, one response) it makes sense to code a single stimulus-response trial as a single "event" (row in the tsv file) with multiple columns, including the stimulus, whether the response was correct or not, and what the reaction time was. In this case the
trial_type
may be useful, for example to code whether it is a congruent/incongruent or standard/deviant trial.The text was updated successfully, but these errors were encountered: