BEP for dimensionality reduction-based networks

[PeerHerholz]

Your idea

Hi @bids-maintenance & everyone,

I hope you're doing fine.

This issue is meant to track/gauge interest and progress for a specification focusing on dimensionality reduction-based networks, e.g. functional networks based on ICA/PCA, structural networks based on covariance, etc. . It originated as part of the BIDS connectivity extension(s) project during the project's first workshop last September. Given its intended scope we aim to collaborate with the majority of the modality-specific, model, as well as other connectivity BEP teams.

The team is currently working on a draft here and we plan to have a meeting discussing the draft at the end of January (I'll update here once we have a date & time).

It would be cool to get all your ideas and feedback on this!

Cheers, Peer

[PeerHerholz]

Hi @bids-standard/maintainers,

as we aim to share our draft with the community to receive and integrate feedback soon, we would like to ask if it would be possible to move our BEP to the next stage. More specifically, this refers to step 5 of the BEP development guide, ie making the BEP official and obtaining a number. We followed and conducted steps 1-3 and would now like to access if the requirements for step 4 were fulfilled and if not, what would be missing to achieve this.

If you have any questions, please don't hesitate to ask. We're looking forward to working with you on this.

Best, Peer

[PeerHerholz]

Hi everyone,

I just wanted to follow up on my earlier message: would it be possible to evaluate if the requirements for step 4 were fulfilled and if not, indicate what we would need to do to achieve this?

It would be great to hear from you.

Best, Peer

[sappelhoff]

Hi @PeerHerholz, thanks for the patience -- I am not sure I'm the correct person to judge this, but to obtain a number you may open a PR to the bids-website repo by editing these files. We can then discuss in that PR and potentially approve and merge it, and then you'll have the official number :-)

• https://github.com/bids-standard/bids-website/tree/gh-pages/_bep_collection
• https://github.com/bids-standard/bids-website/blob/gh-pages/_data/beps.yml

[PeerHerholz]

Hi @sappelhoff,

thanks for getting back to us and the information. We opened a respective PR.

Looking forward to the discussion!

Cheers, Peer

[PeerHerholz]

Hello @bids-standard/maintainers, @bids-standard/steering & everyone,

I hope you're doing fine.

We (@tincala91, @DrCyPhi, @anibalsolon, @dorahermes, @adelavega, @rwblair, @francopestilli and others) continued to work on BEP039 - Dimensionality reduction-based networks. We would like to finalize Step 9 of the BEP development process: Incorporate the feedback and strive for consensus. . Thus, I thought about creating a dedicated issue within which we can track what is still needed in order to do so.

If y'all could have a look at the draft again and share your thoughts re the current status and if something/what definitely still needs to be addressed, that would be great! I'll start a list below and will keep editing it based on your comments.

Needs to be addressed

• [x] add single subject EEG ICA example
• [x] clean up EEG related paragraphs

Would be cool to address but not necessary

Thanks so much again for all your help and effort, we highly appreciated it.

[DrCyPhi]

Peer,

A little hectic here on my end now. I will try to get back perhaps tomorrow if that is okay.

Best Regards, Cyrus

---

From: Peer Herholz @.> Sent: Wednesday, August 30, 2023 10:24 AM To: bids-standard/bids-specification @.> Cc: Cyrus Erik Eierud @.>; Mention @.> Subject: Re: [bids-standard/bids-specification] BEP for dimensionality reduction-based networks (Issue #1378)

Hello @bids-standard/maintainershttps://github.com/orgs/bids-standard/teams/maintainers, @bids-standard/steeringhttps://github.com/orgs/bids-standard/teams/steering & everyone,

I hope you're doing fine.

We @.***https://github.com/tincala91, @DrCyPhihttps://github.com/DrCyPhi, @anibalsolonhttps://github.com/anibalsolon, @dorahermeshttps://github.com/dorahermes, @adelavegahttps://github.com/adelavega, @rwblairhttps://github.com/rwblair, @francopestillihttps://github.com/francopestilli and others) continued to work on BEP039 - Dimensionality reduction-based networkshttps://docs.google.com/document/d/1GTWsj0MFQedXjOaNk6H0or6IDVFyMAysrJ9I4Zmpz2E/edit?usp=sharing. We would like to finalize Step 9 of the BEP development processhttps://bids-extensions.readthedocs.io/en/latest/guide/#when-and-how-to-start-a-bids-extension-proposal: Incorporate the feedback and strive for consensus. . Thus, I thought about creating a dedicated issue within which we can track what is still needed in order to do so.

If y'all could have a look at the drafthttps://docs.google.com/document/d/1GTWsj0MFQedXjOaNk6H0or6IDVFyMAysrJ9I4Zmpz2E/edit?usp=sharing again and share your thoughts re the current status and if something/what definitely still needs to be addressed, that would be great! I'll start a list below and will keep editing it based on your comments.

Needs to be addressed Would be cool to address but not necessary

Thanks so much again for all your help and effort, we highly appreciated it.

— Reply to this email directly, view it on GitHubhttps://github.com/bids-standard/bids-specification/issues/1378#issuecomment-1699288160, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGEEQJTOR7OGJOR7NXDCQALXX5ELNANCNFSM6AAAAAATWQDNCQ. You are receiving this because you were mentioned.Message ID: @.***>

CAUTION: This email was sent from someone outside of the university. Do not click links or open attachments unless you recognize the sender and know the content is safe.

[PeerHerholz]

Hi @DrCyPhi,

of course, no worries at all.

[dorahermes]

My main concern is that it does not capture a highly common use case of ICA on individual subject EEG data. It would be valuable if someone who has a lot of experience with EEG/ICA would have a look at it.

[DrCyPhi]

Dear Dora,

Apologize, I was supposed to append and correct the BEP39 EEG sections at HBM (my last part in BEP39) and did not get time until today to look at it. Just started to look at EEG and hope we may we get a couple of days to finish some more corrections in these EEG sections.

Best Regards, Cyrus

---

From: dorahermes @.> Sent: Sunday, September 3, 2023 10:22 AM To: bids-standard/bids-specification @.> Cc: Cyrus Erik Eierud @.>; Mention @.> Subject: Re: [bids-standard/bids-specification] BEP for dimensionality reduction-based networks (Issue #1378)

My main concern is that it does not capture a highly common use case of ICA on individual subject EEG data. It would be valuable if someone who has a lot of experience with EEG/ICA would have a look at it.

— Reply to this email directly, view it on GitHubhttps://github.com/bids-standard/bids-specification/issues/1378#issuecomment-1704319270, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGEEQJXRXDTAVGPMU5VSH63XYSHDFANCNFSM6AAAAAATWQDNCQ. You are receiving this because you were mentioned.Message ID: @.***>

CAUTION: This email was sent from someone outside of the university. Do not click links or open attachments unless you recognize the sender and know the content is safe.

[francopestilli]

@DrCyPhi Thank you for doing this.

[PeerHerholz]

Hi everyone,

thx @DrCyPhi and @dorahermes, I'll add it to the list!

[dorahermes]

Thank you @DrCyPhi !

[PeerHerholz]

Hi folks,

bumping this up again. What do you think re the current status of the draft? Should we schedule a meeting early next year to discuss and start the next steps?

Cheers, Peer

[PeerHerholz]

Hi folks,

I hope you're doing fine.

@francopestilli, @arokem, @dorahermes, @DrCyPhi, @CPernet, @tincala91, @bids-standard/maintainers & @bids-standard/steering (& everyone of course): I created a poll covering the next 2 weeks to find time for a 1h meeting to discuss the current state and future steps. You can find it here.

Thanks again.

Cheers, Peer

[francopestilli]

@PeerHerholz thank you for setting this up!

[PeerHerholz]

Hi everyone,

thanks so much for taking the time to vote.

Based on the responses, it seems that next Tuesday, January 23, 5 PM CET, 10 AM CT, 8 AM PST works best. I sent everyone who voted (@dorahermes, @tincala91) an invite. If others want to join as well (@DrCyPhi can you maybe make it?), please comment here and I can add you. You can find the agenda here. Please feel free to add items you want to discuss.

Thank you very much again. We're looking forward to the meeting!

Cheers, Peer

[PeerHerholz]

Hi everyone,

thanks a lot for a very productive meeting yesterday.

Based on the things we discussed, we would like to ask @bids-standard/maintainers and @bids-standard/steering if we could schedule a meeting with you to talk about the current state and next steps. Specifically, this refers to moving on to the next stage, ie porting the draft to GitHub and adding examples.

I created a survey here to hopefully find a feasible time, covering the next 2 weeks.

It would be cool to hear from and meet with you.

Thanks again.

Cheers, Peer

[arokem]

Could we please schedule this to occur at an already-scheduled upcoming meeting of the steering group? We have one coming up on February 1st at 6 AM PT / 1500 UTC, which is within the time-frame you indicated. Does that time/day work for you, @PeerHerholz? @KimberlyLRay: do we have anything scheduled for this meeting? Or could we get this item onto the agenda for the upcoming meeting?

[PeerHerholz]

Hi @arokem,

thanks for the info! Yes, as far as I can tell now, this should work for me. @DrCyPhi and @tincala91: would you be able to join?

[tincala91]

Hi there,

sorry not feasible for me but I think it is best if you just go ahead with this meeting, so that we can get timely feedback 🙂

Arianna

---

Da: Peer Herholz @.> Inviato: mercoledì 24 gennaio 2024 15:50 A: bids-standard/bids-specification @.> Cc: Sala Arianna @.>; Mention @.> Oggetto: Re: [bids-standard/bids-specification] BEP for dimensionality reduction-based networks (Issue #1378)

Hi @arokemhttps://github.com/arokem,

thanks for the info! Yes, as far as I can tell now, this should work for me. @DrCyPhihttps://github.com/DrCyPhi and @tincala91https://github.com/tincala91: would be able to join?

— Reply to this email directly, view it on GitHubhttps://github.com/bids-standard/bids-specification/issues/1378#issuecomment-1908285211, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AR2CHB53ESOFGQUJRFXA5ZTYQENTZAVCNFSM6AAAAAATWQDNCSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBYGI4DKMRRGE. You are receiving this because you were mentioned.Message ID: @.***>

[PeerHerholz]

Hi @arokem and @kimberlylray,

I hope you're doing fine.

I wanted to ask if we could maybe briefly present the BEP during the next steering group meeting?

Thanks.

Cheers, Peer

[kimberlylray]

Hey Peer, We'd be happy to have you join! I sent a calendar invite to our next meeting on Feb. 22, 2024. The Steering group will meet 15 minutes early to discuss other business and please plan to join at the start of the hour.

[PeerHerholz]

Hi @cmaumet,

I was wondering how we should continue the discussion around parameters and provenance? Should we draft something in the GoogleDoc?

Thanks again.

Cheers, Peer

[CPernet]

following BIDS derivatives principles, I'd recommend having 2 approaches

• the lightweight descriptions.tsv that gives the parameter space but not provenance
• the BEP prov allowing to actually trace back exactly what was done

we tried to do that for eeg see https://docs.google.com/document/d/1PmcVs7vg7Th-cGC-UrX8rAhKUHIzOI-uIOh69_mvdlw/edit#heading=h.ruoibwsnpivw

[PeerHerholz]

Thanks. Just to reiterate: we would get rid of the "model".tsv and "model".json in favor of the descriptions.tsv that would entail the information we had in the prior as columns and rows, correct?

[CPernet]

yes that's the idea - but it has to be tested if that works for you.

[PeerHerholz]

Hi everyone (@dorahermes, @DrCyPhi, @tincala91, @CPernet and of course everyone else),

as we want to finalize this BEP asap, we would like to get a few roadblocks out of the way. Specifically, this refers to the "model" and "index" keys we have to find different names for, as both are convoluted and/or misleading/already taken. Could I maybe ask y'all if you have some ideas concerning this?

Thanks!

Cheers, Peer

[dorahermes]

Can you perhaps provide a more detailed description about what which terms 'model' and 'index' are intended to capture? (Will help for brainstorming, thanks!)

[PeerHerholz]

Hi Dora,

yes, sorry for not being more precise:

We initially used "model" as a key to indicate what kind of model was applied/run via a respective ID. For example, if you ran an ICA, it would've been model-ICA. However, as the term "model" is currently heavily discussed and mostly its usage discouraged, we should find something akin that would allow us to define what was applied/run on the data. IIRC, at some point "result" was discussed (@effigies, sorry brashly tagging you).

We initially used "index" as a key to indicate which component a file refers to in case files are saved not in 4D. For example, if you ran an ICA and the outputs are stored in 3D files, it would've been model-ICA_index-1. However, as index is already used for something else in BIDS (e.g. here), we should find something akin that would allow us to define which component a file refers to.

HTH and sorry again.

Best, Peer

[effigies]

I was not under the impression that model was discouraged, just its use as a directory for hierarchical organization (https://github.com/bids-standard/bids-specification/pull/1280#issuecomment-1490632674). To my mind, the main thing that would be potentially confusing for that entity is that you might have a case where you want to specify the model type (e.g., model-ICA, model-GLM, etc.) and another where all of your models are the same type and you want to give them specific names, (e.g. model-randomFx model-fixedFx). I don't think that kills the idea, just something to take into account.

I do think index-<index> is a bit problematic, since it is already a term we use for entity values, so doubling it up to also be an entity key is likely to lead to imprecision or to a lot of text to avoid ambiguity. Given that we have entities (echo, run, chunk) where the value is an index, if what we want to say is the 4th component, then something like component-4 would make sense to me. (We could potentially have a short form for component, like cmp-4). If you want something extremely generic, perhaps item-<index> could be defined to be something like "The index of an item in a collection of related files. The specific meaning of the index varies by context."

[PeerHerholz]

Hi @effigies,

thanks a lot for adding your feedback and ideas, that's highly appreciated.

I was not under the impression that model was discouraged, just its use as a directory for hierarchical organization (https://github.com/bids-standard/bids-specification/pull/1280#issuecomment-1490632674). To my mind, the main thing that would be potentially confusing for that entity is that you might have a case where you want to specify the model type (e.g., model-ICA, model-GLM, etc.) and another where all of your models are the same type and you want to give them specific names, (e.g. model-randomFx model-fixedFx). I don't think that kills the idea, just something to take into account.

Thanks. Ah, I see. The way I understood it was the model is generally problematic regardless of used as directory or entity name, as it's definition is rather complicated and convoluted. I don't have anything against atm but just wanted to address what folks discussed before. Re naming models: Yeah, we also discussed this and were wondering if some terms should be encouraged, ie a set of defined model types and their abbreviation/ID, or if folks should be allowed a bit more freedom as the model abbreviation/ID should be further explained in the corresponding metadata. The former option would be related to discussions in BIDS stats models and fitlins I think and at least for some models be possible.

I do think index- is a bit problematic, since it is already a term we use for entity values, so doubling it up to also be an entity key is likely to lead to imprecision or to a lot of text to avoid ambiguity. Given that we have entities (echo, run, chunk) where the value is an index, if what we want to say is the 4th component, then something like component-4 would make sense to me. (We could potentially have a short form for component, like cmp-4). If you want something extremely generic, perhaps item- could be defined to be something like "The index of an item in a collection of related files. The specific meaning of the index varies by context."

Thanks! That's what I thought. I think item-<index> would be a feasible option forward as it would general enough to also be useful for other things in BIDS as outlined by @arokem. WDYT @dorahermes, @DrCyPhi, @tincala91, @CPernet and of course everyone else?

Thanks again.

Cheers, Peer

[CPernet]

Given @effigies and @arokem comments, it seems thatmodel- is fine. As a side note, it also means that within BIDS this will have a very general definition as an entity that refers to an implicit (ICA) or explicit (ballstricks, glm) representation of the data (over any dimension).

@PeerHerholz In the BEP, index- indicates which component it is in the ICA model. Are there other cases for which `index—' is used? (for models, not entities). I cannot see other instances in the examples. thx

[DrCyPhi]

Agree the model entity is okay.

About the index- entity, which BEP39 has an example (sect 4.4, FSL Melodic) where it writes out independent components 3D nii-file by 3D nii-file (as opposed to have all independent components in a single 4D nii-file). If the entity has to change from index- to something else, I think @effigieshttps://github.com/effigies suggestions are good. I like "cmp-" over "item-", but okay with both if we move away from index-. -Cyrus

---

From: Cyril Pernet @.> Sent: Sunday, May 5, 2024 9:01 AM To: bids-standard/bids-specification @.> Cc: Cyrus Erik Eierud @.>; Mention @.> Subject: Re: [bids-standard/bids-specification] BEP for dimensionality reduction-based networks (Issue #1378)

Given @effigieshttps://github.com/effigies and @arokemhttps://github.com/arokem comments, it seems that model- is fine. As a side note, it also means that within BIDS this will have a very general definition as an entity that refers to an implicit (ICA) or explicit (ballstricks, glm) representation of the data (over any dimension).

@PeerHerholzhttps://github.com/PeerHerholz In the BEP, index- indicates which component it is in the ICA model. Are there other cases for which `index—' is used? (for models, not entities). I cannot see other instances in the examples. thx

— Reply to this email directly, view it on GitHubhttps://github.com/bids-standard/bids-specification/issues/1378#issuecomment-2094801645, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGEEQJXS4QIGYKE7FHWZY2LZAYUSRAVCNFSM6AAAAAATWQDNCSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJUHAYDCNRUGU. You are receiving this because you were mentioned.Message ID: @.***>

CAUTION: This email was sent from someone outside of the university. Do not click links or open attachments unless you recognize the sender and know the content is safe.

[PeerHerholz]

Hi @CPernet and @DrCyPhi (& everyone),

thanks for your feedback!

Cool, it seems that model as an entity is ok for folks. We will then keep it for now.

Re the index entity: as outlined by @DrCyPhi, we so far only used it for components not saved in 4D files. Great, item seems to be a feasible way forward.

I'll update the GoogleDoc respectively to see "how it looks". The prior version will, of course, be saved via version control.

Thanks so much again.

Cheers, Peer

[PeerHerholz]

Hi @bids-standard/maintainers,

after talking with @effigies during the Brainhack, I wanted to ask if it be possible to have a somewhat formal review/assessment of the current state of the GoogleDoc draft, so that we can then hopefully move things over to GitHub?

It would be cool to hear from you. Thanks.

Best, Peer