Whilst looking at the nitrate spec for BGC derivations, I've noticed that we have two nitrate variables that look nearly identical in R03:

UV_INTENSITY_DARK_NITRATE (in nitrate cookbook) defined in R03 as:
Raw ultra-violet (UV) flux signal (count) in darkness from nitrate sensor.

UV_INTENSITY_DARK_SEAWATER_NITRATE (not in nitrate cookbook) defined in R03 as:
Raw ultra-violet (UV) flux signal (count) in seawater and darkness from nitrate sensor.

It seems as though UV_INTENSITY_DARK_SEAWATER_NITRATE might be a duplicate of UV_INTENSITY_DARK_NITRATE. Is this the case?

Each parameter is defined as being either:

• core (c)
• BGC (b)
• intermediate (i)

This is stated in the Argo user manual, as well in various cookbooks such as the individual BGC cookbooks. However, this information is not captured in the NVS. Should it be?

And if so, should it be via free-text additions to the R03 concept descriptions, or through a mapping to a new parameter type vocab?

The following concepts need to be created to reflect the updates carried out in Reference Table 3 (parameter code table) of the Argo User Manual:

• TEMP_CNDC
• NB_SAMPLE_CTD
• NB_SAMPLE_OPTODE
• NB_SAMPLE_OCR
• NB_SAMPLE_MCOMS
• NB_SAMPLE_CROVER
• NB_SAMPLE_SUNA
• NB_SAMPLE_ISUS
• NB_SAMPLE_STM
• NB_SAMPLE_CYC
• NB_SAMPLE_DURAFET

Would it be possible to further include in the description of each parameters the attributes we get in Argo netcdf files ?

For instance for TEMP:

		TEMP:long_name = "Sea temperature in-situ ITS-90 scale" ;
		TEMP:standard_name = "sea_water_temperature" ;
		TEMP:_FillValue = 99999.f ;
		TEMP:units = "degree_Celsius" ;
		TEMP:valid_min = -2.5f ;
		TEMP:valid_max = 40.f ;
		TEMP:C_format = "%9.3f" ;
		TEMP:FORTRAN_format = "F9.3" ;
		TEMP:resolution = 0.001f ;

This would be very useful for 3rd party libraries trying to check or double-check data returned by web API such as Ifremer erddap, Euro-Argo dataselection or argovis

In July 2020 I made some suggestions to update the Argo parameters list Excel file named:

• argo-parameters-list-core-and-b_CS_20180129.xlsx

Specifically:

DPHASE_DOXY - currently OXYCPHAB, but this is actually C1PHASE_DOXY - I recommend OXYCPHAC
TPHASE_DOXY - currently OXYCPHAC, but this is actually DPHASE_DOXY - I recommend OXYCPHTC
C1PHASE_DOXY - currently OCYCPHAD, but doesn't exist - I recommend OXYCPHAB
C2PHASE_DOXY - currently OXYCPHAE, but doesn't exist - I recommend OXYCPHAR

At the time of writing, the Excel file was last updated in February 2021, but some problems remain:

• the entry in sdn_parameter_urn for C1PHASE_DOXY remains incorrect as "OCYCPHAB" rather than "OXYCPHAB"
• this is causing the test in sdn_parameter_uri for C1PHASE_DOXY to also be wrong
• the hyperlink in sdn_parameter_uri is wrong for all of the variables mentioned above - the cell formula is correct, but the cell itself seems to have the old hyperlink in use instead if you mouse-over of click on it

Looking at P01 mappings that have been transferred into R03 and we see:

• DPHASE_DOXY - mapped to OXYCPHAC as expected
• TPHASE_DOXY - mapped to OXYCPHTC as expected
• C1PHASE_DOXY - not mapped, probably because of the issue outlined above
• C2PHASE_DOXY - mapped to OXYCPHAR, as expected

So I recommend that:

• the spreadsheet be further updated to correct C1PHASE_DOXY mapping to P01 from "OCYCPHAB" to "OXYCPHAB"
• correct the links in the spreadsheet for all these parameters
• we add the mapping to OXYCPHAB for http://vocab.nerc.ac.uk/collection/R03/current/C1PHASE_DOXY/

This issue has been flagged due to a carry-over issue from Argo to EGO gliders formats and the OG1 vocabulary, see:
http://vocab.nerc.ac.uk/search_nvs/OG1/?searchstr=oxy&options=identifier,preflabel,altlabel,status_accepted&rbaddfilter=inc&searchstr2=

@vpaba @bodcmahe @catsch @tcarval