There are a number of cases of mutually exclusive items or conditional relationships between items in the specification, and we'll need to support them in the schema.

One prime example is timing metadata for fMRI. In that situation, there are five metadata fields (RepetitionTime, SliceTiming, AcquisitionDuration, DelayTime, and VolumeTiming) with specific relationships. There are five supported patterns for these five fields.

Another, less idiosyncratic case is entities work for the dual-purpose beh suffixes (physio, stim, beh, and events). In all cases, they have two options for entities: (1) place the files under beh, in which case there are a set of applicable entities, or (2) place the files under the associated imaging data type, in which case they much "match" entities, plus a reduced set of applicable entities.

To handle the latter case, I was thinking that the schema could include a match "entity" (basically a special stand-in for a set of entities that may vary based on the associated imaging data). We would need to protect this term from the main specification, even though it would be almost exclusively internal.

To handle mutual exclusion, I think we could start using nested lists or something, so if we originally had:

- suffixes:
    - stim
    - physio
  extensions:
    - .tsv.gz
    - .json
  entities:
    sub: required
    ses: optional
    task: required
    acq: optional
    run: optional
    recording: optional

we could instead have:

- suffixes:
    - stim
    - physio
  extensions:
    - .tsv.gz
    - .json
  entities:
    - matches: required
      recording: optional
    - sub: required
      ses: optional
      task: required
      acq: optional
      run: optional
      recording: optional

In that case there would be two options for entities for stim/physio data, represented as a list of dictionaries.

An alternative that might be more flexible would be to use keywords like OR, AND, and NOT as keys to dictionaries, like so:

  entities:
    - OR:
        - matches: required
        - sub: required
          ses: optional
          task: required
          acq: optional
          run: optional
    - recording: optional

When applied to the timing information for fMRI, this option would look like:

  metadata:
    - OR:
        - AND:
            RepetitionTime: required
            NOT:
                - AcquisitionDuration
                - VolumeTiming
        - AND:
            SliceTiming: required
            VolumeTiming: required
            NOT:
                - RepetitionTime
                - DelayTime
        - AND:
            AcquisitionDuration: required
            VolumeTiming: required
            NOT:
                - RepetitionTime
                - DelayTime
        - AND:
            RepetitionTime: required
            SliceTiming: required
            NOT:
                - AcquisitionDuration
                - VolumeTiming
        - AND:
            RepetitionTime: required
            DelayTime: required
            NOT:
                - AcquisitionDuration
                - VolumeTiming
    - EchoTime: required
    ...