⇐ ⇒

[CF-metadata] Re: CF Standard Names

From: Brian Eaton <eaton>
Date: Tue, 2 Apr 2002 13:52:14 -0700 (MST)

Hi Jonathan and Roland,

What strikes me about this exchange is that even though the current name
table apparently contains names for quantities that Roland needed to
identify, the table is not user friendly enough that he was able to
recognize those names. I think this shortcoming in our current table is at
least partly due to trying to express too much of the quantity definition
in the standard name itself. In support of this claim I note that only
about 1/3 the standard names even have associated definitions, the rest
depend on the name being self describing via the definitions of its
component parts. This makes the table hard to use because you have to grub
through it looking for the definitions of those parts. I think the table
would be easier to use if the individual definitions were self contained.

This leads me to make the following suggestions:

1) I think it's more important that the standard names follow accepted
earth sciences conventions than it is for them to be self describing. Thus
it's better to use a term like "precipitation rate" which then requires its
units and possibly other description to define it (does precip refer to
particular condensed phases of water?). I personally find names
like mass_flux_density to be confusing since they are describing what I
know simply as a mass_flux. Since the canonical units are part of the
definition of the quantity, northward_salt_mass_flux_in_ocean can have
units of kg/m2 and upward_water_vapour_mass_flux_in_air can have units of
kg/m2/s without risk of confusion due to mass_flux being used in two
distinct senses. This implies that the generic standard_name mass_flux
should be removed from the table since its common usage is ambiguous with
regards to its units.

2) In the interest of providing a user friendly table, and recognizing that
there are many terms with conflicting conventional usage, I propose that we
make use of the alias mechanism to provide multiple standard names whenever
a case can be made that the standard_name being proposed has widespread
use. I would consider the appearance of a name in a GRIB table to be
sufficient evidence of widespread use.

3) Whenever an abbreviation is used in a standard name the corresponding
definition should spell it out.

While we're on the topic of standard names I'd like to respond to some
suggestions that Jonathan made on 12 Dec 2001:

> I think LW and SW would be OK as replacements for longwave and shortwave.

In general I think that staying away from abbreviations like this will make
the standard names more readable (at least to speakers of English).

If we use longwave as an abbreviation for "longwave radiation", and flux as
an abbreviation for "flux density", then longwave_radiation_flux_density
becomes longwave_flux. Also, I vote for putting the "net" into the
standard_name of flux quantities when that's what's meant.

> It would be nice to have an abbrev for the clumsy phrase "rate_of_change_of".
> I don't think there is a very standard abbrev for this, but perhaps "ROCO"
> would be understandable?

Our convention is to use the term "tendency".

> Could you replace the three quantities of the form "northward_*_in_ocean"
> with "northward_ocean_*"? If you do that, we can make a clear distinction
> between what are currently the two occurrences of "medium" in the template.
> I would propose
>
> [surface] [component] [large_scale_medium] base_standard_name [at surface]
> [in material] [due to process] [where type] [assuming condition]
> where large_scale_medium is e.g. ocean or atmosphere, and
> material is e.g. air, sea_water, sea_ice.

This seems OK to me as a guideline for name construction. But again, I
think we need to give more weight to common usage and not be too bound by a
rigid formula for name construction.

Best regards,
Brian

P.S. Check out the mailing list for CF metadata discussions accessable
from the CF home page at: http://www.cgd.ucar.edu/cms/eaton/cf-metadata/
Received on Tue Apr 02 2002 - 13:52:14 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒