Community Review: BEP038 - Atlases and Templates #2250
Replies: 12 comments 55 replies
-
|
I think we should remove the I would like to avoid having to switch between |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @effigies for the summary, I think it is a valid representation. Some nuances to include:
half-concept: session is already there and cohort fully follows its semantics.
This has been said a couple of times and I answered I disagree. I don't think any examples have been given beyond mine above and in particular how it would be simpler without cohort. In fact, to express derivatives in which there aren't more than one than cohorts, it's simpler if the cohorts entity exists (example is above).
Most likely, we will add it and it just won't be used.
Which is good, metadata should not be encoded by the filename. In addition, Another downside is that I can't query for cohorts, so derivatives directories with several template roots and cohorts (eg., MNIInfantXYZ and UNCInfantABC) require me to either parse XYZ/ABC options or figure out something to understand cohorts. Please note that adding a cohort identifier in the template identifier makes it a nonstandard space too, and parsing becomes a lot more complex if the template id is already nonstandard (e.g., MyInfantIJK). At that point, it looks like a tokenizer item is necessary ( To this point, I haven't seen actual examples of XYZ in this case, so it's hard to criticize something I haven't an example for... And it is important because, for instance, templateflow's version of MNIInfant has the following cohorts: while UNCInfant has: what would ABC/XYZ cohort indicators be for MNIInfant and UNCInfant here? Also, if it is free in the name, what will prevent to have people say something like: ? (updated comment as the first version was written on a phone) |
Beta Was this translation helpful? Give feedback.
-
@oesteban If you're looking for examples, see (#2272) (rendered) for the spec changes, and bids-standard/bids-examples#521 for the changes to a derivative dataset. Note that in the derivative, the
I would imagine that the people distributing |
Beta Was this translation helpful? Give feedback.
-
|
One thing that I think is getting confused here is that, in templateflow, the root of the template datasets is the template directory itself, e.g., `tpl-dhcpAsym` looks like:To bring it into line with BEP038, it would become:Dropping cohort, it would become: |
Beta Was this translation helpful? Give feedback.
-
The logic here is reversed. I think you mean that, if they are forced into not using The redux, to me, is that cohort is actually a thing, why ignore that? Now the complicated example:
Why In the case you have coexisting cohort derivatives in the same folder (a quite specific thing btw, because you will normally use the specific cohort that applies, so possible but not a common case) both options are equally ambiguous. In this case, it is a problem (or a feature, IMHO) of how A totally reasonable alternative (though still out of the scope of this BEP) for power users who dislike the verbosity of space could be to define spaces (which is part of BEP014):
and then in the metadata, indicate that space A means MNIInfat's cohort 1. In addition, with cohorts, if you only have one cohort's derivatives in a given folder, you'd just use IMHO, you are blaming cohort- for a problem of space- (and for me, it's actually a feature to force trusting the metadata rather than the filename). |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, we cross-messaged.
We should scope this BEP within derivatives. TemplateFlow is in a different business (redistributing templates and perhaps acting as a registry). TemplateFlow is a good experience to drive how we operate here, but should not be discussed here. We may decide to have all templates filenames be MD5 hashes and then have a logical view over the data, that can be however you want. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think the |
Beta Was this translation helpful? Give feedback.
-
|
@melanieganz How can we not include scale and how it is not an atlas-based definition (as opposed to density, which specifies how the sampling is done on the surface)? |
Beta Was this translation helpful? Give feedback.
-
|
As @effigies mentions, you could use seg- to encode the scale, but then you end up with names like seg-7Networks100regions which is encoding the two concepts. The area of regions (scale) is an important concept in neuroscience so I can't see how it should not be included. |
Beta Was this translation helpful? Give feedback.
-
|
For the same reasons of the conversation regarding template/cohort, I'm going to update my example: |
Beta Was this translation helpful? Give feedback.
-
BIDS should allow users to express the concept. It may not apply to you in the case of the Schaefer atlas, but if it does for the authors, then they should be able to share the data with their intent being as explicit as possible. That said, the fact that the parcels are not spatially hierarchical doesn't mean they can't be semantically hierarchical. |
Beta Was this translation helpful? Give feedback.
-
|
I disagree that they should be considered hierarchical, even semantically, but the proposed Also just a side note: the 7-network and 17-network "versions" of the Schaefer atlas are the same atlas (i.e., parcels are the same, even if they have different labels), so I would just put those labels in different columns of the same dseg.tsv. This is what we actually do in the 4S atlas, which includes the Schaefer atlases. I'm not saying that the |
Beta Was this translation helpful? Give feedback.
-
|
I'm puzzled about the "License" field in
I'm also surprised that "SampleSize" is marked as REQUIRED, especially since it doesn't even appear in the accompanying example. My proposal would be to:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback @mguaypaq, those are great points! As far as I can tell/say (others should weigh in too), @effigies is correct re the |
Beta Was this translation helpful? Give feedback.
-
|
License if we have a |
Beta Was this translation helpful? Give feedback.
-
|
+1 Downgrade the "SampleSize" field to RECOMMENDED. |
Beta Was this translation helpful? Give feedback.
-
|
My understanding is that each folder under
So, I don't think a BIDS-compliant Also, in the case of a dataset which contains not just the atlas, it may be unclear exactly which files would be covered by the LICENSE in I agree that an atlas is useless without a license, but I would hope that any given atlas is available with a suitable license from a source other than needing to be extracted from some random dataset. It just seems to me that the "natural" unit for licensing is a whole dataset. I understand that these concerns are fairly abstract, but then again, so is the whole concept of licensing. Thanks for your work on BEP-038! |
Beta Was this translation helpful? Give feedback.
-
|
@mguaypaq See https://github.com/bids-standard/bids-examples/tree/bep038/atlas-4S as an example of a standalone derivative dataset where an atlas is among its sources. The idea is that it is plausible that you would not distribute the sources yourself (it may be a DataLad subdataset or just listed in For the distribution of an atlas as a dataset, yes, it is duplicative. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it is currently clear how to create multiple templates with different spatial references. For example, given the SUIT example, the data from 20 subjects are spatially normalized to MNI, and then averaged to create tpl-SUIT_T1w.nii.gz. The corresponding json file should include the 'SpatialReference', which is 'https://templateflow.s3.amazonaws.com/tpl-MNI152NLin6Asym_res-02_T1w.nii.gz' in this case. However, if I now wanted to create the template with a new spatial reference e.g. MNI152NLin2009Asym, how should this be structured, so I don't end up with two files with the same name? Can I use the 'space' entity to distinguish these? I would suggest to allow for that. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that is definitely allowed for. Any filename that is permitted for a I'm not sure how much we would see the specific use case you describe, since it would produce multiple authoritative registration targets and parcellations that could lead to different results for downstream users, depending on which target they use. At that point, it seems less confusing to call it two different templates. |
Beta Was this translation helpful? Give feedback.
-
|
I think it would be nice to also include a surface example using fsaverage. Given that the fsaverage spatial reference also appears https://bids-specification.readthedocs.io/en/stable/appendices/coordinate-systems.html and with the template here (https://www.templateflow.org/browse/), I would suggest to create a BIDS example using this, to also represent surfaces where the data spans multiple files (i.e. left and right hemispheres), where it is necessary to include the ‘hemi’ entity. This would probably also require to add more notation on surface-based templates and file names/extensions (such as *surf.gii?). |
Beta Was this translation helpful? Give feedback.
-
|
Surfaces are out of scope for this BEP. BEP011 introduces surfaces. |
Beta Was this translation helpful? Give feedback.
-
|
what happened to the 3D mean SUVR PET template (bids-standard/bids-examples@e463def#diff-7abfb299aa45ecdaa05d7609e65095cc9c09f3ecec58aaeceb98dde1396bac50) ? is that the _pet vs _petmap issue related @melanieganz @mnoergaard |
Beta Was this translation helpful? Give feedback.
-
|
I am a bit confused, what are you referring to, @CPernet ? Currently the BEP038 branch of the examples has no PET example, correct? That's why we need to agree on a suffix for these type of PET derivatives here and then we can add a PET atlas example. |
Beta Was this translation helpful? Give feedback.
-
|
I made the exemple already but got removed ... |
Beta Was this translation helpful? Give feedback.
-
|
I think @effigies removed it because the pet vs. petmap discussion was resolved in favor of petmap, but validating the dataset wouldn't be possible until petmap (or MImap?) was added to the spec. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this is why I was trying to add MImap now, so we can include a PET example here already as well. |
Beta Was this translation helpful? Give feedback.
-
|
To test out this BEP, I'm trying to BIDSify the PAM50 spinal cord template, and I have some questions. The atlas folder contains several probabilistic segmentations, with one structure per file.
In short: where should one describe the values of the label entity for probsegs? |
Beta Was this translation helpful? Give feedback.
-
|
Also, in |
Beta Was this translation helpful? Give feedback.
-
|
probseg.tsv isn't supported yet (see #2246). I think you can use your own values in |
Beta Was this translation helpful? Give feedback.
-
|
Also, I see that both
|
Beta Was this translation helpful? Give feedback.
-
|
In trying to BIDSify the PAM50 template, I'm also running into some missing suffixes (other than
For the number of axons, it's an integer, but it's not really a dseg. Is there a recommended suffix to use for this kind of data file? |
Beta Was this translation helpful? Give feedback.
-
|
The problem here would be that AFAIK, there's no specification for histology images in BIDS. Should there be a spec for histology, those maps you list feel like they could use |
Beta Was this translation helpful? Give feedback.
-
|
I see, this part of the PAM50 is out of scope for this BEP. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Minor error spotted in the example: |
Beta Was this translation helpful? Give feedback.
-
|
cc @PeerHerholz |
Beta Was this translation helpful? Give feedback.
-
|
This is out of scope for this BEP, but I am curious how other BEPs (especially BEP 017: Relationship matrix data schema and others that describe parcellated data, such as BEP011 and BEP012) will work around the As an example, using Schaefer (since that includes atlas, seg, and scale entities): @PeerHerholz @jdkent is this taken into account in BEP017? I just want to make sure that the proposed entities can be inherited and do not need to be modified for downstream outputs. For example, I'd like to make sure that |
Beta Was this translation helpful? Give feedback.
-
|
Hey @tsalo, thanks for bringing this up. We were/are worried about that too given things can escalate quickly as you outlined in the example. We had some meetings and during one of the maintainer meetings, @cmaumet brought up the |
Beta Was this translation helpful? Give feedback.
-
|
@tsalo please note that As a good principle, names should not be used to track provenance. It is unlikely (unless some multiverse analysis with a focus on that) that you need to keep space in the name at all (neither It doesn't seem like a terrible problem. That said, BIDS cannot preempt someone using |
Beta Was this translation helpful? Give feedback.
-
As long as the parcellation and connectivity BEPs support all of the entities, and doesn't, for example, require that the |
Beta Was this translation helpful? Give feedback.
-
|
@PeerHerholz I think you are referring to the Provenance BEP (BEP 028). Happy to contribute to the discussions as needed! |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, was reading "inherited" and used the wrong word, fixed now. |
Beta Was this translation helpful? Give feedback.
-
|
Judging by the three votes and ongoing discussions, the questions have not been resolved. Can we schedule a call for this week or next to see if we can come to a consensus? We've been doing 10-11am EST (4pm CET) on Tuesdays, if that works for people. I will also ping the email thread. |
Beta Was this translation helpful? Give feedback.
-
|
Should work on my end! |
Beta Was this translation helpful? Give feedback.
-
|
That works for me too. |
Beta Was this translation helpful? Give feedback.
-
|
Also works for me |
Beta Was this translation helpful? Give feedback.
-
|
Thank you all for the discussion! I am belatedly closing this. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We are pleased to announce the community review period for BIDS Extension Proposal (BEP) 038!
BEP038 extends the BIDS standard to describe BIDS Derivatives datasets that are intended to be distributed as atlases and/or templates. It introduces new organizational and metadata features, but it does not introduce new data file types.
The draft specification may be found at: https://bids-specification.readthedocs.io/en/bep038/, with the most significant changes in Derivatives - Template and Atlases and Derivatives - Imaging data types - Derivatives from atlases.
The proposed changes may be found at #1714. To view the source difference, click the Files changed tab.
Example datasets may be found at:
Procedure
Review period
Community review is open from November 10 - November 21, 2025.
Voting
This discussion is a poll, which you can vote in once and cannot change your response. Therefore, please vote once you are satisfied that your answer will not change.
If you vote "No", you may create a thread to explain your reasoning or send a private email to bids.maintenance [at] gmail.com so that your position can be fully understood.
How to review
Use threads in this discussion to request clarification or changes to the BEP. Each independent topic or proposed change should have its own thread. Please review existing threads and consider adding comments to those, if your topics are already being discussed. If your concerns are adequately represented by an existing comment or comments, consider using the 👍🏻 reaction button to indicate agreement in place of extending the discussion.
Where possible, propose the specific text you would like to see added or removed.
For minor issues, such as typos, feel free to make code suggestions only, using the suggest feature on the BEP038 pull request. These suggestions may be accepted or rejected without discussion, so do not make substantial proposals in this way.
Finalization
Once the review period is finished, the BEP leads and maintainers will consider the entire discussion, identify outstanding points to be resolved, and work toward finalizing the BEP. Community members may be asked to participate in this process to provide the necessary expertise.
Before being merged, the BEP will be integrated into the BIDS validator, and the examples must pass the validator.
A BIDS 1.11.0 release is anticipated in December 2025/January 2026, regardless of the conclusion of this specific BEP.
If, for any reason, a critical issue is found after the BEP is merged, the BEP will be reverted while the issues are addressed. At the discretion of the BIDS steering group and maintainers group, depending on the scope of changes, a new community review period may be opened.
9 votes ·
Beta Was this translation helpful? Give feedback.
All reactions