Skip to content
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

Replace _scans.tsv with _recordings.tsv #29

Open
tsalo opened this issue Aug 3, 2020 · 7 comments
Open

Replace _scans.tsv with _recordings.tsv #29

tsalo opened this issue Aug 3, 2020 · 7 comments
Labels
suffixes Changes to suffixes.

Comments

@tsalo
Copy link
Member

tsalo commented Aug 3, 2020

Right now the _scans.tsv file keeps track of which acquisitions exist within a particular session. The word “scans” is a little domain-specific, especially as people begin to write BIDS formats for things like electrophysiology. Why not call this recordings, as this is more domain-general and still reflects the same overall idea?

Original authors: Unknown

@tsalo
Copy link
Member Author

tsalo commented Aug 3, 2020

@jgrethe wrote:

Or perhaps _data.tsv which would be more domain agnostic

@robertoostenveld
Copy link

For me it is also not clear what precisely should go in the _scans.tsv file, i.e., what qualifies as data (or acquisitions) and what not.

In case of task-fMRI with events, a single line (with the bold.nii) would be added.
In case of behavior only (no scanner involved), would the 'events.tsv` be added?

In case of EEG with recorded/digitized electrode positions, the eeg.vhdr file would be added but not the electrode positions ( I guess).
But if only electrode positions are recorded and no EEG, as in this study and this corresponding data, would the electrodes.tsv be added?

@tsalo tsalo added the suffixes Changes to suffixes. label Aug 3, 2020
@jbteves
Copy link

jbteves commented Aug 4, 2020

I would propose "acquisitions" though I will also advocate for #27, which would render this issue irrelevant.

@tsalo
Copy link
Member Author

tsalo commented Aug 5, 2020

In Common Principles, acquisition refers to "a continuous uninterrupted block of time during which a brain scanning instrument was acquiring data according to particular scanning sequence/protocol." I actually think adopting "acquisitions" for the tsv file would be a great idea, @jbteves, independent of #27.

Here's my reasoning:

  1. scans is currently confusing, as @robertoostenveld says. Acquisitions, on the other hand, are quite concrete. There may be edge cases, but generally speaking we know what an acquisition refers to.
  2. In addition to different simultaneously acquired data types (e.g., fMRI + events), we have several entities that generally separate files from the same acquisition (e.g., echo). If, however, we have our (optional) tsv file dedicated to acquisitions, then we can pop out all of those pesky entities and get one acquisition time that applied to the whole file group, along with any other acquisition-specific information.
  3. We could even perhaps include a column to provide acquisitions with identifiers, which could tie into Add concept of a "grouped scan collection" to common principles bids-specification#529. Basically, the "grouped scan collections" (scans from separate acquisitions that are parametrically linked and must be analyzed together) could be defined with this new "group_identifier" column in the "acquisitions" tsv.

@yarikoptic
Copy link
Contributor

There is a need also very similar to

so there _recordings is good,

With @neuromechanist we are working out stimuli/ formalization they have. With stimuli we have a need to align the stimuli whenever it is a video/audio covering entire run. But it is not collected data, and might not even be in that folder but rather just referenced from under stimuli/. But the point is that it also would relate to temporal alignment of various files pertinent to the experiment. If we decide somehow for it to be reflected in this file, then `_recordings.

@tsalo
Copy link
Member Author

tsalo commented Apr 12, 2024

Recently, we started using descriptions.tsv to define values in desc entities in a dataset, and I have proposed extending that to other entities, including recording and acq (see bids-standard/bids-specification#1706). I think the proposals in this issue would conflict with that.

@yarikoptic
Copy link
Contributor

Good point, and 👍 on such generalization. Let's think alternative name

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suffixes Changes to suffixes.
Projects
Status: No status
Development

No branches or pull requests

4 participants