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: [email protected] Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
