dataset.modalities and dataset.datatypes are not being populated in the BIDSContextDataset

[psadil]

So, I think there is a set of warnings that are not currently being triggered, like B0_FIELD_SOURCE_RECOMMENDED

# there is a 'perf' file with .nii.gz extension in a dataset that has fmap data
❯ eza -T bids-examples/asl004
bids-examples/asl004
├── dataset_description.json
├── README
└── sub-Sub1
    ├── anat
    │   ├── sub-Sub1_T1w.json
    │   └── sub-Sub1_T1w.nii.gz
    ├── fmap
    │   ├── sub-Sub1_dir-pa_m0scan.json
    │   └── sub-Sub1_dir-pa_m0scan.nii.gz
    └── perf
        ├── sub-Sub1_asl.json
        ├── sub-Sub1_asl.nii.gz
        ├── sub-Sub1_aslcontext.tsv
        ├── sub-Sub1_asllabeling.jpg
        ├── sub-Sub1_m0scan.json
        └── sub-Sub1_m0scan.nii.gz

# B0FieldIdentifier and B0FieldSource are both missing everywhere
❯ grep -ilv B0Field bids-examples/asl004/**/*json
bids-examples/asl004/dataset_description.json
bids-examples/asl004/sub-Sub1/anat/sub-Sub1_T1w.json
bids-examples/asl004/sub-Sub1/fmap/sub-Sub1_dir-pa_m0scan.json
bids-examples/asl004/sub-Sub1/perf/sub-Sub1_asl.json
bids-examples/asl004/sub-Sub1/perf/sub-Sub1_m0scan.json

❯ deno run -ERWN jsr:@bids/validator --version                                                                                
bids-validator 2.4.1

❯ deno run -ERWN jsr:@bids/validator bids-examples/asl004 --json | jq | grep -i B0_FIELD | wc -l
       0

From what I can see, no construction of a BIDSContextDataset object ends up with populated datatypes and modalities fields, causing selectors like "intersects(dataset.datatypes, ['fmap'])" to always be false (meaning the rule is not applied). Not sure whether there's a schema-blessed way to fill the modalities and datatypes part of the context, but I would have assumed that the constructor for BIDSContextDataset would need to walk the filetree so that the selectors can be evaluated once files start getting validated.

[viranovskaya]

Hi, I reproduced this and have a local implementation.

BIDSContextDataset now makes one lightweight pass over the file tree using the existing findDatatype() logic. It skips ignored files, opaque directories, and pseudofile contents, and fills the unique datatype and modality lists before any schema rules are evaluated.

On asl004, this produces the two expected B0_FIELD_SOURCE_RECOMMENDED warnings for the ASL and m0scan files.

It also exposes eight existing NonlinearGradientCorrection errors in pet001, pet002, pet003, and pet005. In pet005, the field appears to use NonLinearGradientCorrection, while the other examples do not contain enough information to choose a value safely.

Would you prefer a coordinated bids-examples update before the validator PR, or another way of handling these newly activated checks? I do not think the validator should suppress them.