DEPLOYMENT_PLATFORM : unambiguous ship name and codes

[matdon17]

The Argo metadata field DEPLOYMENT_PLATFORM is currently populated in a wide variety of ways, with different entries for the same ship even at the same DAC. The C17 ICES platform code vocabulary is already used within the Ocean OPS system, and if adopted for use inside the Argo NetCDF files, we will need to consider the form it takes.

An examples would be to use the full identifier, e.g. “SDN:C17::74JC James Clark Ross” to avoid ambiguity and support other vocabs e.g. for air-launched floats from planes

[gabrielapilo]

Hi Matt, from what I remember you had a link on your presentation at the ADMT2020 (day 1) for the standardised vessel names (maybe from JCOMMOPS?) Could you please share that link here?

[matdon17]

BODC host the C17 vocabulary which is essentially a copy of the ICES platform codes:
https://www.bodc.ac.uk/resources/vocabularies/vocabulary_search/C17/

ICES also make their version of the codes available via: https://vocab.ices.dk/

There is a relationship between BODC, ICES and Ocean OPS, the details of which I would need to dig out.

[tcarval]

The Argo metadata field DEPLOYMENT_PLATFORM is a human readable variable. We may enhance it with the feature URI (Universal Ressource Identifier) .
This is human readable; this is machine readable : a computer code will use a simple regexp instruction to parse uri:<*> elements.

Example:

• DEPLOYMENT_PLATFORM=“Ronald H. Brown uri:<http://vocab.nerc.ac.uk/collection/C17/current/33RO/>"

[randerson57261]

I plan on transitioning our database to the C17 vocabulary, using the "Preferred Label" field. But the "Identifier" will also be linked and available for use.

I wasn't aware that C17 existed, so we created our own vocabulary from a variety of sources.

[vpaba]

Hello,

After discussion with Victor and Magali at @nvs-vocabs/oceanops, we agree that Argo may benefit from implementing C17 in populating the DEPLOYMENT_PLATFORM field. The way that @tcarval proposed sounds like a good one, for the reasons he described. It would be good to know what the @nvs-vocabs/avtt thinks about the implementation of C17?

There is one issue that Victor identified, and that would be good to discuss: the NVS C17 vocabulary is syncronised with ICES, and as such, currently any new addition needs to go through the ICES/NOAA approval process. This may take several weeks. The outcome we want to avoid is to have the GDAC file checker refuse the registration of a new float (by rejecting the metadata file) because the C17 code for the new platform from which the float was deployed from (e.g. a ship of opportunity) is still pending approval.

How could we get around this issue?

[vturpin]

Also at OceanOPS we already use the ICES code witch is similar to C17 so should be "easy" to benefit from this evolution.

To complement the discussion, we also have a internal procedure to request ICES code any time a new ship is registered in our system. That may serve for the problem identified above.

[ClaudiaAOML]

Hello Violetta & all, To avoid issues with GDAC submissions, an issue with the content in the DEPLOYMENT_PLATFORM field should result in a warning rather than a rejection. I also think it would be good to review the rejection list for meta.nc files. The reason for this is that it sometimes takes quite a while to update a table on NVS and have that update propagate to the format checker. This results in consistent rejection of updated meta files. In such cases we submit a meta.nc file with suppressed information so that the GDAC accepts it, but the regular updates with new configuration information are rejected. That means users do not have access to such time variant information because one other field with pending updates causes a rejection. Bye, Claudia

…

On Tue, Feb 15, 2022 at 6:52 AM Violetta Paba ***@***.***> wrote: Hello, After discussion with Victor and Magali at @nvs-vocabs/oceanops <https://github.com/orgs/nvs-vocabs/teams/oceanops>, we agree that Argo may benefit from implementing C17 in populating the DEPLOYMENT_PLATFORM field. The way that @tcarval <https://github.com/tcarval> proposed sounds like a good one, for the reasons he described. It would be good to know what the @nvs-vocabs/avtt <https://github.com/orgs/nvs-vocabs/teams/avtt> thinks about the implementation of C17? There is one issue that Victor identified, and that would be good to discuss: the NVS C17 vocabulary is syncronised with ICES, and as such, currently any new addition needs to go through the ICES/NOAA approval process. This may take several weeks. The outcome we want to avoid is to have the GDAC file checker refuse the registration of a new float (by rejecting the metadata file) because the C17 code for the new platform from which the float was deployed from (e.g. a ship of opportunity) is still pending approval. How could we get around this issue? — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AW5R4ZKA23RI2BJ4674NQ3TU3I5A7ANCNFSM4UAWYKWA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

-- ************************************************************************** Dr. Claudia Schmid NOAA/AOML/PHOD Phone: 305-361-4313 4301 Rickenbacker Causeway Fax: 305-361-4412 Miami, FL 33149 email: ***@***.*** ************************************************************************** As per the 2005 NOAA security awareness recommendations, the contents of this message are mine personally and do not necessarily reflect any position of the U. S. Government or of the National Oceanic and Atmospheric Administration (NOAA).

[vturpin]

Rejection should lead to improving and not degrading the meta.file.nc.
But indeed, if the file checker or NVS vocab is not up to date rejection become conterproductive.

Maybe the warning Vs rejection should be align with the approval stage of a new collection ? related to #33 ?

[vturpin]

It seems we are reaching some kind of agreement here :

"The Argo metadata field DEPLOYMENT_PLATFORM can be enhanced with the feature URI. This is human readable and machine readable.
Example:
DEPLOYMENT_PLATFORM=“Ronald H. Brown uri:http://vocab.nerc.ac.uk/collection/C17/current/33RO/"
No uri will lead to a warning in the format checker."

BUT, because is not possible to have "rejection" in the case of new "DEPLOYMENT_PLATFORM", warnings may lead to no impact on the metadata files...
Is there a way to encourage users to fill the uri when it exist in C17 and allow "DEPLOYMENT_PLATFORM" with no C17 collection yet ?

[tcarval]

I my opinion, there is no strict way to oblige users to fill deployment_platform with C17 codes.
What we should do is regular monitoring (twice a year, before admt and ast), list the "good" and the "could be better" DACs

• "good" : more than 90% of deployment_platform with valid C17 uri
• "could be better" : less than 90%
• "why ?" : 0%

[vturpin]

I think this is a monitoring we could do at OceanOPS, modulo some evolution in the index files we are using for such statistics.
We could also set up a metadata QC feedback on ships based on this analysis...

[randerson57261]

If C17 is a unique list, why are we adding the URI? We don't add the URI in any other field.

If it's a unique list, a user should be able to look up the entry in C17 to get the other associated information.