Related Standards

[effigies]

BIDS is a structure for organizing data and metadata. There are some BEPs that go beyond this to do something quite different:

• BIDS StatsModels (BEP 002) is a specification of intended processing. While how to name stats models fits neatly into the existing format, the file contents are somewhat tangential. Consistency with BIDS variable (TSV column) naming schemes and conventions is a general goal, and so it makes sense for this to depend on BIDS, but to include this in the BIDS spec would preclude backwards-incompatible changes. A separate versioning scheme for the models would make it easier to put out usable results.

• The above discussion can probably be applied nearly word-for-word to computational models. I'm not quite sure of the status of that effort.

• The transform file format (BEP 014) is somewhat similar. It internally has little need to reference BIDS names, so is almost wholly independent except that it would be nice if BIDS permitted it as a valid extension. And again, format versions do not need to be on anything like the same timetable as BIDS proper.

In addition to the above, where to put these in the actual structure of the specification is unclear. Transformations may be considered modalities, but model specifications are harder to wedge in. To add these coherently, I believe the current spec would need to become a subsection of a larger structure. It probably makes more sense to think of these as related but not fully subordinate.

Assuming this seems reasonable there are some questions:

1. Where should these specifications live?
2. How should we link to them on the website and main spec?
3. How should maintenance of these specifications be handled, if differently from the main specification?

[tyarkoni]

Re: BIDS-ComputationalModels, that effort is IMO sufficiently independent that it doesn't really make sense to construe it as part of the BIDS ecosystem at all. It currently has essentially zero overlap with any of the other BIDS specs. What we probably will want down the line is an execution/glue spec that mediates between BIDS dataset and the computational model spec, but that will probably be very lightweight.

BIDS-StatsModels is a bit different because much of the content of the spec is currently tied to the BIDS ecosystem to some extent. To the degree that we want to retain that link, I think it makes sense to retain the BIDS branding to some degree—though I agree that it still wouldn't make sense to think of BIDS-StatsModels as part of the BIDS spec in the same way as the core spec, derivatives, etc. I.e., if we went this route, I would probably want to call it an extension forever, without any implication that it would eventually be merged into the same document as the rest.

The alternative is to adopt the same approach here as for the BIDS-CM spec—i.e., to deliberately minimize/eliminate any explicit dependencies between BIDS-SM and BIDS, and then write a small wrapper spec to mediate between them. Currently the main dependency is that BIDS-SM uses the level names defined in BIDS ("run", "session", "task", "subject", etc.). But that's actually about it. Since we've already resolved to handle the mapping from BIDS datasets onto BIDS-SM inputs via a separate execution spec, there's actually no reason that I can see to continue to brands BIDS-SM as a BIDS product. I don't know that it matters much one way or the other, because I think the probability is pretty low of anyone wanting to adopt BIDS-SM who isn't working in BIDS (and certainly not outside of the imaging community). But in principle it could be more generic.

In general, I guess I like the idea of divesting BIDS of these other specs and retaining only the parts necessary to bridge between BIDS datasets and what the other specs do. So, for example, suppose we rename BIDS-SM to something like NISSM (Neuroimaging Specification for Statistical Models), BIDS-NISSM would then specify how BIDS datasets get mapped onto NISSM-supporting tools. The main use case for such bridges would then presumably be in building BIDS-Apps.

[poldrack]

I like the idea of separating the spec (e.g. into NISSM) and the having a separate interface between specs (i.e. BIDS-NISSM).

[sappelhoff]

related: #255

[yarikoptic]

I think this discussion is also in alignment with the question of "standard versioning". And interesting and related evolution is happening ATM within Zarr (and "derived" OME-Zarr which uses Zarr format for open microscopy, and we do support that format within BIDS):

• https://github.com/zarr-developers/zarr-specs/issues/299#issuecomment-2166656804 - so Zarr is largely abandoning all the ".minor.patch" versioning as a decision factor on "compatibility" of any given tool with the given Zarr archive
• https://github.com/zarr-developers/zarr-specs/pull/262 , working to define "Zarr Conventions" or "namespaces" (or features etc) formalization so given a Zarr tool could see which extensions are there and claim support of some but may be not the others
• this is apparently might have been inspired by evolution in HTML which abandoned versioning as well back in 2011, See recent blog post Versioning in OME-Zarr by @normanrz

And BIDS is highly modular and there is really no way ATM for tools to claim "full support of BIDS 1.?.?" since they simply typically would not care about e.g. unrelated modalities etc.

With that in mind, I think that eventually (may be could be a target for BIDS 3.0???) BIDS should follow the suite as to provide

• https://github.com/bids-standard/bids-2-devel/issues/66
• establish clear "boundaries" between elements of the schema to describe them as FEATURES of some kind (e.g. different modalities, inheritance principle, etc), so that any given tool could immediately see/declare what it supports and what not (e.g. I wonder how many tools currently implement inheritance principle "fully"?)
• https://github.com/bids-standard/bids-2-devel/issues/74 to provide extra FEATURES which might be even eventually offered as BEPs to become part of the standard

and then at large "freeze" within BIDS3 model. While thinking/developing this strategy we should see/review/stay in touch with related developments in DICOM/Zarr/OME-Zarr and other standard communities.