Determine if `instrument_ctd` needs to be replaced by individual instrument variables for each variable.

[dpsnowden]

If the instrument_ctd variable is used and completely follows the guidance from NODC, see instrument definition, there will be accuracy, precision, etc listed for each parameter. Right now, instrument_ctd is an umbrella instrument for temperature, conductivity, pressure, depth, salinity etc. Do we need to create instrument_temperature, instrument_pressure etc, or can we find another alternative?

Perhaps using a comma separated list as is done for quality flag definitions? Or, ignore these altogether?

[graybeal]

Might need to rephrase this questions.

Almost all instruments have multiple parameters, each of which has its own accuracy, precision, etc. The guidance from NODC conflates instrument-level attributes and parameter-level attributes, and conflates instruments with sensors (using the definition of one sensor per parameter); SOS or OOI CI metadata is much clearer on these details.

Each variable in the netCDF file should be separately defined anyway, so that's where I'd expect the variable-specific details to go, unless you are explicitly trying to document the entire instrument within a single place.

[dpsnowden]

In the final sentence above you said that's "where I'd expect the variable-specific details to go". We could adopt the OceanSITES approach which is to include accuracy, precision, standard error etc as variable attributes and then allow for the instrument_ctd container to house only those concepts that apply to the entire instrument, like serial number. This is a compromise between introducing a complete Platform > Instrument > Sensor hierarchy within the netCDF file.

[dpsnowden]

See the "sensor_*" variable attributes in the Variables section of https://github.com/IOOSProfilingGliders/Real-Time-File-Format/wiki/Real-Time-File-Description for an example of the options.

1. Factor everything out of the variable attributes in favor of a container variable which, as John says above, actually conflates a couple distinct concepts.
2. Move everything to variable attributes as is done in OceanSITES, GROOM, IMOS and allow for the redundancy and possible human error of recording redundant information.

[dpsnowden]

Hybrid solution? Keep instrument_ctd as is that contains static metadata like serial number and use variable attributes for error stats, resolution, accuracy etc.

[kerfoot]

Keeping the instrument_ctd variable with attributes describing the sensor (ie: make_model, serial_number, calibration stuff) and move the accuracy, precision and resolution attributes to the C, T and P variables as per the GROOM spec:

https://github.com/IOOSProfilingGliders/Real-Time-File-Format/issues/4#issuecomment-21376076