BEP Proposal: Atlas specification
Your idea
EDIT
github draft for current discussion: https://github.com/PESTILLILAB/bids-specification/blob/bep038/src/atlas.md
the google doc draft (deprecated in favor of the github draft) : https://docs.google.com/document/d/1RxW4cARr3-EiBEcXjLpSIVidvnUSHE7yJCUY91i5TfM/edit?usp=sharing
We currently aim to organize a meeting to further discuss the atlas-related BEP developments in #1379.
yo, count me in
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.
We are aware of the current status concerning the two atlas-related BEPs and one of our team (myself) will attend the next maintainers meeting to discuss if the outlined procedure is feasible. However, based on the so-far positive nature of the received feedback on this matter we nevertheless already wanted to ask regarding the further steps.
If you have any questions, please don't hesitate to ask. We're looking forward to working with you on this.
Best, Peer
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
@effigies you were there at the steering group meeting, and while we are still a little unsure of some specific aspects, I cannot see any reasons not to move on stage 4 - IMO +1
reposted from other thread:
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
Hi @sappelhoff,
thanks for getting back to us and the information. We opened a respective PR here.
Looking forward to the discussion!
Cheers, Peer
Hello @bids-standard/maintainers, @bids-standard/steering & everyone,
I hope you're doing fine.
We (@jdkent, @dorahermes, @francopestilli, @dlevitas, @poldrack, @CPernet, @melanieganz, @mnoergaard, @mathesong, @bendhouseart, @MaxvandenBoom and others) continued to work on BEP038 - Atlases. 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] PR #1579
- [x] Electrophysiology example/pointer
- [ ] "atlas" as "DatasetType", ie no modality tag(s)
- [ ] outline differences and files of BEP17
Would be cool to address but not necessary
Thanks so much again for all your help and effort, we highly appreciated it.
Thanks @PeerHerholz! And please check out the atlas PR and voice your opinions, so we ensure to address all concerns before moving forward.
Thanks @melanieganz! I/we keep monitoring the PR closely but so far we haven't noticed any major issues concerning the BEP. IMHO it's better to see what the PR leads to and then adapt the BEP respectively as this would greatly enhance adaptation and streamline the process (I think for the BEP this would most likely mean smaller changes, ie changing some definitions and naming patterns).
Hi everyone,
given that #1579 was merged, I think we can proceed with finalizing the draft.
Could I please ask everyone, the moderators/leads (@eduff, @jdkent) and contributors (@dorahermes, @francopestilli, @dlevitas, @poldrack, @CPernet, @melanieganz, @mnoergaard, @mathesong, @bendhouseart, @MaxvandenBoom, @dlevitas) to have another look at the BEP and indicate problems that should be addressed before we're moving forward (except the ones listed above)?
Thank you very much for your continued supported, we highly appreciate it.
Cheers, Peer
- [x] PR #1579
- [ ] Electrophysiology example --> given the scope, we said no need of that - correct?
- [ ] "atlas" as "DatasetType", ie no modality tag(s) --> I still think we need to constrain a little more the
_*map.[ext]proposal but also we should move along with it to progress
Thx for the reply and comments @CPernet!
Electrophysiology example --> given the scope, we said no need of that - correct?
Sure thing, we can remove it for the time being and add one if needed.
"atlas" as "DatasetType", ie no modality tag(s) --> I still think we need to constrain a little more the _*map.[ext] proposal but also we should move along with it to progress
I'm actually not sure if #1602 applies here, ie for atlases, or did you mean PET-related things more generally? However, I agree that we should try to move forward.
@melanieganz I added the needed discussion re BEP017 files to the list.
@melanieganz and @CPernet, I was trying to come up with an approach to exclude BEP017-related files in this BEP for the time being but am not sure how to implement this best. We could simply ignore them, knowing that we will introduce/add them later, ie once BEP017 is through but I wanted to ask for feedback re this. WDYT?
is that the files to check? PR are fine but a pain to edit, can you invite people to your fork instead
Hi @CPernet,
sorry for my unclear message. I was referring to the _relmat files that we aim to introduce via BEP017 but already use in this BEP to denote e.g. spatial distance between nodes of an atlas.
?? @melanieganz and I were wondering about community feedback -- posting the google doc to the community?
Hi @CPernet,
the google doc was shared earlier this year and promoted at different events (e.g. conferences and workshops). Are you suggesting to make another call for feedback?
Cheers, Peer
well no one else but 'us' look at it, and that's a little problematic -- nothing says we can keep working on the markdown, but another public email would be good IMO
re good your point about relmat -- sine we want this BEP first, we have to define it here.
can you point me to the markdown doc? do you need help - it is an important extension for Open Neuro PET so @bendhouseart can definitively spend time on that
Hi Cyril,
well no one else but 'us' look at it, and that's a little problematic -- nothing says we can keep working on the markdown, but another public email would be good IMO
yeah, I would be cool to get more ideas and feedback. However, I'm not sure how likely this is given the BEPdevelopment process so far, of this and other BEPs. It seems to be the case that the development of most BEPs is done by the group of folks initially proposing the BEP and then supported by the steering group/maintainers and adjacent folks. We're currently brainstorming ideas to address this and make the BEP development process more streamlined (ie find ways to engage more folks and don't get stuck in a waiting for feedback-loop).
re good your point about relmat -- sine we want this BEP first, we have to define it here.
So, introducing the files here but outlining that they're part of BEP017 (and thus could change respectively)? I think @melanieganz proposed a different solution (IIRC, sorry if I didn't).
can you point me to the markdown doc? do you need help - it is an important extension for Open Neuro PET so @bendhouseart can definitively spend time on that
We're still working on the Google Doc, as we want to follow the BEP development guidelines as closely as possible. Ie, moving only to GitHub and markdown once the draft is considered mature enough.
P.S.: Sorry for closing and re-opening the issue, I hit buttons by mistake.
Yes - let's not get stuck in the waiting loop ... I say let's fork the repo and start the markdown. In parallel, send another community email JIC.
Hi folks,
as we would like to bring this BEP to the next stage of the development process, ie moving it to GitHub, we would like to
- address the, currently, final discussion point, ie files related to
BEP017(@melanieganz WDYT?) - afterwards "freeze" the draft of the BEP and get feedback from the maintainers and steering group re if we can advance
The second point will also include another announcement over the mailing list and social media to ask others for feedback. Please let us know if you don't agree with this plan.
Cheers, Peer
Dear @PeerHerholz,
sorry, for leaving you hanging, I simply missed this thread.
So regarding the files related to BEP017 (see below your earlier comment), I would vote for not mentioning them in the atlas BEP at all. They are no introduced yet in the spec and otherwise we would have to wait for BEP017 before merging the straightforward and basically relatively finished BEP038. So I would remove them for now and then mention in BEP017 that files can be saved according to the atlas spec and give examples there. And then one can always later on make a minor change and add more atlas examples once BEP017 is finished and merged.
I just think it's a bad idea to keep holdign the straightforward atlas BEP that goes way beyond BEP017 back.
So remove those, freeze draft and get a date with the maintainers and afterwards steering group scheduled.
The relmat files seem fairly well defined (for their use case) in the atlas doc - does it make sense just to remove references to the BEP017, if needed, but keep the files in the Atlas spec?
I agree, defining relmat is needed and fine. Simply not referring to BEP17 is a simpler solution allowing to keep all examples.
Hi everyone,
Thanks for your feedback.
I have no strong preference for either option (although I slightly prefer @melanieganz's proposal). Should we have a quick vote here or is there another way to decide this?
Best, Peer
I agree, defining relmat is needed and fine. Simply not referring to BEP17 is a simpler solution allowing to keep all examples.
I concur!