Add concept of a "grouped scan collection" to common principles

[tsalo]

BEP001 (#508) introduces the idea of a “grouped scan collection” with respect to certain suffixes. In a recent call with @agahkarakuzu and @emdupre, we talked about the idea of divorcing the idea of grouped scans from specific suffixes, given that some suffixes in BEP001 refer to multiple files from the same acquisition and some refer to multiple files from different acquisitions. Moreover, I’d like to future-proof the concept by not linking “grouped scan collections” to specific suffixes, in case of changes to sequences.

Currently, the specification already has the mechanism (i.e., entities) to support multiple files from a single acquisition, but not multiple files from separate, but associated, acquisitions. If we could add the concept of a grouped scan collection to the common principles, I think that this would make things easier.

Tagging @agahkarakuzu, @emdupre, and @sappelhoff.

[tsalo]

What about a metadata field to indicate files that were either simultaneously acquired or should be treated as such? The latter would essentially be a "cheat" for the associated scan groups required by BEP001.

In the json, we could have "AcquiredWith" with a format similar to "IntendedFor", or in the scans.tsv file there could be a column with a unique identifier for files acquired at the same time.

[tsalo]

In #622 and #624, @oesteban introduces new metadata fields with purpose-specific grouping identifiers (i.e., one field for grouping multi-part DWI scans and one field for grouping B0 estimation-related files). This is definitely different from the general group identifier field that I was proposing at the start of this issue, but it does seem like it could solve BEP001's grouping issue as well.

@agahkarakuzu, what do you think of having metadata fields that identify groups of files for specific qMRI targets?

[agahkarakuzu]

@tsalo as an attempt to i) mitigate the ambiguity introduced by using over generic suffix terms in identifying files belonging to B0 mapping with retrocompatibility in mind and ii) to use files outside /fmap folder for B0-mapping, this sounds like a good solution. It also has no contingencies in terms of interchangeability. Whereas neither (i) nor (ii) is applicable to our case. Former is the very reason why we are aiming at descriptive suffixes, and the latter is not a case in the scope of the applications we describe in BEP001.

I doubt that this approach can help cover the basis for qMRI applications BEP001 introduces. I am also afraid that trying to adapt this solution will restart the discussion about how anatomy imaging suffixes are going to be named in that case (we may end up calling everything GRE again, hence disintegrate the interchangeability principle) , which could easily bring us back to square one. We really need to create main application branches (BEP001 is diligent not to be granular about this already) for qMRI through suffixes so that we can propose a meaningful data organization. Otherwise it would require qMRI data providers to create json puzzles and users to solve them.

Something like qMRIdentifier hidden in the metadata could be useful when a qMRI-relevant suffix has different flavors, but even in that case, would be a supplementary information rather then than a requisite. Because as we know what that suffix means, the rest can be easily inferred.

[tsalo]

I think this should have been closed by #688, so I'm going to close it now.