-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OG1 vocab: ancillary variables #262
Comments
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. |
Thanks Dani. So, for instance with our ADCP, we will need to request terms like PITCHADCP, ROLLADCP, TIMEADCP etc? |
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 |
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 Agreed that extra time channels in OG1 format from ADCP needs bringing back to DMTT meetings to discuss further |
@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. |
@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. |
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
The text was updated successfully, but these errors were encountered: