As @Remi-Gau hinted by #695 , we still lack total clarity on original stimuli storage and annotation.
We do have
stimuli/ folder which, like sourcedata/ is nohow "prescribed" for a specific structure.
stim_file column in _events.tsv as to point to a (unregulated) location under stimuli/ and then populating that stim_file description/HED tags within _events.json (bless the inheritance principle).
- "human wording" to point to the origin of a stimuli within
_events.json as possibly coming from some DB
_stim.tsv.gz files for "signals related to the stimulus" (but not necessarily stimulus)
In respect to the first 3 items, and in conjunction with
- stimuli collections/datasets should be self-sufficient/described
- incoming requests to store stimuli datasets on DANDI archive
I wondered if there either an ongoing effort to standardize "stimuli datasets" so
- they could be readily reusable across studies by simply placing them under
stimuli/<name> and avoiding necessity to describe stimuli in _events.json since information could be picked from their standardized layout
- derivatives of them could be created and possibly shared along (e.g. all the feature extractions done by pliers (thanks to @tyarkoni , @qmac, et al)
With that in mind I am even thinking such datasets could follow BIDS mantra and just get "participant/subject" and sub- renamed to "stimulus"/stim-, and preserve README.md, dataset_description.json, stimuli.tsv etc
Worth a BEP/effort or may be it is already a "solved problem"? ;) WDYT?
Related:
As @Remi-Gau hinted by #695 , we still lack total clarity on original stimuli storage and annotation.
We do have
stimuli/folder which, likesourcedata/is nohow "prescribed" for a specific structure.stim_filecolumn in_events.tsvas to point to a (unregulated) location understimuli/and then populating thatstim_filedescription/HED tags within_events.json(bless the inheritance principle)._events.jsonas possibly coming from some DB_stim.tsv.gzfiles for "signals related to the stimulus" (but not necessarily stimulus)In respect to the first 3 items, and in conjunction with
I wondered if there either an ongoing effort to standardize "stimuli datasets" so
stimuli/<name>and avoiding necessity to describe stimuli in_events.jsonsince information could be picked from their standardized layoutWith that in mind I am even thinking such datasets could follow BIDS mantra and just get "participant/subject" and
sub-renamed to "stimulus"/stim-, and preserveREADME.md,dataset_description.json,stimuli.tsvetcWorth a BEP/effort or may be it is already a "solved problem"? ;) WDYT?
Related:
_stim.{mp3.mp4,...}along side with neural data. sidecar fields in that file could come handy why instrumenting specification of stimuli as presented from the shared across subjectssourcedata/(e.g.StartTime, possiblyTimeDriftbetween scanner and stimuli delivery for lengthy (an hour) presentation, etc)