When running the multi-run pipeline, should we use "run" or another word to refer to the scans?

[smoia]

Instead of using "run" to indicate a scan, we could use a different token - "take" or "scan" for instance.

Detailed Description

At the moment, the multi-run pipeline divides recordings into chunks and indexes them using the "run" label.
The thing is that "run" is a label with a precise meaning in BIDS, and despite the definition might be slightly loose, it might be better to use a different label to indicate a chunk of data, such as "scan" or "take" or even "chunk".

The reason is twofold. On one side, the current behaviour suggest a naming that increments the "run" with each scan. It looks like it's common practice in BIDS to use and increment "run" only when two files are otherwise named identically, e.g.:
I have three scans, in order a RS, a a TASK, and a RS.
The current behaviour suggests:

• [...]task-rest_run-1[...]
• [...]task-TASK_run-2[...]
• [...]task-rest_run-3[...]
  While it seems to be common practice:
• [...]task-rest_run-1[...]
• [...]task-TASK[...]
• [...]task-rest_run-2[...]

The second reason is that it will be easier to understand the code if we maintain "run" as per BIDS label, and use a different naming system for the chunks of recordings.

[tsalo]

In the specification, a "run" is referred to as a synonym of a "data acquisition", which is "a continuous uninterrupted block of time during which a brain scanning instrument was acquiring data according to particular scanning sequence/protocol." However, I'm hoping to differentiate the two at some point, for reasons related to BEP001 and reflected here. My point being that "data acquisition" (or just "acquisition") might be a good term for this, since it's already defined within the specification, even if it's not as commonly used as "run".

[smoia]

@physiopy/all , opinions?

[RayStick]

I think "scan" makes sense to me. That's what I would use to describe it. And then a run suggests a repeated scan.