[MISC] Restructure MEG empty room example texts #1677
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1677 +/- ##
=========================================
Coverage ? 87.97%
=========================================
Files ? 16
Lines ? 1356
Branches ? 0
=========================================
Hits ? 1193
Misses ? 163
Partials ? 0 ☔ View full report in Codecov by Sentry. |
effigies
changed the title
| 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`. | ||
| 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. |
There was a problem hiding this comment.
These additions feel redundant with L509/L510:
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?
There was a problem hiding this comment.
I am impartial as to whether that makes more sense, but I agree that we should not introduce redundancy here.
There was a problem hiding this comment.
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.
Co-authored-by: Julia Guiomar Niso Galán <[email protected]>
| @@ -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. | |||
There was a problem hiding this comment.
in BIDS, a session is always "per participant" (that is, you would not have two participants listed in the same session directory)
| 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. |
There was a problem hiding this comment.
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 :)
| 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. |
There was a problem hiding this comment.
okay, let me try to push a commit and we can see whether you think that's an acceptable improvement.
|
This is fine. I'm not 100% in favor of including spec language likes SHOULDs and MUSTs in examples, but it doesn't change the meaning of the spec, so if this helps people find the information they need, fine. |
sappelhoff
changed the title
sappelhoff
changed the title
Edit: Removed boilerplate.