Closed cmaumet closed 10 years ago
Agreed with @jbpoline, @gllmflndn, @nicholst and myself.
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
)?
Also discussed with @chrisfilo:
nidm
namespace)?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.
nidm:coordinateSpace
in nidm:atCoordinateSpace
: @gllmflndn 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.
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.
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.
Discussed with @nicholsn yesterday afternoon.
In order to query on StatisticalMap
directly we could create a lightweight ontology.
An then:
or
?stattype subClassOf nidm:StatisticalMap
?mapid a ?stattype
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"?
@cmaumet: here is the python library for inferring triples: https://github.com/RDFLib/OWL-RL
@nicholst :+1: for using StatisticMap
Thanks @nicholsn!
@gllmflndn: just discussed with @satra. For the URIs (used as identifiers) we could have:
prov:atLocation
pointing to a file (ExcursionSet
, StatisticalMap
...);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.
Agreed during the Friday TF meeting (sub-group "NIDM Stats": @nicholst, @jbpoline, @chrisfilo, @gllmflndn and @tiborauer):
Implementation:
Data Model:
Apps:
Tests and validation:
Also, agreed at the Hackathon with @nicholst, @gllmflndn, @jbpoline:
SetStatistic
entity in FSL (to be able to use the same query across software)Commented by @gllmflndn:
All un-ticked items are now under discussions in separate issues. I will therefore now close this one.
See also ni-/ni-exportForFSL#1