Non-parametric statistics

[cmaumet]

This is a work-in-progress, developed with @nicholst, to model non-parametric inference.

The proposed modifications are as follows:

• New attribute nidm:isParametric in nidm:Inference to specify whether parametric or non-parametric inference is performed.
• New optional entity nidm:NonParametricNullDistribution (used by nidm:Inference and only available if isParametric = true) with attributes: nidm:numberOfPermutations, nidm:exchangeabilityBlockSize (optional).
• New optional attribute nidm:varianceSmoothingFWHM in nidm:StatisticMap to specify the degree of variance smoothing for Pseudo-TStatistic.
• nidm:NonParametricSymmetricDistribution replaced by nidm:SymmetricDistribution in nidm:ErrorModel (as discussed at Non-parametric distributions ISA-tools/stato#29 and Non-parametric symmetric distribution ISA-tools/stato#31).

[nicholst]

Thanks @cmaumet. So have we defined a new type of statistic, the 'pseudo t'? (Which really should instead be called the 'Smoothed Variance t-test'

[cmaumet]

Thanks @nicholst, the new statistic term is now updated to SmoothedVarianceTStatistic. Once we have agreed on those changes we might want to check with STATO if this new term can be created there as well.

[cmaumet]

(Just rebased)

[cmaumet]

Created new terms for:

• TFCE Statistic: nidm:ThresholdFreeClusterEnhancement and nidm:EParameter and nidm:HParameter.
• cluster mass: nidm:clusterMass

[nicholst]

These nidm:EParameter and nidm:EParameter are quite specific to TFCE. Might they not be better labelled nidm:TFCE_EParameter and nidm:TFCE_EParameter or something?

[cmaumet]

We discussed this issue on NIDASH call on December 15th.

• We re-discussed the possibility to use nidm:NonParametricInference, nidm:ParametricInference (and similarly remove nidm:statisticType).
• @nicholst: add uncorrected and corrected p-value maps?

[nicholst]

@cmaumet : Yes! We should model uncorrected and corrected p-value as well.

[cmaumet]

This pull request has been rebased on master and the following updates included:

• Modelling of "non-parametric" analyses proposed in this PR, is now considered as an "extension" to nidm-results.owl. A separate folder extension/non_parametric was created in order to store scripts, examples and a new owl file called nidm-results_nonparametric.owl.
• nidm-results_nonparametric.owl imports nidm-results.owl and is using the same nidm namespace.
• a few fixes were introduced in the owl file (nidm:Statistic -> obo:statistic) and non-parametric example (add nidm:CoordinateSpace entity).

[jbpoline]

looking at it now, looks great -
@nicholst : strictly speaking the smoothed variance t is an actual t ? is the denominator an independent sqrt(X2) ?

[nicholst]

Good question @jbpoline. Your definition amounts to the strict parametric definition. In that vein the smoothed variance t-test is Gaussian divided by independent approximate chi-squared.

Colloquially, I think of any "estimate divided by standard error" as a "t ratio", and certainly in a nonparametic setting we don't need the parametric assertions.

I find "smoothed variance t-test" a very clear description, more informative than Andrew Holmes' preferred "pseudo t-test". But I'm up for suggestions they are more precise.

What do you suggest?

On Mar 30, 2015, at 6:09 AM, Jean-Baptiste Poline [email protected] wrote:

looking at it now, looks great -
@nicholst : strictly speaking the smoothed variance t is an actual t ? is the denominator an independent sqrt(X2) ?

—
Reply to this email directly or view it on GitHub.

[nicholst]

@cmaumet : What's the status of this PR... Are we waiting for resolution of the discussion from 2015? Or for another version / release candidate of NIDM-Results to be created?

[cmaumet]

Hi @nicholst! I think we only need to check that what is in here is consistent with our first prototype for SnPM (SnPM-toolbox/SnPM-devel#45). If @TomMaullin is up for it, we could also do the same for randomise, just to check that the proposed model fits our needs.

[nicholst]

Sorry for being slow but I'm trying to keep track of all of our NIDM-Results exporter work:

1. SPM: By @gllmflndn, in Matlab, writes out NIDM-Results graph in Turtle & JSON-LD serializations.
2. nidmfsl - By @cmaumet , in python, uses rdflib to write out Turtle & JSON-LD
3. SnPM: By @cmaumet, in Matlab, uses @gllmflndn's code to do analogous serializations (based on these nonparam-NIDM extensions)
4. JSON API: By @cmaumet, a specification of a JSON file giving minimal details to create a NIDM-Result export (again depending on this PR)
5. Randomise via JSON API: Initial effort by @TomMaullin & @AlexBowring
6. nidmafni - By ???, initially planned as clone of nidmfsl, now planned to use JSON API

So the question is, for SnPM: What should we do? Use this PR? Or switch to JSON API?

@cmaumet - Please feel free to edit this comment to correct details in-line.

[cmaumet]

Hi @nicholst! Sorry for the confusion!

So the question is, for SnPM: What should we do? Use this PR? Or switch to JSON API?

The JSON API is a intermediate (flattened) representation used by the exporters to more easily generate a NIDM-Results export. But, we still need to have the information represented in NIDM in the first place.

For non-parametric statistics:

1. This PR is used to extend NIDM to represent non-parametric statistics - then -
2. We can update the JSON API to add non-parametric attributes new terms (directly from the new NIDM terms) - then -
3. Finally we can update SnPM to generate NIDM-Results packs using the JSON API (via SPM NIDM exporter)

My suggestion was that before we merge this PR, we do a full cycle 1 -> 2 -> 3 as a sanity check that our model fits our needs. How does this sound?

[nicholst]

OK... so... how to action this... Are you poised to do this all? Or you taking the lead on 2, Tom MS w/ my help, 3?

[cmaumet]

Suggested action items/people:

• Add the non-parametric terms as a new section of the JSON API spec - @TomMaullin
• Check consistency of SnPM export with JSON API - @cmaumet (NIDM-Results export SnPM-toolbox/SnPM-devel#45)
• Code NIDM export for randomise and submit as a PR to NIDM FSL exporter - @nicholst & @TomMaullin
• Use JSON API in NIDM FSL exporter [this point was added following comment below] - @cmaumet

Is that okay? @nicholst, @TomMaullin

[nicholst]

@cmaumet : This is good for me: @TomMaullin are you clear what needs to be done?

My only question is: Does the NIDM FSL exporter currently use the JSON API? I.e. will @TomMaullin & my PR to the exporter use the JSON API?

[cmaumet]

My only question is: Does the NIDM FSL exporter currently use the JSON API? I.e. will @TomMaullin & my PR to the exporter use the JSON API?

That's a good point! The integration of the JSON API in the NIDM FSL exporter is still work-in-progress, and this is another todo point [now added above].

Maybe you can start by finishing the collection of all the required information in the randomise output folder while I focus on JSON API integration and we can reconvene afterwards?

[nicholst]

OK, this sounds like a plan.

[TomMaullin]

Hi @nicholst @cmaumet , yes this makes sense to me. Just to double check though, I should:

• Add the terms discussed in this PR to the Google doc for the JSON API
• Make a PR for Randomise on the nidmresults-fsl repository