Discussion on subject states

[spieschnik]

In BIDS information about subject states are missing. Unless otherwise specified we assume that there is only one subject state.

The BIDS file inheritance makes us assume the following:

• Is there one task.json in the top-level folder, there is only one subject state. This one task can be executed several times but within one session.
• Are there two (or more) task.json in the top-level folder, there are two subject states. We assume these tasks were executed in two sessions.

[lzehl]

There is a safer assumption we can make from the BIDS folder hierarchy:

• Is there no session folder or only one session folder, we assume there is only one state to consider.
• Are there multiple session folders each session corresponds to one subject state.

I'm not sure if we can assume the task case you describe above. I would like to discuss this with the BIDS community first.

@dorahermes @robertoostenveld what do you think? To provide context: We are in the process of implementing an automated BIDS-To-openMINDS converter. A full conversion will for now be not possible because BIDS is lacking some standardization. We are currently trying to identify which assumptions we can make based on the BIDS specifications.

[dorahermes]

Can you clarify what is meant by state? For example, a subject can even fall asleep during one run.

A session is currently defined pretty freely as a 'A logical grouping of neuroimaging and behavioral data consistent across subjects'.

[lzehl]

@dorahermes "state" should be used to identify experiment relevant / affecting states of the subject. Your example could (should) qualify to identify a change in state during one run. (thanks for providing us with feedback here :smiley: )

However, how detailed states are captured is basically up to the researcher and should also be evaluated against what should be searchable through a database and what should be there as in-depth data annotation with the data, but does not necessarily have to searchable across datasets in a database. There would be of course the ideal world scenario that everything is searchable in a database but...

I don't really see though that BIDS is able to robustly cover the case of state change within a run except through events, and then only if these events were actually recorded. Subject metadata for longitudinal experiments are currently not well captured in BIDS (there seem to be several workarounds for this in the community).

In the end, for the BIDS-2-openMINDS converter we are currently just trying to identify the elements in BIDS we can automatically translate to openMINDS without human interference. However, there are many elements in BIDS which we cannot translate without human interaction. The elements for which we can identify a defined set of possible interpretations, we could at least semi-automate (where the user has to identify how he/she used BIDS). The once which are completely user dependent we need to skip and potentially provide as a list of "manual TODOs" for a user. I hope that there will not be that many for the latter.