incf-nidash/nidm — pull request #171 by cmaumet (2014-09-15 08:40:14+00:00)
Title: Rename "atCoordinateSpace" in "inCoordinateSpace" + definition

**Term**: `atCoordinateSpace `
**Current definition**: "Attribute between a SpatialImage entity and a CoordinateSpace entity that is used to associate spatial metadata with a physical file."
**Original comment**: [link](https://docs.google.com/spreadsheets/d/16pC2cDsdxlzv2CzlNMtStqt5-xHwDEsU6MjZVxWhrE4/edit?disco=AAAAAJYs7Y4)

---

@nicholsn `19:07 18 Apr`
How is this? Note: we will need to define `SpatialImage` (or a similar term) that is the parent of all Maps, etc.

@JessicaTurner `20:14 21 Apr`
Is `atCoordinateSpace` the only possible association between spatial data and a physical file?

@cmaumet `11:01 25 Apr`
I would say yes. Currently, `atCoordinateSpace` is the only attribute found in a "Map" entity which is associated with a `CoordinateSpace` value.

@cmaumet `11:20 25 Apr`
Could our "Map" term be used in place of `SpatialImage`?

@nicholsn `17:37 25 Apr`
You could, but is Map the only type of Entity with CoordinateSpace metadata? I would argue that most all image types (DICOM, NIfTI, etc.) have a CoordinateSpace and the definition should reflect that.

The suggestion here is that the attribute `atCoordinateSpace` is not specific to Map, but to the "parent" of Map, which I'm calling `SpatialImage`, but we could call it something else.

Note that children can inherit the attributes (properties) of a parent class, so atCoordinateSpace is valid for SpatialImage, Map, DICOM, etc.

@satra `20:36 25 Apr`
also perhaps: `inCoordinateSpace`

@nicholsn `22:07 25 Apr`
I like `inCoordinateSpace`, might as well make a clean break from `atLocation`

@cmaumet `12:18 1 May`
For now Map is the only type of Entity with `CoordinateSpace`.

I found out that the term `SpatialImage` is used in nibabel: http://nipy.org/nibabel/generated/nibabel.spatialimages.SpatialImage.html#nibabel.spatialimages.SpatialImage
and is very similar in meaning to our Map, so maybe re-naming Map in SpatialImage would make sense.

The only thing is that we have to be careful in keeping the possibility to model surfacic data (and not being limited to image data...).
Show less

@satra `12:46 1 May`
i would stay away from `SpatialImage`, unless we wanted to make it specific and create a hierarchy. in SPM, this "Map" could be a time-series, a time-frequency representation, a volume or surface. and as such `CoordinateSpace` would have many different `units`, `dimensions` and `coordinatesystems`