Extension of BIDS to organize atlas data via four features

[flyxiaye]

Hi @bids-maintenance & everyone, we are working on the specification for the storage and organization of the brain atlas data, where the atlas data is described as a new type of neuroimage data. Importantly, we mainly distinguish the atlas via four features which are specie, modality, age and spatial resolution.
This extension is motivated by the absence of reference schema on the storage and organization of the atlas data and we are going to provide a detailed document to define and organize the atlas data, further to help researchers use and share brain atlas to conduct neuroscience research.
The team is currently working on a draft here and is going to hear the suggestions from the whole community on this idea.

[tsalo]

@flyxiaye are you familiar with the atlas BEP in #1281? It might be a good idea to contact the BEP leads (@jdkent and @PeerHerholz) to see if you can combine efforts.

[jdkent]

Yes please, we should combine efforts! https://docs.google.com/document/d/1RxW4cARr3-EiBEcXjLpSIVidvnUSHE7yJCUY91i5TfM/edit

[PeerHerholz]

Yeah, please check out our draft if you have time. Your's looks great!

[flyxiaye]

Thank you for your prompt response @tsalo, @jdkent, @PeerHerholz. Unfortunately, we didn't notice the existing BEP. We have been working on this over a year. Although we kept an eye on this topic at the beginning, but failed to do so in the last few months. We have read through the BEP in #1281 submitted by @jdkent, it's no doubt that both BEPs have many in common and a wonderful work has been done.

In our point of view, however, there are significant differences between the two BEPs. To facilitate discussion, we would call the one by @jdkent as BEP-J and ours as BEP-Y, respectively. To be concise, BEP-J is about atlas individualization for image analysis, therefore, it's subfolders under each subject; while BEP-Y is about describing atlases in a 4D space defined by spatial resolution, time point, species, and data modality, or maybe called "the atlas of atlases", or a database/library of atlases.

The first three dimensions are (somehow) continuous, while the fourth is discrete. Apparently, other dimensions, such as authors, algorithms and methods, could be used to define the multidimensional space, while we reckon these four are the most useful, at least currently and in the foreseeable future.

Similar to the motivation behind BIDS, BEP-Y was conceived to deal with the problem of an increasing number of atlases and a lack of a common data structure to ensure code-reuse and easy sharing. Another motivation is that we consider atlases as a substrate for information integration. Therefore, in BEP-Y, we have structural and functional connectome data of each parcellation, as well as multiple -ome data included.

In our vision, BEP-Y has the following major applications in real-world scenarios:

1. Single atlas-based applications. In most cases, only one atlas (corresponding to a point in the 4D space of BEP-Y) specific to the study is needed. Once it has been checked out from BEP-Y, BEP-J can be applied to individualize it for subsequent computations. Therefore, we propose to use the BEPs in a sequence in atlas-based neuroimaging data analyses.
2. Multiple atlas-based applications in neuroimaging data analysis. This could happen in longitudinal studies, evolution-related studies, and multiple modality fusion-based studies. Similar to Point 1, BEP-Y and BEP-J can be used sequentially.
3. Studies on atlases. In such cases, no individual images are used. Instead, the atlas is the object under investigation. For example, a study on the overlap of two human brain MRI atlases or a study focused on the evolution of brain structural connectivity.

The following comparison between the two BEPs reflects the differences to some extent.

1. BEP-J organized atlas as the additional data of the subjects' neuroimaging data, which has the file organizing structure depicted as:

bids/
    sub-01/
        anat/
            sub-01_T1w.nii.gz
    derivatives/
        pipeline-<name>/
            space-<label>_atlas-<label>_dseg.nii.gz
            sub-01/
                sub-01_space-<label>_atlas-<label>_dseg.nii.gz

2. BEP-Y organized the atlas as a set of (image) data, rather than something belongs to a subject. We provided codes for atlas individualization though.

atlas/
    atlas_description.json
    tree_view.json
    atlas/
        parcellation/
        probmap/
        funconnectome/
        struconnectome/
    derivatives/

We do have one concern regarding BEP-Y. We wonder whether our idea meets the BIDS specification, because we replaced the subjects' neuroimaing data by atlas data, which might be in conflict with BIDS specification and most other BEPs @tsalo.

In summary, we propose to consider the two BEPs separately due to their distinct focuses, but with overlapping aspects. We would like to change the name of BEP-Y to something like AtlasLibrary-BIDS. For sure, we are open to further discussion. Thank you.

[PeerHerholz]

Hi @flyxiaye,

thank you very much for your response and thoughts.

Thank you for your prompt response @tsalo, @jdkent, @PeerHerholz. Unfortunately, we didn't notice the existing BEP. We have been working on this over a year. Although we kept an eye on this topic at the beginning, but failed to do so in the last few months. We have read through the BEP in #1281 submitted by @jdkent, it's no doubt that both BEPs have many in common and a wonderful work has been done.

No worries! With BIDS expanding as in the last couple of years and so many things happening in its ecosystem, it's easy to miss things for all of us. Thanks, we are happy to hear that our draft and the entailed ideas appear to make sense.

In our point of view, however, there are significant differences between the two BEPs. To facilitate discussion, we would call the one by @jdkent as BEP-J and ours as BEP-Y, respectively. To be concise, BEP-J is about atlas individualization for image analysis, therefore, it's subfolders under each subject; while BEP-Y is about describing atlases in a 4D space defined by spatial resolution, time point, species, and data modality, or maybe called "the atlas of atlases", or a database/library of atlases.

The first three dimensions are (somehow) continuous, while the fourth is discrete. Apparently, other dimensions, such as authors, algorithms and methods, could be used to define the multidimensional space, while we reckon these four are the most useful, at least currently and in the foreseeable future.

I agree that there are prominent differences between our drafts. However, I would like to outline that our draft doesn't focus on individualized atlases, ie applications of atlases in a given participant's native space but is comprised of a set of core principles when describing and utilizing atlases:

1. we approach an atlas as a set of nodes/parcels and their relationship among each other, ie. edges (for example their distance) which would include the following files:

• _desg/_pseg.nii.gz -> the atlas
• _desg.tsv -> nodel/parcel information (e.g. label, network association, etc.)
• _desg.json -> atlas metadata (e.g. authors, species, source data, etc.)

2. an atlas can be stored at the pipeline/derivative level and/or the subject level, depending on the use case

• if the same atlas was used for all participants without modification then it's stored at the pipeline/derivative level, e.g. this example
• if an atlas was modified from it's original state before being applied to a given participants (e.g. a spatial transformation into participants native space) then it would be stored at both the pipeline/derivative and subject level, e.g. this example
• if an atlas was derived from a given participant's data, ie a subject-specific parcellation, then it would only be stored at the respective subject level, e.g. this example

I like the idea of approaching the broad landscape of atlases via defining a set of features as proposed by you. However, I think most of them might already be captured/described by BIDS, ie. spatial resolution and time point via respective keys in the filename, as well as json sidecar files and species and data modality via keys in the json sidecar files. The latter would also entail the other dimensions you mentioned. With that distinct entities can be correspondingly mapped out (e.g. multiple different atlases, as we tried to outline here).

Thanks again, looking forward to discussing everything further!

Cheers, Peer

[PeerHerholz]

Hi everyone, @flyxiaye & @bids-maintenance,

we were wondering if you would be up for meeting to discuss the further development of the atlas-related BEPs, as we aim to start the next step of the BEP development process (ie getting an official number) and share our draft with the community in the next couple of weeks. However, before that, we would of course like to talk to everyone involved concerning how we can consolidate the current situation, where efforts can be combined, etc. .

It would be great to hear from you.

Cheers, Peer

[eduff]

It seems to me that these projects needs to be at least tightly aligned - they seem to be coming at the some challenge from different starting points: Yang et al (Y): starting with the organisation of complete canonical atlas file sets with an MRI focus (Kent et al) J: starting with the standardisation of atlas-based labelling for node data, with a more multimodal perspective and accommodating more minimal subject-specific atlases and variants. @flyxiaye 's point above is relevant - whether considering the canonical atlas as something similar to raw data is a helpful construct. Atlas definitions should clarify their relationship to labelling schemes for segmentations already defined in BIDS.

[flyxiaye]

Hi everyone, @flyxiaye & @bids-maintenance,

we were wondering if you would be up for meeting to discuss the further development of the atlas-related BEPs, as we aim to start the next step of the BEP development process (ie getting an official number) and share our draft with the community in the next couple of weeks. However, before that, we would of course like to talk to everyone involved concerning how we can consolidate the current situation, where efforts can be combined, etc. .

It would be great to hear from you.

Cheers, Peer

@PeerHerholz & @bids-maintenance. Thanks for your invitation! Perhaps we can have the meeting in January 28, Saturday this week and the specific time can be further disscussed, for the reason that these days we are celebrating the new year. Looking forward to meeting with you!

[PeerHerholz]

Hi @flyxiaye,

thx for the reply.

Sorry, I didn't intend the message to sound like this should happen this week and/or create stress. I was thinking about maybe later next week or the second week of February and sending around a little meeting scheduler.

Happy new year!

[flyxiaye]

Hi @PeerHerholz,

Sure, it is decided by you, and we prefer the next week in any time. If you have decided the meeting time, please send to me freely. Waiting for you reply.

Thank you!

[PeerHerholz]

Hi @flyxiaye,

coolio. I created a little survey to find a time that fits for everyone, you can find it here (it should automatically convert to your timezone). It covers the end of this/all of next week.

Looking forward to meet with y'all.

Cheers, Peer

P.S.: Also tagging @jdkent & @bids-maintenance.

[sappelhoff]

@PeerHerholz the @bids-maintenance account that you are tagging is a bot user :-)

if you want to tag maintainers, please use the "GitHub Org Team" --> @bids-standard/maintainers

[flyxiaye]

Hi @PeerHerholz,

We all have filled out the time form and are waiting for your decision. By the way, there is an error in the form that the user 'changshuo wajg' is a typo and actually we have four members.

Looking forward to meet with y'all.

Thank you!

[PeerHerholz]

Hi everyone,

thx @sappelhoff, sorry, completely forgot about that!

Thx @flyxiaye and colleagues for filling out the form. @jdkent and someone from @bids-standard/maintainers: could someone of you maybe also join?

Cheers, Peer

[Remi-Gau]

Added my name in the when2meet but I will be traveling during most of the likely dates, so I will most likely attend when traveling by train, if I can make it at all.

[tsalo]

I've also filled in the when2meet, but given my time zone I doubt my available times will line up with everyone else's.

[PeerHerholz]

Hi folks,

thx @Remi-Gau & @tsalo for adding your availabilities.

Based on the current state, it seems that Wednesday, February 8, 10 AM EST/4 PM CET (sorry @flyxiaye, I don't know your timezone) would work for a group of people that includes someone from all sides/teams (@jdkent and I from our atlas BEP, Changshuo and Steven from their atlas BEP and @Remi-Gau and @tsalo from the maintainer side). Thus, I would vote for using this data/time.

Would that work/be ok for everyone?

Cheers, Peer

[Remi-Gau]

I will be in a train, so can't make promises on the stability of my connection.

[flyxiaye]

Hi @PeerHerholz ,

We agree that the meeting will hold in Wednesday, February 8, 10 AM EST/4 PM CET/11 PM CST. All four members of us will attend the meeting.

[jdkent]

this works for me, thanks for organizing Peer!

[PeerHerholz]

Hi everyone,

thanks for confirming your attendance, looking forward to this!

I created a jitsi meeting here, please let me know if that works for everyone. I'm happy to set up a different meeting tool, e.g. zoom or so.
Otherwise, see you tomorrow!

Cheers, Peer

[flyxiaye]

Hi @PeerHerholz,

We have received the jitsi meeting links, looking forward to this! In addition, to ensure the meeting, can we have the zoom as a backup?

Thank you!

[PeerHerholz]

Hi @flyxiaye,

yeah, sure thing. I'll prepare one and update here if the jitsi meeting doesn't work.

Cheers, Peer

[Remi-Gau]

Sorry could not make it today. Travelling and online meeting do not work well together.

[PeerHerholz]

Hi everyone,

here's a little update.

We meet yesterday and had folks from both BEPs and the maintainer group attending. Thanks again to everyone!
During the meeting we discussed the current state as well as potential future developments and would like to give a brief respective overview.

The two BEPs

Following the comments and information provided in this thread, we agreed that the two BEPs comprise different points of view and aim to achieve/implement distinct goals that are yet complementary in the bigger picture.
The BEP from @flyxiaye and colleagues targets the characterization of atlases via a holistic set of features, ie an atlas of atlases, and might lean more towards comparable resource efforts such as templateflow.
The BEP from @jdkent, myself and colleagues rather targets how atlases should be stored and provided as part of BIDS (derivatives), ie what files and their type, structure and metadata.

Further development

Concerning the further development, we discussed the following plan: the respective efforts will continue and collaborate where possible. For example, @flyxiaye and colleagues will continue to work on a well-characterized and indexable collection of atlases and @jdkent, myself and colleagues will fetch atlases from this resource to holistically test and adapt our specification. This furthermore entails, @flyxiaye and colleagues updating @jdkent, myself and colleagues concerning important meta-data, as well as the other way around updating concerning naming patterns and file types.

@flyxiaye, @jdkent and @tsalo: please feel free to add things that I forgot.

Additionally, we also would like to open up the discussion for more feedback. Of course from the community but specifically from people involved in comparable efforts (e.g. @oesteban, @effigies... (sorry for the brash tag)).

Cheers, Peer

[CPernet]

the steering group is now aware of this issue/complementarity - would anyone want to present this information at our next meeting and see where, if needed, we need to weigh in? or all is 'resolved' now in terms of who does what?

-- in any case, one small thing, but key in the future spec, would both BEP be merged under 'atlases' or do we need separate names? I tend to lean toward the second case as a user that builds atlases will want something different from a user that wants to share the atlasing decomposition/recomposition of his/her data (if I understood the above discussion)

[PeerHerholz]

Thx for your input @CPernet!

the steering group is now aware of this issue/complementarity - would anyone want to present this information at our next meeting and see where, if needed, we need to weigh in? or all is 'resolved' now in terms of who does what?

That would be great and I can definitely try my best to make that work, ie attending the next meeting! I think we (as in both BEP teams) are clear on how to proceed but it would be great to also get feedback from y'all re this.

-- in any case, one small thing, but key in the future spec, would both BEP be merged under 'atlases' or do we need separate names? I tend to lean toward the second case as a user that builds atlases will want something different from a user that wants to share the atlasing decomposition/recomposition of his/her data (if I understood the above discussion)

In this discussion and the meeting on Wednesday, we also leaned toward the second option as both BEPs aim to do different things but are complementary. We also talked about how the BEP of @flyxiaye and colleagues might be more related to a BIDS resource like e.g. templateflow given its database and characterization focus.

[melanieganz]

Can we have a summary of the current status of this? As far as I understand it's now all merged in the atlas BEP0038, correct?
This PR#1579 might also be of interest for people, since it advocates for re-defining the current atlas entity in order to open up space for a re-definition through BEP038.

It also highlights inconsistencies in the concept of an atlas being defined twice in the spec right now.

[effigies]

Closing in favor of #1281.