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.

[callumrollo]

Hi @danibodc just to check I've understood correctly, when you say "not good practice to have multiple parameters that point back to the same URI " does that mean that we need to request extra terms in OG1 where we have several sensors on a glider measuring the same property?

To give a concrete example, we have a glider where we are testing two different sensors to measure chlorophyll, the wetlabs ecopuck and the RBR tridente:

https://erddap.observations.voiceoftheocean.org/erddap/tabledap/nrt_SEA055_M78.html

Currently, we have two variables one called "chlorophyll" and one called "chlorophyll_tridente". Both of them are measuring the same parameter, the concentration of chlorophyll in seawater. Therefore I would assume that they would both link to the same concept in the OG1 vocabulary

vocabulary: "https://vocab.nerc.ac.uk/collection/OG1/current/CHLA/"

would that not be the case? Would we need to add a new OG1 concept CHLA2?

[danibodc]

@callumrollo yes the advice would be to create additional OG1 parameters that specify that a second or third sensor was used. There are existing cases within the OG1 vocabulary where this has been implemented. See: https://vocab.nerc.ac.uk/search_nvs/OG1/?searchstr=second%20sensor&options=identifier,preflabel,altlabel,status_accepted&rbaddfilter=inc&searchstr2=