Dead links to GRIB tables at end of section 3.3

[larsbarring]

Title

Dead links to GRIB tables at end of section 3.3

Moderator

None at the moment.

Requirement Summary

The Conventions document should not contain dead links.

Technical Proposal Summary

Either the dead links should be updated or removed.

Benefits

This will benefit all readers of this section of the document.

Status Quo

The conventions document will contain dead links.

Detailed Proposal

At the minimum the three dead links at the end of Section 3.3 should be updated to current web pages, or or links to non-existing web pages should be removed and the text edited to reflect the change.

However, with recent years' extensive additions to the standard name table the overlap between CF standard names and GRIB parameter tables may have weakened substantially. Thus it may be relevant to discuss whether the two lines

Here are lists of equivalences between the CF nstandard names and the standard names from the ECMWF GRIB tables, the NCEP GRIB tables, and the PCMDI tables.

instead should be removed irrespective of whether there are up-to-date web pages to link to. In this case this issues should probably be relabeled as an enhancement.

[martinjuckes]

I support this, including the removal of the lines referring to GRIB and PCMDI tables -- especially as the GRIB 1 codes referred to are now being replaced by GRIB 2.

[erget]

I support this as well - there have been many attempts to harmonise CF and WMO tables, but none of them have really gained traction, so this would keep from pointing people potentially in the wrong direction.

[JonathanGregory]

Thanks you for raising this, Lars. I support your initiative to do something about it. I agree that doing nothing but updating the links would be to correct a defect.

Going further than that would be an enhancement, as you say, and I agree with others that we should do so. As far as I know, the correspondence of standard names with PCMDI names and GRIB codes has only even been partial and never updated. I was responsible for including these in the first version of the standard name list. At that time it was desirable to make those links because standard names were a new idea, and by showing their relationship to existing standards we could make them more attractive to potential users. Now, however (twenty years later), standard names are well-established in their own right, I would say, and the mapping between different metadata standards belongs better outside the standard, in neutral territory.

Hence, I would propose we should

• delete the two lines you mention.

• delete this sentence earlier in 3.3: "When appropriate, the table entry also contains the corresponding GRIB parameter code(s) (from ECMWF and NCEP) and AMIP identifiers."

• delete this text from Appendix B:

Entry elements may optionally also contain the following elements:

<grib>GRIB parameter code</grib>
<amip>AMIP identifier string</amip>

Not all variables have equivalent AMIP or GRIB codes. ECMWF GRIB codes start with E, NCEP codes with N. Standard codes (in the range 1-127) are not prefaced. When a variable has more than one equivalent GRIB code, the alternatives are given as a blank-separated list.

• delete the <grib> and <amip> tags in Example B1 and in the standard name table.

I wonder what others think, especially Alison, of removing all this?

[steingod]

Now, however (twenty years later), standard names are well-established in their own right, I would say, and the mapping between different metadata standards belongs better outside the standard, in neutral territory.

I fully agree with this and the activities of ENVO are better suited for such developments of ontologies (especially since WMO codes also are becoming available in semantic frameworks now).

[larsbarring]

If no one else volunteer, I can to write a pull request following Jonathan's suggestion above. But it would be good hear from Alison @japamment

[larsbarring]

This issue seems to be taken over by the more general overhaul of links suggested in #267 (points 1 and 2), and no activity in this issue for more than a month. So closing .