Current state of the BEP (NOT FOR MERGING)

[Lestropie]

This is a replacement of #6 as the BEP is being reinvested in.

The PR is not for merging, but to show the current state of the difference between the BEP and an up-to-date master of the BIDS specification.

[codecov[bot]]

Welcome to Codecov :tada:

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered :open_umbrella:

[arokem]

Looks like there are still a lot of unrelated things even after merging #78 in here.

[arokem]

Ok - now merged with the specification master branch, this is (for now) the actual diff against the specification.

[arokem]

Updated with current master branch on the upstream fork of the spec.

[francopestilli]

@Lestropie @arokem after this is approved, can we please merge this into the main spec? @effigies

[arokem]

I believe that next steps are:

1. Review and eventually merge #92 into this PR. I am in the midst of a review of that one, which I hope to complete today.
2. Move this branch into a PR against bids-standard/bids-specification, so that we can hash out some of the remaining questions (see https://github.com/bids-standard/bids-bep016/pull/92#issue-2264977772) in that broader format.
3. After iterating there and coming to consensus, we would still need to complete all the work on the BEP, before it can be merged into the spec. The next two steps are: (a) Examples and (b)Schema. The BEP cannot be considered ready to merge before these steps are completed (see this page for details).

Maybe you were referring specifically to item 2 above when you said "merge into the main spec"?

[francopestilli]

Ok. Thanks let me know if I can help with the review

[Lestropie]

• Before actually constructing a PR, I think we need to go through the full Issue list. Some items can be deferred for inclusion after the first version of the extension, that's fine, but we need to explicitly flag such, whereas anything that's a requisite decision about a feasible first version needs to be resolved. I expect the maintainers / steering committee wouldn't like receiving an extension proposal where there's a lot of ambiguous outstanding Issues.

• For the examples, the existing data appear to be exclusively raw data (ie. no derivatives), and the README file explicitly states that it corresponds to raw data. The latter is maybe slightly ambiguous as they could be using "raw" to refer to data files in comparison to metadata files, as opposed to raw vs. derived. I'm interested to know if the "common derivatives" extension included providing example data. In the absence of such, we'd need to discuss with maintainers / steering committee about whether example derivatives should be going into the same examples repository vs. a different repository.

[francopestilli]

Hi @Lestropie it is my understanding that the full issue list cannot be addressed as it goes beyond the scope of the PR as it requires changes to BIDS. I proposed constructing the PR and discussing what is needed given what BIDSbis now and discussing the other issues in the context of BIDS 2.0. we are 4 years in in some major issues without working solutions. I think it is fair to ask to wait for BIDS 2.0 for your major requests.

[arokem]

I just merged the upstream master branch into this one, so this is in sync with bids-standard/bids-specification

[arokem]

IIUC, we need to resolve this discussion: https://github.com/bids-standard/bids-bep016/pull/104/files#r1605423106, and after that we can convert this to a PR against bids-standard/bids-specification:master. Is that others' understanding as well? Do folks want to weigh in on that terminology discussion? @francopestilli : do you have any thoughts on nomenclature for l/lmax?

[Lestropie]

A PR without #71 and with no exemplar data generated via #23 would IMO be laughed off. You can't demand that the community format their data to your decree whilst literally never having done it yourself. Please give me time to generate a BIDS App to generate and save the derivatives currently exemplified in the specification document, so that they can be moved from there to bids-examples. I had to deal with the reference frame handling issues first.

[PeerHerholz]

Hi @Lestropie,

concerning this, I started working on a respective BIDS App a while ago: bids_bep16_conv. It's a fully working BIDS App and we would only need to update the output formatting to conform to the current up-to-date version. Thus, if you would consider this feasible instead of starting a new BIDS App, I'm happy to help! No worries of course if not, e.g. you would prefer a different implementation, etc. .

Cheers, Peer

[Lestropie]

My comment was on the premise that the converter was being restricted in scope to exclusively conversion of pre-generated model fitting outputs, in which case another tool would be required to run the fitting then the conversion. Been a long break between bursts so certain details will still be a bit fuzzy. If in its current state that tool does both fitting and conversion, then that's the obvious starting point; but as per https://github.com/PeerHerholz/bids_bep16_conv/issues/7 longer term we'll want to think about separation of those two steps.