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.

Sign up for GitHub

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

[MISC] Restructure MEG empty room example texts #1677

Merged
merged 6 commits into from
Feb 5, 2024
Merged

[MISC] Restructure MEG empty room example texts #1677

Changes from 3 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
c22f348
Update magnetoencephalography.md
guiomar Jan 8, 2024
bc7920a
Update magnetoencephalography.md
guiomar Jan 8, 2024
e947ab1
Update magnetoencephalography.md
guiomar Jan 8, 2024
bd1ed2b
Apply suggestions from code review
sappelhoff Jan 9, 2024
0f3d0a4
pull example descriptions under example subheadings
sappelhoff Jan 12, 2024
441fa10
Merge branch 'master' into guiomar-patch-1
sappelhoff Feb 5, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions src/modality-specific-files/magnetoencephalography.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -509,13 +509,13 @@ It is RECOMMENDED to explicitly specify which empty-room recording should be use
Empty-room recordings may be collected once per day, where a single empty-room recording may be shared between multiple subjects and/or sessions (see [Example 1](#example-1)).
Empty-room recordings can also be collected for each individual experimental session (see [Example 2](#example-2)).

In the case of empty-room recordings being associated with multiple subjects and/or sessions, it is RECOMMENDED to store the empty-room recording inside a subject directory named `sub-emptyroom`.
In the case of empty-room recordings being associated with multiple subjects and/or sessions (see [Example 1](#example-1)), it is RECOMMENDED to store the empty-room recording inside a subject directory named `sub-emptyroom`.
sappelhoff marked this conversation as resolved.
Show resolved Hide resolved
If a [`session-<label>`](../appendices/entities.md#ses) entity is present, its label SHOULD be the date of the empty-room recording in the format `YYYYMMDD`, that is `ses-YYYYMMDD`.
The `scans.tsv` file containing the date and time of the acquisition SHOULD also be included.
The rationale is that this naming scheme will allow users to easily retrieve the empty-room recording that best matches a particular experimental session, based on date and time of the recording.
It should be possible to query empty-room recordings just like usual subject recordings, hence all metadata sidecar files (such as the `channels.tsv`) file SHOULD be present as well.

In the case of empty-room recordings being collected for the individual experimental session, it is recommended to store the empty-room recording along with that subject and session.
In the case of empty-room recordings being collected for the individual experimental session (see [Example 2](#example-2)), it is RECOMMENDED to store the empty-room recording along with that subject and session.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These additions feel redundant with L509/L510:

image

If keeping the examples close to the more detailed descriptions makes more sense, maybe we should remove these links from L509/L510 and reword that to be a bit smoother without the examples?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am impartial as to whether that makes more sense, but I agree that we should not introduce redundancy here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got a couple of questions here, so I decided to reinforce the links to the examples. But maybe not that necessary.
What about instead of using "(see Example 1)" as in lines L509/L510, say just "(Example 1)". People often read fast, and a bit of redundancy sometimescan may help.

sappelhoff marked this conversation as resolved.
Show resolved Hide resolved

In either case, the label for the [`task-<label>`](../appendices/entities.md#task) entity in the empty-room recording SHOULD be set to `noise`.

Expand Down Expand Up @@ -546,7 +546,7 @@ A guide for using macros can be found at

### Example 2

One recording per session, stored within the session directory.
One empty-room recording per each participant's session, stored within the session directory.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in BIDS, a session is always "per participant" (that is, you would not have two participants listed in the same session directory)

Suggested change
One empty-room recording per each participant's session, stored within the session directory.
One empty-room recording per session, stored within the session directory.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was to clarify that in the other example (1) you can store under one session the noise recording to be used for multiple participants, but it's true it is redundant. How to store the emptyroom recordings is the thing I typically get the more questions about, as it is very MEG specific not applicable to other modalities, that's why I might have been over redundant in many places :)

Suggested change
One empty-room recording per each participant's session, stored within the session directory.
One empty-room recording per session, stored within the participant's session directory.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, let me try to push a commit and we can see whether you think that's an acceptable improvement.


<!-- This block generates a file tree.
A guide for using macros can be found at
Expand Down