Separation of metadata describing data vs. intended processing

[Lestropie]

Expansion of the logic in #53 to cover more than the Issue title.

There are likely many situations where one wishes to be able to provide instruction on how the person responsible for collecting the data intends for those data to be processed. While many Apps may provide some degree of control over how processing is performed at the CLI, some more nuanced details may become too complex to be manipulating at the CLI; further, it is quite common for data to have been collected with the intention of being utilized in some way during processing.

Therefore, what I'd be interested in as a hard transition from BIDS 1.x is a standalone JSON file whose exclusive purpose is encoding the intended relationships between input data, processing steps, and output data. What I want to do in this Issue is invite insight from contexts outside of my own experience where similar logic may be applicable, to gauge the scope of what such a format may need to be able to cover.

• In Change handling of field mapping information #53 I've already discussed how this could be used for B0 offset field maps in MRI. It would involve metadata changes in the case of spin-echo EPIs, and suffix changes in the case of dual echo gradient echoes.

• Input data files in a BIDS Raw dataset do not always have exclusively either a one-to-one or many-to-one mapping to output data files in a BIDS Derivatives dataset.
  Take for example a complex DWI acquisition, where there's two different acquisitions for two different purposes---let's call them X and Y---but each is additionally acquired with two different phase encoding directions---say AP and PA. Ideally there should be some way of encoding that the input images of run X with phase encoding AP and PA are somehow combined to produce one output series for run X, and the input images of run Y with phase encoding AP and PA are combined to produce one output series for run Y; but data across the two runs are not to be combined. Maybe a sufficiently clever tool can either infer what it thinks is best to do, or provide CLI options to modify its behaviour. But the most robust and extensible solution would be to provide to the tool a file (potentially as content within the input dataset) that encodes this mapping, potentially as well as any additional information about processing steps that should be applied along the way.

It's possible that some of this will be assessed as creeping outside of the scope of BIDS; or maybe into BEPs relating to applications / processing. But the examples above I do think relate to the raw dataset in terms of intentions of the person responsible for acquiring and providing the data. So discussing the concept may need to be bisected into:

• What would be the possible scope of such an approach if it were constrained exclusively to what would be appropriately defined as part of the BIDS Raw dataset; that is, what is reasonable for the person providing the raw data to be defining as their intended usage / interpretation of those data.

• What would it look like to define a more generic and powerful interface that would be accepted as input by BIDS Apps and more actively modified by users of BIDS Apps, to define image processing operations and mappings between input and output data in a manner defined by the specification rather than the esoteric CLIs of individual Apps.
  And indeed whether there's a sufficiently broad scope of use cases to warrant this degree of complexity.

[yarikoptic]

attn @effigies and @ericearl on this one if you have a chance to review/provide feedback.

[ericearl]

@yarikoptic I'm off work this week, but I'll try to come back and take a look next week.