Generic export from minimal json file

[cmaumet]

This PR refactors the SPM NIDM exporter and divide the code in two functions:

• spm_results_nidm.m: Gather all the informations form the SPM output directory and store them as a minimal NIDM-Results json file
• spm_nidmresults.m: Create a NIDM-Results pack from any minimal json file. This function is generic and can be reused by other Matlab-based tools to create a NIDM-Results export.

This will facilitate the creation of new exporters (e.g. for SnPM, cf. https://github.com/nicholst/SnPM-devel/pull/45).

@gllmflndn: how do you feel about those changes? Any feedback is very welcome! You can update the PR directly if you want to or just post comments here. Thank you!

[cmaumet]

Hi @gllmflndn,

I have successfully tested this code in conjunction with SnPM (https://github.com/nicholst/SnPM-devel/pull/45) and added the following updates:

• use of camel case for OBO and NeuroLex terms (d9d4c33) in agreement with Camel case preferred prefixes from external ontologies nidm-specs#416.
• equivalent thresholds are considered as optional and the exporter runs even if they are not available in the minimal JSON (fc50776)
• use scr (instead of src) as prefix of the https://scicrunch.org/ namespace (510fff6)

Also, I wanted to get your feedback on the following:

• Shall we rename spm_nidmresults.m in spm_nidmresults_export.m or spm_nidmresults_generic.m to avoid confusion with spm_results_nidm?
• I had an issue with the generation of the design matrix image as discussed with @nicholst in Generic export from minimal json file #44 (comment)). Do you think we could find a way to handle this problematic use case? Or do you think we can ignore it?
• In Vancouver, we discussed removing the NIDMResultsExporter_softwareVersion from the minimal JSON API to have this value filled in by the library that translate the minimal JSON into a NIDM-Results. Are you still in favour of this? Let me know and I can create the update accordingly.
• Regarding the update of URI for the crypto namespace (Test exports with SPM12 r6906 #42), as this update breaks backward-compatibility, do you think we could wait until we have released the next major release of NIDM-Results?
• When running the tests, I have noticed that the structure used to describe groups in spm_results_nidm.m ("groups.N", "groups.name") is different from the one generated by spm_cfg_results.m ("nsubj", "label") . Is this an inconsistency or am I missing something? Or maybe your dev version of spm_cfg_results.m has been updated since spm_cfg_results.m 6896 2016-10-03 16:53:31Z guillaume?

Thank you in advance! Hopefully once we have solved these, the code will be ready for you to integrate in SPM.

[gllmflndn]

Hi @cmaumet, thanks for all your work here. I'd be happy to go through this and integrate the changes in SPM: are there extra things to consider in the meantime? Can we now run all of the tests online, since #46, it would help a lot?

[cmaumet]

Hi @gllmflndn! Great! Thanks! I'm working on rebasing this update on master and will let you know as soon as it's ready (I had some conflicts related to integration with #47).

[cmaumet]

@gllmflndn: I have an issue with our spm_group_mfx test case. There are more (i.e. 4 instead of 2) regressor names extracted from the design matrix than beta maps in the results folder. Is this behaviour as you would expect for such analysis?

$ ls ./test/data/nidmresults-examples/spm_group_wls/mfx | grep beta
beta_0001.nii
beta_0002.nii

$ matlab -nodisplay
>> addpath('~/Softs/spm12/')
>> load('./test/data/nidmresults-examples/spm_group_wls/mfx/SPM.mat')
>> SPM.xX.name

ans =

  1×4 cell array

    'contrast 1 parameter 1'    'contrast 1 parameter 2'    'contrast 2 parameter 1'    'contrast 2 parameter 2'

>> 

In the SPM exporter code, I was relying on the fact that we would always have one regressor name per beta. Do you think this is something we could also have for MFX analyses in SPM? Thanks!

[cmaumet]

@gllmflndn: the code is now rebased ready for your to go through. Let me know how the integration goes. Thanks!