rest condition should have task name starting with rest not == to rest

[agramfort]

ok for you @sappelhoff @hoechenberger ?

see at https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/01-magnetic-resonance-imaging-data.html

The task label included in the file name is derived from this "TaskName" field by removing all non-alphanumeric ([a-zA-Z0-9]) characters. For example "TaskName" "faces n-back" will correspond to task label facesnback. A RECOMMENDED convention is to name resting state task using labels beginning with rest.

[hoechenberger]

On the one hand, I agree we're currently being too strict.

On the other hand, we might produce false-positives here. Imagine a task restless, or restore, or restricted, or restaurant, … you get the idea.

I'm starting to think we should introduce a config option, allowing the user to specify whether the data at hand is a resting-state recording or not.

WDYT?

[agramfort]

yes I think you are right. How would you write such an option @hoechenberger ?

[hoechenberger]

@agramfort

Since we currently only allow to process a single task, we could simply have

task_is_resting_state: bool = False

Super low-effort and not very flexible, but I think absolutely sufficient for now. WDYT?

[hoechenberger]

task_is_resting_state: bool = False

Maybe better:

task_is_resting_state: Optional[bool] = None

and if None, we apply the existing heuristic (task name equal to "rest"); and with a boolean value, the user can force the treatment of any task as either resting-state or not.

[agramfort]

looks pretty ok https://output.circle-artifacts.com/output/job/27fa0c6f-01aa-4c51-8044-aaf015d4bdff/artifacts/0/site/examples/ds003775.html !

this one is ready for review @hoechenberger 🙏

[agramfort]

@hoechenberger please have a look at this one when you have a moment. 🙏

[hoechenberger]

Some nitpicks, otherwise LGTM!

[agramfort]

🙏 @hoechenberger

[hoechenberger]

Thanks @agramfort!!!