Software Ecosystem Plan

[jbteves]

I would like to see as part of the v2.0 standard, a concrete plan of action for creating a robust software ecosystem around BIDS. I believe that standards should come with as complete as possible tooling to support that standard. While it's true that many apps have been developed to be BIDS-compatible, I think that the current approach is not communally focused and instead requires going back and forth between major packages and asking them to implement changes for BIDS, rather than implementing complete solutions. I would also propose that a full-fledged 2.0 would minimally consist of the following software solutions (some of which already exist):

1. A web-based validator tool.
2. A command-line-based validator tool.
3. A conversion tool which guides the user through the creation of a full BIDS-compliant dataset, or trivially adds to an existing one. (Note: dcm2niix and heudiconv exist to facilitate this, but still require that the user follow the specification and validate. I propose that the program follow the specification and validate; this is a reason for requiring (2)).
4. A tool which queries metadata via the command line to enhance scriptability.

If there exists some plan already and I've missed it, please feel free to close this issue.

[tyarkoni]

Can you elaborate on what you think a concrete plan of action of this sort would look like? BIDS doesn't have a dedicated, long-term funding source; the initiative is entirely reliant on the community for contributions. So conditioning the release of 2.0 on having the kinds of tools you describe—which I suspect everyone agrees would be great to have—seems like a recipe for never releasing 2.0. (For reference, there isn't even have a fully-compliant web-based validator for 1.0 at the moment, and it's not because people don't think this is important.)

[jbteves]

In that case, part of the concrete plan of action would include securing funding. Are there existing efforts to secure the funding? If so, how might one contribute?

A concrete plan of action would include specifications for what these programs would do, contact points for who is responsible for overseeing the projects, and agreements for funding their development rather than ad-hoc volunteering.

This goes more into governance, but one barrier to adoption at my institution is the lack of existing software and long-term funding for BIDS. So I would view this is a key issue.

[tyarkoni]

In that case, part of the concrete plan of action would include securing funding. Are there existing efforts to secure the funding? If so, how might one contribute?

There have been, and continue to be, plenty of efforts to secure funding. But most of them, as you might expect, are focused on expanding whatever part of the ecosystem is most salient to the proposing researcher's needs. If you (or someone at your institution) want to write a grant proposal to fund the tools you describe, you're welcome to, and I'm sure the community would be happy to contribute, provide letters of support, etc (I certainly would!). But we are operating on the academic model here; nothing is going to happen unless someone takes the initiative, because everyone is already overcommitted and has other things on their plate. (And of course, when people do get funding, there's no guarantee that they'll share your assessment of what ought to be prioritized.)

A concrete plan of action would include specifications for what these programs would do

Feel free to draft specifications to this effect; I'm sure people would be happy to consider them for inclusion in a 2.0 draft.

contact points for who is responsible for overseeing the projects, and agreements for funding their development rather than ad-hoc volunteering.

See above: this is all contingent on someone volunteering their time to lead such projects, or securing the funding for them.

This goes more into governance, but one barrier to adoption at my institution is the lack of existing software and long-term funding for BIDS. So I would view this is a key issue.

Understandable, but that's the reality of it. I don't think folks in the BIDS community are naive to the fact that if there were better tooling and long-term support, people would be more likely to adopt the standard. But as a community-driven effort, there is no way to wave a magic wand and obtain a bunch of FTEs to do the work. I think the success of BIDS so far is a testament to many PIs and institutions' recognition that BIDS isn't a turnkey commercial product, and does require some investment of time and/or energy at the moment. There's no question that there are limitations, and that some people/institutions might not buy in because of them.

[mateuszpawlik]

I'd like to chip in to point 3. with BIDScoin which uses BIDS schema for DICOM to BIDS conversion. I'm not the software developer. I like many features of BIDScoin but you can judge yourself.

[yarikoptic]

Indeed BIDS schema and https://bidsschematools.readthedocs.io help along the way here. Finalizing current JavaScript-written validator to become fully schema-driven is already pretty much pre-requisite for instigation "schema-level" work towards "BIDS 2.0".

As for 3 and 4 (conversion tool, metadata query library/tool). I do not think there would ever be "the standard" conversion tool, especially as an increasing number of modalities being supported by BIDS. Thus it is critical to have validation/validator a separate tool. Now, having BIDS specified through schema opens indeed for better possibilities for metadata querying tools but again I do not see "the one and only" to be made available.

Overall, I think we would need to limit the "software ecosystem plan" to

• schema library (currently only Python): providing high level abstractions to load/manipulate schema elements
• validator(s): ATM JavaScript one is canonical and there is only basic validation implemented within bids schema tools in Python. It should be possible to implement fully fledged Python implementation of validator (@effigies said that he even had implemented some Python based parser for the validation specifications in the schema) but I am not totally certain it must be the requirement for BIDS 2.0 release.