Advancing the spec to Version 1.1.0

[fangq]

here is a summary of the action items from today's meeting. I will work on the spec changes, after we all agree on the changes, I will create a "Draft 4" document.

• [ ] writing a validator (python)** - @huppertt
• [ ] updating fNIRS/snirf-samples** - @fangq
  • [ ] fix 1D arrays in easyh5, regenerate the sample data files (wavelengths, ...)
• [x] spec changes/clarifications (@fangq, @huppertt, @jayd1860, @dboas )**

1. measurementDate/Time - need to allow "unknown"

2. language for *Labels (k) need to change to a 1D string array or 2D char array

3. revisit the language for string/string array:

string: either a H5T.C_S1 (null terminated string) type or as ASCII encoded 8-bit char array or UNICODE UTF-16 array. Defined by the H5T.NATIVE_CHAR or H5T.H5T_NATIVE_B16 datatypes in H5T. (note, at this time HDF5 does not have a UTF16 native type, so H5T_NATIVE_B16 will need to be converted to/from unicode-16 within the read/write code).

• [x] drop src/det/landmarkPos

• [x] leave wavelengths for "nominal" wavelengths, and define measurementList.wavelengthsActual, wavelengthsEmissionActual (optional) for actual per-optode wavelength, if available

• [x] wavelengths list can be empty for processed data, but must present

• [ ] measurementList.dataTypeIndex needs a probe.dataTypeLabels to look up

[fangq]

@huppertt @jayd1860 and @dboas

see my above commits. I've made most of the changes in the spec, but I feel unsure about measurementList.dataTypeIndex, and where the newly discussed probe.dataTypeLabels fit in this.

below is what David wrote to address #40:

---

/nirs(i)/data(j)/measurementList(k)/dataTypeIndex

• Presence: required
• Type: integer
• Location: /nirs(i)/data(j)/measurementList(k)/dataTypeIndex

Data-type specific parameter indices. The data type index specifies additional data type specific parameters that are further elaborated by other fields in the probe structure, as detailed below. Note that the Time Domain and Diffuse Correlation Spectroscopy data types have two additional parameters and so the data type index must be a vector with 2 elements that index the additional parameters. One use of this parameter is as a stimulus condition index when measurementList(k).dataType = 99999 (i.e, processed and measurementList(k).dataTypeLabel = 'HRF ...' .

---

in addition, there is also a measurementList.dataTypeLabel.

David, can you explain what is the targeted use of measurementList(k)/dataTypeIndex? what do you expect the additional data structure in probe looks like?

[sstucker]

measurementList.dataTypeIndex needs a probe.dataTypeLabels to look up

Can we revisit this? I think we are okay to "Release" 1.0 without addressing this. dataTypeIndex is in use now without this, and is well defined for TD data via /nirs(i)/probe/timeDelayWidths and /nirs(i)/probe/momentOrders

[dboas]

I don't think

measurementList.dataTypeIndex needs a probe.dataTypeLabels to look up What the dataTypeIndex references is dependent on the dataType. We presently indicated in the appropriate fields in probe when it is required for a given dataType. To be more clear about this, we might either want to itemize the various requirements in measurementList.dataTypeIndex or maybe better in the appendix where we itemize the dataTypes.

As this is just clarification of the spec and not really changing the details of the spec, I think we can leave this clarification for the next release.