To be updated in the model after the Hackathon

[cmaumet]

• [x] Remove "Level" in "xxxLevelStatistic" in FSL ground truth

See also ni-/ni-exportForFSL#1

[cmaumet]

Agreed with @jbpoline, @gllmflndn, @nicholst and myself.

• [x] coordinateSystem -> worldCoordianteSystem
• [x] dimensions -> dimensionsInVoxels
• [x] coordinate1InUnits -> coordinate1
• [x] coordinate1 (in FSL ) -> fsl:coordinate1InVoxels (in the definition specify if origin is 0 or 1). 0 is nifty spec.

[cmaumet]

Discussed with @chrisfilo (and @gllmflndn separately). For the query on StatisticalMap to be more general we could go back to have an entity of type nidm:StatisticalMap and then have an attribute to specify the type of statistic (same problem with Inference and ContrastWeights). Otherwise we need a different query for TStatisticalMap, FStatisticalMap, OneTailedInference, TwoTailedInference... Or having multiple prov:type attributes?

To be discussed with @satra and @nicholsn: is it possible in a SPARQL query to take into account the hierarchy of classes, i.e. query for any type of nidm:StatisticalMap (parent of TStatisticalMap, FStatisticalMap)?

[cmaumet]

Also discussed with @chrisfilo:

• Noise smoothness, could we have a cross-software attribute (in the nidm namespace)?

[nicholst]

Crux of the debate on what's common (nidm:) vs what's software-specific. As FSL and SPM actually use different methods to estimate FWHM, I'm for keeping them separate.

[cmaumet]

• [x] SPM export tool: rename nidm:coordinateSpace in nidm:atCoordinateSpace: @gllmflndn

[dbkeator]

Regarding nidm:StatisticalMap, I completely agree. I think you can use the Propery Path feature of SPARQL 1.1 to essentially do recursive queries http://www.w3.org/TR/sparql11-query/#propertypaths or follow paths in the graph which I believe would handle hierarchical relations between classes.

[dbkeator]

Regarding noise smoothness, I agree with Tom that we probably have to account for differences there between software packages. Part of our contributions to the field will certainly be in identifying which of the entities (attributes, etc) are actually software specific and which are general across packages.

[khelm]

I agree, and this is one of the benefits to having definitions, right? And a big benefit since it's not always understood by everyone what the modules are doing under the hood. Karl

Regarding noise smoothness, I agree with Tom that we probably have to account for differences there between software packages. Part of our contributions to the field will certainly be in identifying which of the entities (attributes, etc) are actually software specific and which are general across packages.

---

Reply to this email directly or view it on GitHub: https://github.com/ni-/ni-dm/issues/68#issuecomment-45360491

Karl Helmer, PhD Athinoula A Martinos Center for Biomedical Imaging Massachusetts General Hospital 149 - 13th St Room 2301 Charlestown, MA 02129 (p) 617.726.8636 (f) 617.726.7422 helmer@nmr.mgh.harvard.edu

The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

[cmaumet]

Discussed with @nicholsn yesterday afternoon.

In order to query on StatisticalMap directly we could create a lightweight ontology.

An then:

1. Infer new triples (e.g. using protege or the OWL-RL Python library)
2. Query on the "augmented" set of triples

or

1. Create a query in two steps:

?stattype subClassOf nidm:StatisticalMap
?mapid a ?stattype

[nicholst]

Looking forward to getting our terms into an ontology, but for the specific issue of TStatisticalMap vs StatisticalMap w/ attributes, I'm all for the 'StatisticalMap'.

Here's an annoying question: Shouldn't it be "StatisticMap" instead of "StatisticalMap"?

[nicholsn]

@cmaumet: here is the python library for inferring triples: https://github.com/RDFLib/OWL-RL

@nicholst :+1: for using StatisticMap

[cmaumet]

Thanks @nicholsn!

[cmaumet]

@gllmflndn: just discussed with @satra. For the URIs (used as identifiers) we could have:

• a md5 of the file shasum for entities that have a prov:atLocation pointing to a file (ExcursionSet, StatisticalMap...);
• a UID for other instances.

[khelm]

I agree with "StatisticMap" rather than "StatisticalMap", because it is a map of a statistic. And having the general case with attribute rather than a specific case is the minimal-set way to go. Karl

Looking forward to getting our terms into an ontology, but for the specific issue of TStatisticalMap vs StatisticalMap w/ attributes, I'm all for the 'StatisticalMap'.

Here's an annoying question: Shouldn't it be "StatisticMap" instead of "StatisticalMap"?

---

Reply to this email directly or view it on GitHub: https://github.com/ni-/ni-dm/issues/68#issuecomment-45406619

Karl Helmer, PhD Athinoula A Martinos Center for Biomedical Imaging Massachusetts General Hospital 149 - 13th St Room 2301 Charlestown, MA 02129 (p) 617.726.8636 (f) 617.726.7422 helmer@nmr.mgh.harvard.edu

The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

[cmaumet]

Agreed during the Friday TF meeting (sub-group "NIDM Stats": @nicholst, @jbpoline, @chrisfilo, @gllmflndn and @tiborauer):

• [x] Terms: Convert the Google spreadsheet to an OWL file and upload on github.

Implementation:

• [x] Do not export the beta files from SPM and FSL export tools.
• [ ] Change the way URIs are generated. (cf. #109)

Data Model:

• [x] Changing “StatisticalMap” in “StatisticMap”
• [x] Changing “TStatisticMap” to “StatisticMap” with a “statisticType” attribute (and same comment for Inference)
• [x] Add mean image of input data.

Apps:

• [ ] Start working on a NIDM-Results viewer in javascript. (cf. #178)

Tests and validation:

• [ ] Add more queries as validation and unit tests. (cf. #178)
• [ ] Neurovault: read NIDM. (cf. #178)

[cmaumet]

Also, agreed at the Hackathon with @nicholst, @gllmflndn, @jbpoline:

• [x] Include a SetStatistic entity in FSL (to be able to use the same query across software) [crossed out as this is now not needed since #94 was merged]

[cmaumet]

Commented by @gllmflndn:

• [ ] Deal with SVC mask different from the filtering mask you can have at the level of the inference (cf. #157).

[cmaumet]

All un-ticked items are now under discussions in separate issues. I will therefore now close this one.