This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#74: Allow sharing of ancillary variables among multiple data variables ---------------------------------------+------------------------------------ Reporter: [email protected] | Owner: [email protected] Type: enhancement | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: "ancillary data" "standard name modifiers" ---------------------------------------+------------------------------------ Comment (by [email protected]): Hi all ! Sorry for being negligent in bringing this trac item to closure. Let me recap where I think we are on this. The most recently published version of the CF conventions (1.6), includes an “ancillary data” construct. This allows one data variable (a.k.a. the ancillary data variable) to provide metadata about the individual values of another data variable. To conform to the convention required for ancillary data requires: (1) The use of an attribute with the name “ancillary_variables” for the data variable needing metadata to describe its elements. The attribute value is the name of the one or more associated ancillary data variables separated by spaces. (2) Declaration of the ancillary data variable with the same dimension(s) and assignment of its standard_name attribute will often have the standard_name of the data variable needing metadata to describe its elements. In the standard name attribute of the ancillary data variable, a modifier is included to indicate the relationship (see Appendix C, Standard Name Modifier). This current convention allows a single data variable to have multiple ancillary data variables, but does not allow multiple data variables to share a single ancillary data variable. The proposal is to allow the standard_name attribute in the ancillary data variable to contain one OR MORE standard_names, which are associated with the data variables needing metadata to describe their elements,. (See the original proposal in the trac item.) There was one counter-proposal presented that requires the standard name modifiers in Appendix C to have their own standard names and adding a new standard attribute to indicate the standard name of the referring variable, but this is problematic because these new standard_names do not fully identify themselves and the units could potentially vary, as is the case with the modifier standard_error. There was another counter-proposal presented that requires a unique standard_name to be defined for the ancillary data variable where the unique name is a concatenation of the standard name of the data variable being referred to and an Appendix C standard_modifier. The problems with this approach are (1) the linkage from the ancillary data variable to more than one data variable is not provided, and (2) new standard_names would need to be defined whenever a data variable (having a defined standard_name) requires a new ancillary data variable, standard_modifier combination. This could cause a very large number of new standard_names to be defined. Also note that this approach defeats one feature of the existing ancillary data convention – no need to establish standard_names for ancillary data variables having standard_modifiers. very respectfully, randy -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/74#comment:12> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
