"stat" entity

[Lestropie]

Mostly been considering this in the context of common derivatives, but might nevertheless be applicable here.

Consider the case where one wants to compute the mean EPI volume across an fMRI time series. One way to encode this would be to include a dedicated entity _stat-*, which indicates that there has been some scalar summary statistic computed along one axis of the data. One could consider mandating that some metadata field appear that nominates the axis along which that statistic was computed, though theoretically in the future this could be discoverable through provenance.

Where this might be applicable in BEP016 is in the ball-and-sticks model. There are some parameters for which a set of parameters per bootstrap realisation is provided, and others for which the mean across all bootstrap realisations is provided instead / in addition. Currently these two cases are somewhat clumsily disambiguated using the _desc- entity. Explicitly indicating that a mean has been taken along the bootstrap axis might be more accurate.

[oesteban]

@effigies I'm pretty sure this has been discussed in the functional derivatives front. What's the situation there?

[effigies]

We had a discussion over in poldracklab/fitlins#125. I haven't brought a proposal to the community, as I've been waiting on structural and functional derivatives to get merged first.

[effigies]

Summary: We've used _statmap suffix, and have several labels for a stat-<label> entity: effect, variance, t, F', p, z.

We also use some other ones for model assessment, and you can find them all here: https://gin.g-node.org/markiewicz/fitlins-tests/src/master/outputs/afni_smooth/node-subject/sub-01

[oesteban]

Any particular reason not to use a more general suffix (e.g., _param) instead of _statmap and then particularize that this map is a statistical map by the fact that the stat-<label> is present?

Rather than suggesting changes, I'm trying to learn of potential issues I haven't anticipated when proposing #68.

BTW. I remember this stat-<label> idea was discussed back in the day when the early BEPs were kicked off. Probably the time has blurred that initial impetus on the idea.

[Lestropie]

I think the content of the proposal here may have been inferred erroneously based only on the key of the proposed entity. My description has nothing to do with statistical inference or linear models. This is purely about computing some aggregate statistic along an axis of an image.

[oesteban]

Then I guess this proposal should be moved into common derivatives, correct?

[Lestropie]

If there's merit to the idea, then yes. Could do with a basic sanity check though, I'm not across all of the various goings-on in the BIDS ecosystem. Also wanted to think a bit about how to encode in filename entities vs. metadata (need to know both what statistic was computed and along which axis), and how that relates to provenance.

[effigies]

The just-completed workshop did adopt stat-<mean|std> as needed for molecular imaging maps. Thanks @Lestropie for linking this issue in. We'll need to consolidate these use cases, but I suspect we can reasonably give a generic definition for the term that allows for different use cases to use a different collection of values for clarity.

At least for the use cases I can think of the phrase "across volumes" (typically axis 4) is universally true for images and over ROI time series there's only one dimension to collapse across. For N-D images (bids-standard/bids-specification#197) with no this does seem like a potential concern, though I think we will need specific use cases to see if there are practical concerns.

[Remi-Gau]

I may be missing something (and sorry if I missed the discussion in Copenhagen) but does that not introduce some redundancy at least with the mean and std suffixes proposed by the functional bep12.

https://bids-specification--519.org.readthedocs.build/en/519/05-derivatives/05-functional-derivatives.html#functional-derivatives-maps

I am not opposed to have both but we need to make it very clear when to use each.

[effigies]

Yes, BEP12 will probably move those out of the suffix and into an entity. We'll need to think of what the new suffix should be. boldmap or mrmap (magnetic resonance map, to match PET's molecular imaging map mimap) spring to mind, but they may be terrible.