Dear Jonathan, John G. and John D.,
Thanks for your discussion of the surface_carbon_dioxide_mole_flux name:
> 6) surface_carbon_dioxide_mole_flux
>
> We have agreed that this existing name is ambiguous as to its sign
> convention and we think that it has generally been used as an upward
> flux into the atmosphere. We have also agreed that it would be useful
> to
> define fluxes in both directions.
>
> Jonathan has suggested making the existing name an alias of
> surface_upward_mole_flux_of_carbon_dioxide. I am uncomfortable about
> opting to add one specific direction to this name, which effectively
> changes (narrows) its definition, when we can't be certain how it has
> been used in the past. I suggest adding two new names of
> surface_upward_mole_flux_of_carbon_dioxide and
> surface_downward_mole_flux_of_carbon_dioxide and making
> surface_carbon_dioxide_mole_flux an alias of both. That way, any data
> written in the future will be unambiguous but we won't be imposing a
> (possibly) incorrect interpretation onto older data. What do others
> think?
I think we've now agreed on creating the two new names and making the
older name an alias of both. This will be done at the next update of
the standard name table.
The discussion of this point has prompted me to review exactly what the
current CF document says about aliases and how we are using them in
practice in version 14 of the standard name table. Some of the issues
are quite subtle, but I believe that we are using aliases in a manner
consistent with the spirit of the conventions document.
The purpose of aliases is to provide a way of deprecating
standard_names. This is discussed in CF 1.4, Appendix B which describes
the XML schema of the standard name table:
"The purpose of the alias elements are to provide a means for
maintaining the table in a backwards compatible fashion. For example, if
more than one id string was found to correspond to identical
definitions, then the redundant definitions can be converted into
aliases. It is not intended that the alias elements be used to
accommodate the use of local naming conventions in the standard_name
attribute strings."
Clearly this is not an exhaustive list of the circumstances in which
aliases can be (and are) used, but I don't think it restricts the
relationship between standard names and aliases to be solely one-to-one
mappings.
I think it is important to reiterate that once a standard name is added
to the standard name table, the string that is chosen will remain in the
table in perpetuity, either as a current standard name or as an alias.
All are listed in the table along with the appropriate canonical units
and (usually) a description/definition.
Generally speaking, an alias is created if it becomes apparent that the
string originally chosen to be the standard name of a quantity is
ambiguous, inappropriate or incorrect in some other way (e.g., a
spelling mistake or a typo). Under these circumstances a new standard
name is chosen to represent the defined quantity. The older string is
then made an alias of the new standard name and is listed as such in the
table entry for the name. In this way both versions of the name
continue to be associated with the same units and definition and only
the name itself changes. Older data written using the alias will remain
valid CF and will retain the same units and definition information, and
new data should be written with the new standard name. A current
standard name may be mapped to zero, one, or more, aliases. Most
current names have no alias. Many have just one, e.g., the current name
mass_fraction_of_ozone_in_air has an alias of
mass_fraction_of_o3_in_air. The quantity with standard name
lagrangian_tendency_of_air_pressure was previously known first as
'omega', then as '
vertical_air_velocity_expressed_as_tendency_of_pressure' so the current
name has two aliases.
It is of fundamental importance that the meaning of a standard name does
not change even when the name itself changes because to do so risks
altering the interpretation of existing data. This does not necessarily
mean that the definition text will never be modified, but modifications
will only be made to improve clarity and make the quantity easier to
understand, not to change the interpretation. Sometimes I make this type
of modification to a definition even when no alias is being introduced.
When an alias is being introduced there are three circumstances that
would require some adjustment to the definition text:
1) The name itself is mentioned in the definition - in this case I would
change the text to reflect the (new) current name.
2) The new name employs one of the common standard name 'phrases' that
didn't occur in the older version - I would add the standard text that
explains that phrase to the definition (although I can't recall ever
needing to do this in practice).
3) The mapping being created between a standard name and an alias
broadens or narrows the usage of the name. I can think of two examples
of this:
a) the aliases we have just agreed for the surface carbon dioxide
fluxes in which two more specific names are being introduced to remove
ambiguity in the original. Each new name will have its own separate
definition, and the two definitions will differ only in the sign
convention. We have agreed that it would be a mistake to impose one or
other sign convention on existing data, hence the only available
solution is to create the same alias for both names. The definitions
will refer to one another and will both explain that data written with
the deprecated "unsigned" name needs to be examined carefully to
determine which convention was used.
b) aliases that were created from the old "where" names as a result of
agreeing trac ticket 17. It was agreed that instead of including a
description of surface type in the standard name we would supply that
information via cell_methods and (optionally) string valued coordinate
variables. The aliases created were:
precipitation_flux_onto_canopy (alias
precipitation_flux_onto_canopy_where_land)
surface_net_downward_radiative_flux (alias
surface_net_downward_radiative_flux_where_land)
surface_snow_thickness (alias surface_snow_thickness_where_sea_ice)
surface_temperature (aliases surface_temperature_where_land,
surface_temperature_where_open_sea, surface_temperature_where_snow)
surface_upward_sensible_heat_flux (alias
surface_upward_sensible_heat_flux_where_sea)
water_evaporation_amount_from_canopy (alias
water_evaporation_amount_from_canopy_where_land)
water_evaporation_flux (alias water_evaporation_flux_where_sea_ice)
water_evaporation_flux_from_canopy (alias
water_evaporation_flux_from_canopy_where_land)
area_type (aliases land_cover, surface_cover).
We needed to create these aliases because the CF conventions were
modified and the basic geophysical quantities are the same, regardless
of the underlying surface type. The current names are all somewhat
broader in scope than their aliases but I added sentences to all the
definitions to explain how older data employing the 'where' phrase
should be interpreted, thus preserving the meaning of those data.
This seems like a lot of detail about one small corner of the
conventions but I thought it would be useful to write it down so as to
be clear about how the aliases are being used and, in particular, how
they interact with the definitions. Perhaps it would be helpful to
incorporate some of the above into section 3.3 of the CF document to
give a more complete description of the purpose and use of aliases. I
would be willing to create the necessary trac ticket if anyone else
thinks it would be worthwhile.
Best wishes,
Alison
------
Alison Pamment Tel: +44 1235 778065
NCAS/British Atmospheric Data Centre Fax: +44 1235 446314
Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk
Chilton, Didcot, OX11 0QX, U.K.
--
Scanned by iCritical.
Received on Thu Jun 10 2010 - 06:58:04 BST
