OG1 vocab: ancillary variables

[callumrollo]

Moderator: @OceanGlidersCommunity/format-maintainers

How should we deal with secondary/duplicate variables in an OG1 file? e.g. temperature from an oxygen optode, pressure from an ADCP etc. I assume that we should still link to the correct OG1 vocabulary concept, but what name should we give to the netCDF variable for this data? something like "TEMP_OXYGEN_OPTODE"? "OPTODE_TEMP"?

Should the long_name and standard_name differ between the temperature from the CTD and the temperature from an optode?

The SENSOR attribute will unambiguously identify the source of the data, but we can't have two variables called TEMP

[danibodc]

Hi @callumrollo,

I think you would need to create new concepts for secondary/duplicate variables so that you have a unique URI for each, describing the differences unambiguously.

There are instances in OG1 where 'second sensor' has been appended to the preferred label, usually reserved for duplicate parameters from the same instrument type.

However, I notice there is an existing term in OG1 for Temperature from an oxygen optode: http://vocab.nerc.ac.uk/collection/OG1/current/TEMPDOXY. So this is an approach you could use for secondary/ancillary variables.

[callumrollo]

Thanks Dani. So, for instance with our ADCP, we will need to request terms like PITCHADCP, ROLLADCP, TIMEADCP etc?

[emmerbodc]

This goes back to the days of discussing groups as a way to handle these use cases but there wasn't a consensus to go with this because tooling doesn't work so well with groups.

I think this would require further discussion as we haven't discussed having multiple time channels in the OG1.0 file format.

If i remember well, the discussion of the same sensor type duplicated was going to be handled via naming the variable TEMP1 TEMP2 in the NetCDF and the attributes would link back to the sensor model and serial but again may need a revisit and some documentation

[emmerbodc]

Discussed in vocab meeting 06/09/24

Agreed for same measurement from a different sensor we can create new OG1 terms such as TEMP_DOXY
For same sensor type we could either create new OG1 concepts that specify second sensor or we could name the variables differently in the OG1 for example TEMP_DOXY, TEMP_DOXY2. We have the URL to link back to the sensor instance but we would like some some advice from the NVS team regarding how to handle duplicate sensors data in files.
Action @danibodc to take back to NVS team

Agreed that extra time channels in OG1 format from ADCP needs bringing back to DMTT meetings to discuss further
Action @emmerbodc to create a new ticket for this and raise in future DMTT meeting

[danibodc]

@emmerbodc I have added this to the agenda of our next Vocabulary Management Group meeting which is on Thursday, so will report back from then.

[danibodc]

@emmerbodc Advice from the meeting is to create new OG1 terms for each duplicate parameter, not good practice to have multiple parameters that point back to the same URI - this is not fully machine readable.