[ENH] BEP044 - Stim-BIDS#2022
Conversation
Implement the standardization of stimulus files and their annotations within the BIDS specifications.
* **Add new file `src/modality-specific-files/stimuli.md`**
- Describe the specifications for the stimuli directory.
- Include guidelines for storing stimulus files and their annotations.
- Define what goes into `stimuli.tsv/json`, `annotations.tsv/json`, and `stim-<label>.json`.
- Use the same style as other modality-specific docs to design the tables, variables, and examples.
* **Modify `src/modality-specific-files/task-events.md`**
- Add a section detailing the standardization of stimulus files and their annotations within the BIDS specifications.
- Include examples of how to use the `stim_file` and `stim_id` columns in `events.tsv` files.
- Provide guidelines for storing stimulus files in the `/stimuli` directory.
- Expand the definition of the `stim_file` column to include `stim_id`.
* **Modify `src/schema/objects/columns.yaml`**
- Update the definition of the `stim_file` column to ensure consistency in stimulus file references.
- Add the `stim_id` column definition for `events.tsv` files.
* **Modify `src/schema/rules/checks/events.yaml`**
- Add a check for missing stimulus files declared in `events.tsv`.
- Add a check for missing `stim_id` references in `events.tsv`.
* **Modify `src/schema/rules/sidecars/events.yaml`**
- Specify the `StimulusPresentation` metadata field for `events.tsv` files.
- Include the `stim_id` column in the metadata field specifications.
* **Modify `src/schema/objects/entities.yaml`**
- Add entities described in the document with proper requirement levels and descriptions.
* **Modify `src/schema/objects/suffixes.yaml`**
- Add suffixes for `{audio, image, video, audiovideo}`.
- Include the file extensions and descriptions for each suffix.
* **Add new file `src/schema/rules/sidecars/stimulus.yaml`**
- Define sidecar tables for `stimuli.tsv/json`, `annotations.tsv/json`, and `stim-<label>.json`.
- Use the same style as other modality-specific docs to design the tables.
---
For more details, open the [Copilot Workspace session](https://copilot-workspace.githubnext.com/neuromechanist/bids-specification?shareId=XXXX-XXXX-XXXX-XXXX).
Add stimuli specifications to BIDS
for more information, see https://pre-commit.ci
|
will do a bit of clean up to get less red in CI and maybe see if we can get the HTML version of the BEP to render |
yarikoptic
left a comment
There was a problem hiding this comment.
initial quick pass with little recommendations etc
The test was failing because it tried to access datatypes attribute on all rules, including the new stimuli rules that use path-based organization instead.
… stimuli tables - Add explicit schema path loading to make_sidecar_table to avoid caching issues - Temporarily comment out stimuli.Stimuli tables that need namespace fixes - File tree generation from schema is now working for /stimuli directory
- Fix entity format labels in root template macro (use <label> instead of hardcoded) - Add explicit schema loading to make_columns_table to avoid caching issues - Re-enable all stimuli tables (sidecar and columns) that now work correctly - File tree now properly shows stim-<label>[_part-<label>] format
…macro Add generic root-level template macro for non-datatype directories
- Show .<extension> when more than 2 extensions exist for same suffix - Keep stem files (stimuli.tsv, annotations.tsv) explicit for clarity - Keep events files explicit (only 2 extensions) - Consolidate audio/image/video/audiovideo files (5-6 extensions each)
The <extension> placeholder was being interpreted as an HTML tag and hidden. Now using <extension> for HTML output while keeping <extension> for PDF.
|
Update prior to making PR out of Draft:
|
| "raw", | ||
| path="stimuli") | ||
| }} | ||
|
|
|
|
||
| ### Using `stim_file` | ||
|
|
||
| Reference stimulus files directly using the `stim_file` column, where values represent the relative path to the stimulus file within the `/stimuli` directory: |
There was a problem hiding this comment.
@neuromechanist I do not want to derail this BEP, but it might as well be included here (or later).
I would like your feedback on our
use case, where we will have a distinct video record for every MRI data file in the dataset (thus per subject/[session/]). I envisioned placing them nearby the data files:
and that is reflective somehow of @bendichter 's
where it is a audiovideo record of behavior, instead of audiovideo record of stimuli.
One logical way could be to allow for stimuli/sub-<label>/[ses-<label>/]... hierarchy but that feels suboptimal since if unique per sub/ses -- better just go nearby the data.
I would say, we (with @vmdocua) would just add stim- entity to the file, associated with the data file, so e.g. for every _events.tsv level file it would produce the one with extra _stim-reprostim_audiovideo.{mkv,json} .
So in the long run, I would need to advocate allowing for such files in the hierarchy, and that will use stim entity then, with stimuli.tsv on top level providing description for what that reprostim means.
|
Very nice @yarikoptic. Indeed recording the stimulus/subject individual presentations could unlock accounting for even more variabilities throughout the session.
Hopefully we should not overuse
But, in the case that only the presented stimuli is recorded, like presenting randomized NSD data, capturing the video feed and sharing the presented video per participant (to make sure that event times are correct captured?): I hope that I could convey this not super twisted. LMK. Either way, both should not have a bearing on BEP044. One of the reasons not to push BEP044 out now is to make sure that the use-cases are mature enough and that tools can sufficiently use it. Hence, working on https://github.com/Annotation-Garden/HEDit. So, please bring on more use cases :D. |
|
re synergy with #2231 (to be BEP047) |
I kinda liked it but it made me pause: if I to take that subject specific stimuli and place it following this BEP under top level If it was |

This PR addresses #153 by introducing specifications for handling and standardizing stimulus files and their annotations within the BIDS specifications. The changes focus on improving the organization, referencing, and metadata of stimulus files to enhance consistency, reusability, and efficiency.
Important
HTML render of the stimuli page : https://bids-specification--2022.org.readthedocs.build/en/2022/modality-agnostic-files/stimuli.html
Note
The issue: #153
Google Doc
Example PR: bids-standard/bids-examples#433
Known issues:
/src/schema/rules/files/rawrequiredatatype. Stimuli might be a special data type that can only be present at the root of the dataset. So, the datatype field is missing for now.cc: @bids-standard/bep044 and @monique2208