Provide clarification on current ambiguity in data_type folder names (`beh/` and `func/` in particular) and allocation of files to them

[yarikoptic]

Here are the issues relating to potentially changing the folder organization within BIDS, I think it is better to discuss it among those

IMHO, this is a problem of today. It'd be great that BIDS 2.0 had an elegant/more consistent response. However, BIDS needs to address this for future BEPs (cc/ @ericearl)

Originally posted by @oesteban in #2231 (comment)

Also @satra in earlier comment:

i think some clarity how the organizational principles are different in behavior versus others would be good to add. the last part of your proposed sentence doesn't match up with what i wrote about func above. bids clearly says modality specific files in its documentation.

We should address it with clarification in the current bids-specification and potentially BEP Guidelines to avoid derailing discussions in BEPs.

[oesteban]

I believe this is very much related to the principle of atomic changes you made me aware of some days ago.

IMHO, new data_type/ folders should be considered "molecular" (i.e., not atomic) and new _suffix could be considered atomic. In other words, I would raise the bar before accepting new data_type/ folders (I think they are arbitrary and do not serve a very clear purpose anyway, so I see them as almost always unnecessary).

[yarikoptic]

so I see them as almost always unnecessary).

• please chime in (at least 👍 ) the Dissolve (remove) {datatype}/ level/folder bids-2-devel#93

IMHO, new data_type/ folders should be considered "molecular" (i.e., not atomic) and new _suffix could be considered atomic.

An interesting analogy, and it is indeed so, somewhat by "definition" of a folder being a container for (typically) multiple things, and often they are of different "types" one way (modalities) or another (file types, as data vs .json sidecar). Indeed we need to be more cognizant when allowing for a new data_type/ folder, but to a degree, even more thoughtful about _suffixes since, as you noted, we could get entirely get rid of data_type/ folders and I do not think loose an ability to understand/query data, potentially only loosing some convenience from groupping some times (e.g. easier separation of high level data modalities e.g. eeg vs mri). But, again, what should we do within BIDS 1.x spec to clarify on this point overall?

[oesteban]

data_type/ folders and I do not think loose an ability to understand/query data, potentially only loosing some convenience from groupping some times

Most of the cases, data_type can be inferred from the suffix, so it's "queriable" by definition.

Perhaps, "simultaneousness" requires more work for the database if scans.tsv files are not present, but they could become mandatory.

Other than that, the folder buys nothing for machines and it's a matter of taste for humans.

[neuromechanist]

Moved my comment from 2231 here, thanks @oesteban, I overlooked:

+1 for clarity. But, I am afraid the argument (if we have beh why eeg, ieeg, pet are not categorized in func) is not as strong, especially as BIDS has strived for clear definitions, reproducible metadata, and community-led extensibility. Following this argument, one could argue since the stimuli/ directory does not have a mandated structure, why other directories should have a structure.

IMO, the answer is quite clear, because those who contributed to the standard recognized that there are topics that are not func, eeg, pet, etc. and that they are not the subject matter expert on those. Another answer could be that by surveying open-data resources, there are "as much" data and usage of open data for a modality that urges the need for a separate modality yet. Once experts or even enthusiastic power users have enough interest, they propose a BEP and lead the charge.

On the clarity, I'd suggest to the BEP Process Working Group to add a note on the BEP Process page, and encourage the community to lead the charge to propose more datatypes like eeg, pet, emg to reduce the burden on behavioral-oriented data types.

To sum up, BIDS current structure is much more an effort toward FAIR data and metadata representation in a highly structured and schema-oriented approach and less as a "two conflicting grouping mechanism."

[oesteban]

Thanks for moving 👍 . It can be responded now:

On the clarity, I'd suggest to the BEP Process Working Group to add a note on the BEP Process page, and encourage the community to lead the charge to propose more datatypes like eeg, pet, emg to reduce the burden on behavioral-oriented data types.

This is a foundational and interpretation problem, not procedural. Addressing under BEP process will just dissolve the legitimate concern. It will creep up again.

To sum up, BIDS current structure is much more an effort toward FAIR data and metadata representation in a highly structured and schema-oriented approach and less as a "two conflicting grouping mechanism."

I can't see the connection between this discussion and FAIR. I can't see either how one option (I assume the data_type/ folder) is "highly structured" and (even more 👀 ) "schema-oriented" than the other.

Finally, responding to the final point (which feels pretty tangent to the FAIR and structuring to me), this is not a clash between "grouping mechanisms", it's an arbitrary choice that had consequences we did not anticipate. And it is creating serious problems for the standard.