Add `/imaging-modalities` route for getting available imaging modality term instances & labels

[alyssadai]

Currently, the instances endpoint responses have this structure:

{
  "nb:Diagnosis": [
    {
      "TermURL": "ncit:C94342",
      "Label": "Healthy Control"
    },
    {
      "TermURL": "snomed:58214004",
      "Label": "Schizophrenia"
    }
  ]
}

To provide all the imaging modality metadata the query tool needs to display, we at minimum need to add:

• abbreviation (BIDS suffix)
• data_type

We also want to make imaging terms configurable via a vocab file (similar to diagnoses/assessments) instead of hardcoding in CLI/query tool.

Implementation tasks

• Communities

  • Add imaging modalities vocab to neurobagel/communities configs (e.g., Image standardized variable): update communities README with a small hint on imaging modalities being different
    • Include fields: term identifier (NIDM URI), label, abbreviation (BIDS suffix), and data_type.
    • Ensure config.json references the new vocab file so it’s fetched at startup.

• API:

  • Add /imaging-modalities and /imaging-modalities/vocab routes mirroring assessments/diagnoses.
  • Ensure instances SPARQL query targets objects of nb:hasContrastType and matches each TermURL returned from the graph to the term's corresponding Label, abbreviation, and data_type from the vocab file fetched on startup
  • Extend startup vocab loading to include imaging vocab, add Imaging modality to configurable variables.
  • Update term response shaping to pass through the extra metadata for imaging modalities while keeping existing shape for other attributes.
  • implement test coverage for the new routes, including:
    • Happy path with vocab providing labels/abbreviation/data_type.
    • Handling missing labels/metadata.
    • Auth behavior consistent with other standardized-term routes.

[alyssadai]

Hey @rmanaem, thanks for updating the issue description. I think all the API tasks make sense (one point edited slightly for clarity).

One change to the spec I'd propose is seeing if we can avoid adding imaging modality as a standardized variable in each config.json file. Atm, pipeline and imaging modality variables are not included in config.json because these are a) not annotatable but rather extracted automatically b) we will likely never make them configurable by the user, unlike phenotypic variables and terms. For those reasons, I don't think they need to belong inside config.json.

The CLI currently fetches the imaging_modalities.json file directly from the Neurobagel community subdirectory - I think if we could get away with a similar solution for the API, that would be cleaner. Wdyt?

[surchs]

@alyssadai please update the spec to reflect new decisions.

• we don't add imaging modalities in config.json
• as part of this issue, udpate communities README with a small hint on imaging modalities being different