Naming of structures that group sensors and parameters

[BrianKingNOC]

@Jean-Michel raised the following question

the argo variables dimension on N_SENSOR, eg
SENSOR
SENSOR_MAKER

are grouped into a structure SENSORS, eg

"SENSORS": [
{
"SENSOR": "SDN:R25::CTD_PRES",
"SENSOR_MAKER": "SDN:R26::RBR",
"SENSOR_MODEL": "SDN:R27::RBR_PRES_A",
"SENSOR_SERIAL_NO": "205908",
"SENSOR_FIRMWARE_VERSION": " ",
"sensor_vendorinfo": {
"vendor_schema" : "RBR",
"version": "1.0",
"RBR_foo1" : 1,
"RBR_foo2" : "twotwo"
}
},
{
"SENSOR": "SDN:R25::CTD_TEMP",
"SENSOR_MAKER": "SDN:R26::RBR",
"SENSOR_MODEL": "SDN:R27::RBR_ARGO3",
"SENSOR_SERIAL_NO": "205908",
"SENSOR_FIRMWARE_VERSION": " ",
"sensor_vendorinfo": {
"vendor_schema" : "None",
"example": "Vendors can add their own sensor info here; they can add any field they like as a fieldname below sensor_vendorinfo"
}
},

So when this is loaded into matlab, we end up with
js.SENSORS{1}.SENSOR
js.SENSORS{1}.SENSOR_MAKER

and so on.

And similar for
js.PARAMETERS{1}.PARAMETER
js.PARAMETERS{1}.PARAMETER_UNITS

@Jean-Michel question arises when one instrument, eg a CTD has multiple sensors (CTD_PRES, CTD_TEMP, CTD_CNDC, CTD_PSAL). His suggestion was to call the upper level structure 'INSTRUMENT' instead of 'SENSORS'.

So
js.INSTRUMENT
would have fields for SENSOR, SENSOR_MAKER and so on

This idea has some appeal in a file for a single instrument

But I think it breaks down when multiple instruments/sensors are aggregated for a full float.

The SENSOR array then grows to size 10, 15 or more for a BGC float.
The separate SENSOR entries are no longer so closely tied to their parent instrument.
There is just a collection of SENSORs, eg
CTD_PRES
CTD_TEMP
CTD_CNDC
TRANSISTOR_PH
OPTODE_DOXY
and so on.
All the sensors have the same status in the array, so grouping them under "SENSORS" seems like a good choice to me.

Comments welcome

[SBS-EREHM]

@BrianKingNOC Good suggestion but.....All Argo float float xxxxx_meta.nc files also have the same single large SENSOR array with no connection to the parent "instrument".

I think that's a "feature" (or "bug") in the Argo metadata scheme described in the Argo User's Guide. Given that loss of parent-child relationship, changing from SENSORS to INSTRUMENT really doesn't accomplish anything.

[BrianKingNOC]

@SBS-EREHM There is some link to the parent "instrument" through the SENSOR_MAKER and SENSOR_MODEL

[SBS-EREHM]

@BrianKingNOC I think adding a parent INSTRUMENT adds a singleton parent object that is redundant - the file itself represents the vague instrument.

Consider the SBS REMA product. It's a mechanical combo of a SATLANTIC_OCR504_ICSW and an ECO_FLBBCD created for NKE due to some noise and grounding issues with their float; the sensors are identical to the ones shipped individually. There is no Argo "REMA" instrument in Argo metadata and there really doesn't need to be. Today we ship separate calfiles for the two sensors and they are reported as separate sensors in xxxx_meta.nc data. Consistent with that, I see SBS shipping to sensor-*.json metadata files.

So, I vote no here....