Run parameterization

[Chris Markiewicz]

Hi all,

Currently, for a dataset processed with a given pipeline <pipeline>, the root directory derivative dataset is named <pipeline>/.

One of the issues that was discussed in the BIDS derivatives breakout group is how to label a derivatives directory to indicate specific run parameters, which would (for instance) allow comparing the results of the application based on the presence or absence of a given parameter. As concrete examples, consider iterating over registration methods, or smoothing windows.

The consensus proposal was to permit generic labels, so that derivative datasets may also be named <pipeline>_<label>, where label may be specified by the user or algorithmically constructed by the app itself.

I want to propose a `--exec-label <label>` command-line option that BIDS apps respect, to apply the given label to the derivative dataset name. I'm not strongly attached to the option name, but I do believe that some such access should be permitted.

What do y'all think?

-- 

Chris Markiewicz

[Eric Earl]

Chris M, et al,

I like this idea.  Though it would not be a strict requirement of any particular pipeline run, this would be good to include in the next BIDS spec with some suggestions or guidance.  For instance, from this discussion I also came up with a sort of semantic naming idea following that same convention, I think, where the label is composed of <inputset>_<optionset>, the two most common things in my experience that change from one pipeline run to the next.  So if I were running the HCPpipeline, here is a rough example:

HCPpipeline_noT2_SIEMENS

I might call it "--app-label" instead as a given app is what makes a derivative folder, right?

~Eric

[Chris Markiewicz]

I agree that the BIDS spec ought to include guidance on the BIDS App interface. There is a document, but it's not as easy to find and its specification status is unclear.

With regard to your suggestion, `--app-label` would seem to suggest (to me) that you're giving an alternative label for the entire app, as opposed to an additional label that indicates execution parameters. It's a minor quibble though. It definitely sounds better than `--exec-label`.

[eric...@gmail.com]

Chris M, et al,

Good point.  I retract my "--app-label" suggestion and instead suggest "--deriv-label" or "--derivative-label" as that seems to be what's being labeled in this instance.  If that is still a point of contention, I would default back to your original suggestion, odd as its name may be, but perhaps you can get more feedback from the working group besides me?

~Eric