Add an association between PLATFORM_TYPE, PLATFORM_MAKER and WMO_INST_TYPE for FileChecker consistency checks

[delphinedobler]

In the original argo Reference table 23 (https://docs.google.com/spreadsheets/d/1Aw8B7FFUjG4e9MveD5qqvI7ZbB-z_x32IQnpHZbXVZA/edit#gid=2), there was the indication of the possible manufacturer(s) and WMO_INST_TYPE (column IXIXIX (1770)) for a given platform_type. This information is used in the FileChecker, but is absent of https://vocab.nerc.ac.uk/search_nvs/R23/ table. We should find a way to indicate these possible associations in the NVS.

As an additional action, in the FileChecker, MARTEC should be allowed for PROVOR II (PR_version 5.0, 5.1, 5.2 and 5.5) along with NKE (discussed with Vincent B.). This concerns 17 coriolis floats (old ones), for which the meta file update is not possible at the moment.

[delphinedobler]

Edit from JPR @tcarval :

• PROVBIO-A (Coriolis V5.0) (2006/11/15) is a MARTEC
• PROVBIO-B (Coriolis V5.1) (2008/03/26) is a KANNAD
• PROVCARBON (Coriolis V5.2) (2007/12/20) is a KANNAD
• PROVNUTS (Coriolis V5.5) (2010/10/23) is an NKE

Reference table 23 of the GDAC checker should be updated as follows :

PROVOR_II | 103 | 839 | MARTEC KANNAD NKE | dual board PROVOR |
instead of PROVOR_II | 103 | 839 | NKE | dual board PROVOR |

And similarly for the PROVOR:
PROVOR | 101 | 840 841 842 | MARTEC KANNAD NKE | |

[vpaba]

Hi @delphinedobler, thank you for raising this.

With regards to linking information between terms in different NVS collections, the creation of 'mappings' can be of use to address exactly this.

I am happy to go through this with you in case, though the steps are described in the NVS website.

To try this, please go to the Vocab Editor tool (https://vocab.nerc.ac.uk/editor/), and click on 'Mappings - bulk uplaod', just above the list your collections, on the right-hand side.

This will take you to the following instructions:

Submit mappings in a pre-prepared comma separated file with NO HEADER.

For NVS to NVS mappings you will need the following columns (all fields mandatory):
| Subject collection ID | Subject Concept ID | Relationship ID | Object Collection ID | Object Concept ID | Action |

Action can only be "I" (for insert) or "D" (for deprecate).

Relationship ID needs to be one of the permissible terms from collection C60 (currently: BRD, NAR, SYN, MIN)

To satisfy your request, we could create R23 - R24 and R23 - R08 mappings.

To do this, we would create a simple text file containing the following, for example:

R23, PROVOR, MIN, R24, NKE, I
R23, PROVOR_II, MIN, R24, MARTEC, I
R23, PROVOR_II, MIN, R24, NKE, I
R23, PROVOR, BRD, R08, 840, I
R23, PROVOR, BRD, R08, 841, I
R23, PROVOR, BRD, R08, 842, I
R23, PROVOR_II, BRD, R08, 839, I

*Note that I've not included a mapping to 'KANNAD', as this would need creating in R24 first.

And upload it to the Vocab Editors - mappings page for review and submission.

Please let me know if this would meet your requirements, and if so, whether you'd be happy to try submitting these mappings?

If you encounter any issues or have any questions, please let me know.

Thanks,
Violetta

[delphinedobler]

Hi @vpaba ! Thank you very much for your help and indications. From what you explain, I think mappings are convenient. I will try this and will get back to you if I have trouble. I need to have a look on how it looks like when tables are exported (in prevision of the File Checker update).

[tcarval]

Argo uses C60 mappings; example : #118

[danibodc]

Hi @delphinedobler if these mappings have been created the ticket can now be closed, thanks!

[delphinedobler]

Hi @danibodc, thank for raising this. I've made some updates, based on Violetta's guidance but it was some time ago and I don't remember well but I did not fulfill completely. I will double check and complete and provide a status before ADMT. This ticket was twofold: one part on the NVS tables, and one on the file checker configuration file. @tcarval: have you added the mapping between PROVOR/PROVOR II and MARTEC in the configuration files of the file checker, or does this still need to be done ?

[delphinedobler]

As I remembered, I missed a few mappings because of unfound entries in R08:

From the WMO_INST_TYPE that can be found in the initial reference table file https://docs.google.com/spreadsheets/d/1Aw8B7FFUjG4e9MveD5qqvI7ZbB-z_x32IQnpHZbXVZA/edit?gid=2#gid=2, sheet PLATFORM_TYPE/KEY, column C, a few codes are missing in R08:

• ALTO : 873 (39 floats in the GDAC)
• SOLO_D_MRV : 874 (82 floats in the GDAC)
• NAVIS_EBR : 869 (342 floats in the GDAC)
• HM2000 : 870 (87 floats in the GDAC)
• ITP : 901 (None in the GDAC)
• ALAMO : 866, 867, 868 (None in the GDAC)

Additionnally, code 871 (would mean COPEX floats from the 1770 table) is used in the GDAC (15 floats), but this code is not in table R08. It was used to assign WMO_INST_TYPE for HSOE/HM2000/CSIO floats, which seems incorrect => code 870 should have been used probably.

Codes 881 and 882 and used for HM4000 and XUANWU (HM6000) floats on the GDAC. In the 1770 table, these codes are noted as "Reserved".

Regarding NVS R23, XUANWU is missing, it concerns 17 floats (16 indicates LaoshanLaboratory and 1 QNLM as associated platform_maker: #63) The float indicating QNLM should be corrected.

Regarding NVS R24, LaoshanL altlabel should be changed to LaoshanLaboratory to match what is in the GDAC (#63), it is used by 16 floats (cf. above comment). Additionnally 3 floats do not report correctly TWR (TELEDYNE WEBB found for csio/2902654; Teledyne Webb Research found for aoml/5904002 and Webb found for aoml/5901338).

Looking at the reference table from which WMO_INST_TYPE codes are extracted (https://library.wmo.int/records/item/35713-manual-on-codes-international-codes-volume-i-1/), 870, 873 and 874 codes are consistent with the instrument type name as described in our former Excel spreadsheet. However, there seems to be one inconsistency: code 869 is marked as "Reserved" in the 1770 table, and not associated to NAVIS_EBR as in our spreadsheet. Is there any reason why @tcarval, anyone ? It is noteworthy that there is no other code mentioning NAVIS_EBR in the 1770 table. Regarding NAVIS floats, there is only NAVIS-A in table 1770, associated to code 863 and this 863 code is effectively used in Argo and concerns 997 floats.

So, there is nothing preventing from adding 870, 873 and 874 in table R08 and create the corresponding mappings, unless someone objects.

But how should we deal with code 869 and other codes that are marked as "Reserved" in the 1770 table ? I suggest we mention this in the description of the R08 associated concept.

Other discrepancy found: PROVOR_V_JUMBO are marked as WMO_INST_TYPE 888, 889 but in the GDAC 834 is used.

[delphinedobler]

Associated tickets:
#90 (consistency between WMO 1770 table and Argo codes)
#85 (SOLO_BGC and SOLO_BGC_MRV in R23)
#63 (renaming platform_maker from QNLM to LaoshanLaboratory)
#36 (renaming platform_maker from HSOE to QNLM)

[delphinedobler]

• Add 869, 870, 873 and 874 in R08
• Finish the mapping for HM2000, HM4000, XUANWU (HM6000), NAVIS_EBR, POPS_NEMO, POPS_PROVOR, SOLO_D_MRV, SOLO_BGC, SOLO_BGC_MRV
• Edit the R24 description for QNLM and LaoshanLaboratory to mention that they are related (name change). (change submitted)
• Change AltLabel from HM6000 to XUANWU in R23 (HM6000 already mentioned in the description)
• For codes 869, 834 and 875 to 891: add in the description that the codes is not from 1770 table (corresponds to Reserved ids). (submitted)
• allows MARTEC for PROVOR and PROVOR_II in the file checker @tcarval
  (examples of wmos with MARTEC and PROVOR/PROVOR_II:
  6900630;841;MARTEC;PROVOR;
  6900631;841;MARTEC;PROVOR_II;
  They were accepted when created but their meta files can not be updated anymore with the now more contraigned FileChecker version)

[delphinedobler]

Investigation_mapping_R08_R23_R24.xlsx