#155: Invalid "id" values in CF Standard Name aliasses
--------------------------------+---------------------------------
Reporter: martin.juckes | Owner: cf-standard-names@…
Type: defect | Status: new
Priority: low | Milestone:
Component: cf-standard-names | Version:
Resolution: | Keywords:
--------------------------------+---------------------------------
Comment (by apamment):
Dear Martin,
Sorry for not getting to this ticket sooner!
I'm not sure I agree with changing the ids with "spurious spaces". The
problem is that when the names were first published they did accidentally
contain spaces - the aliases were introduced to correct the mistake (in
the same way as we would do for a simple spelling mistake). The versions
of the names containing spaces had been around for quite a long time
before they were noticed. "rate_of_
hydroxyl_radical_destruction_due_to_reaction_with_nmvoc" appeared in
versions 28 - 36 of the standard name table, spanning a period of 18
months in 2015-16. The other four appeared in versions 8 - 10 spanning a 7
month period in 2008. It is possible that during those periods data files
were written containing the erroneous names. To avoid invalidating such
files I thought it was better to use aliases rather than just quietly
delete the problem! I could of course simply delete the aliases if that is
generally felt to be acceptable, but that would mean treating typos
involving spaces differently from any other minor error that might crop up
in standard names.
Regarding the other alias that points to two current names, this again was
done to avoid possibly invalidating existing data files. The original
name, surface_carbon_dioxide_mole_flux, contained no indication of sign
convention and this was felt not to be satisfactory. That particular name
dates back to pre-version 1 of the standard name table and the aliases
weren't introduced until version 15, a period of at least 2006 - 2010.
Data files could have been written during that period using either upwards
positive or downwards positive as a sign convention and both would have
been valid CF at the time. I support the idea of changing the schema to
make this use of aliases valid - such a use case was probably not
envisaged when the schema was created but the main aim should always be to
preserve the original meaning of the data, not to accidentally change it
by imposing a schema that is too rigid.
Best wishes,
Alison
--
Ticket URL: <https://cf-trac.llnl.gov/trac/ticket/155#comment:2>
CF Metadata <http://cf-convention.github.io/>
CF Metadata
