Make use of AssociatedEmptyRoom field in *_meg.json

[hoechenberger]

I don't know how I could have missed this all this time, but the *_meg.json sidecar files support a field AssociatedEmptyRoom:

RECOMMENDED. Relative path in BIDS folder structure to empty-room file associated with the subject’s MEG recording. The path needs to use forward slashes instead of backward slashes (e.g. sub-emptyroom/ses-/meg/sub-emptyroom_ses-_task-noise_run-_meg.ds).

I think we should make use of this.

By default, write_raw_bids() should try to retrieve the matching empty-room recording via mne_bids.get_matched_empty_room() (which would imply that empty-room data need to be added to the BIDS folder first, before adding participants' recordings).

To explicitly specify an empty-room recording, write_raw_bids should gain a kwarg emptyroom_session=None, which would accept a string with the name of the associated empty-room session. This can then be used by write_raw_bids() to construct the relative path to the requested empty-room recording file.

In both cases (default behavior where we infer the empty-room recording, and in cases where users explicitly request an empty-room recording), write_raw_bids() would add the correct AssociatedEmptyRoom to the JSON sidecar file.

Only question that remains is what to do in cases where empty-room recordings are missing / how to design the API such that this case would be covered too.

get_matched_emptyroom() would be updated to first check if there's an AssociatedEmptyRoom entry in the sidecar; and only if not, it would actually start looking at the file names in the dataset.

Would like to hear your thoughts on that!

[jasmainak]

can you check if any datasets actually use this field? I think it's a fairly new field but I'm not sure

[hoechenberger]

can you check if any datasets actually use this field?

I could, but is that relevant? :) Just suggesting to add it for writing, and respect it when reading, if it's present at all

[jasmainak]

I could, but is that relevant? :)

It will help you understand how to write the code. For example, looking here tells me that it's not always in a sidecar associated with a file. It's always good to ground oneself in reality ;-)

[hoechenberger]

Sorry, I cannot follow you… the file you linked to has an entry:

 "AssociatedEmptyRoom": "sub-emptyroom/ses-20090409/meg/sub-emptyroom_ses-20090409_task-noise_meg.fif.gz"

and this file, in fact, does exist in the dataset. 🧐

[jasmainak]

but which raw file is it for?

[hoechenberger]

Ooooh now I see what you mean! I didn't even know this was allowed in BIDS …

[jasmainak]

welcome to BIDS inheritance principle :)

the specification is too complex sometimes.

[hoechenberger]

Still: when writing, we could write this attribute -- we'll be in full control of where to put it.

Reading -- needs to be discussed.

[hoechenberger]

the specification is too complex sometimes.

sometimes .... *cough, cough*
😭🙈

[jasmainak]

hahaha.

I believe for ephys, mne-bids is the most comprehensive option out there :) I agree we could have an option for writing. Go for it if you like. For reading, we don't deal with the inheritance principle currently, so I think that can be safely ignored.

[sappelhoff]

welcome to BIDS inheritance principle :)

place to complain/discuss about this --> bids-standard/bids-2-devel#36

I see two problems with the inheritance principle:

1. it's not very rigidly defined, see: Inheritance principle: clarify the procedure of which files would be considered bids-standard/bids-specification#102
2. the validator does not have sufficient coverage to check that the principle is reasonably used (and warn or error otherwise)

[hoechenberger]

I see two problems with the inheritance principle:

My main concern is that there is no central authority one can query when looking at a subject's individual data. I feel that ideally, either everything would be specified in the BIDS root – or on the same level as participants' data files. And not split across different levels, including inheritance… Ugh, what a standard…

[jasmainak]

My main concern is that there is no central authority one can query when looking at a subject's individual data.

higher levels of hierarchy do take precedence ...

Ugh, what a standard…

can you please complain on the bids-specification github and/or forums? :-P Sometimes I feel I'm the only one shouting ;-)