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 jonathan): Dear Randy, Nan et al. I think the difference between Randy's proposal and Nan's comment highlights a different perception about the purpose of `standard_name`s and modifiers. I believe the purpose of the standard name is to make the data variables self-describing, and the modifiers were introduced as an extension to support this purpose without expanding the standard name table too much. If that's the purpose, Randy's proposal is logical because the data variable for status flag or number of observations variable needs to describe ''itself'' as applying to various different quantities. This would be particularly helpful if the status flag data variable was stored in a different file from the primary data variables, for example, in which case it would lose the association if it could not describe itself. Thus, I don't think the modifiers are principally intended as pointers. On the other hand, the `ancillary_variables` attribute was deliberately introduced as a pointer. It makes life easier by pointing from the primary data variable to its metadata variables. It could be omitted, because the association can be inferred from the standard names. In Nan's example, if you scan the file and find a variable with `standard_name` of `sea_water_temperature number_of_observations`, you know that it is a metadata variable which belongs to a primary data variable with a `standard_name` of `sea_water_temperature`; the `ancillary_variables` attribute of the primary data variable is a convenience feature which saves your having to scan the file. I would suggest that the above is an answer to Nan's comment, and supports Randy's proposal. However, there have been other threads discussing standard name modifiers, which together give the impression that they are confusing and/or were ill-conceived. A particular restriction about the interpretation I have given and Randy's proposal is that it can only apply when the metadata variables for the various primary data variables have the same units. That is OK for `status_flag` and `number_of_observations`, which are dimensionless. Metadata variables with these modifiers could apply, for example, to both `sea_water_temperature` and `sea_water_salinity`. A metadata variable with the `standard_error` modifier could not, because it would have a different unit for the two primary data variables. Therefore I am wondering about a simpler solution than Randy's or Martin's. Maybe we should introduce `status_flag` and `number_of_observations` as standard names in their own right. The drawback with this would of course be that the metadata variables with these standard names would not be so completely self-described. You would not be able to tell which primary data variable they belonged to if they were in different files. Within the same file, you'd have to rely on the ancillary_variables pointer if there was any ambiguity. But maybe this would not be too bad. There are plenty of other relationships between data variables in files that are application-specific and not indicated by any CF metadata e.g. it's a reasonable assumption that `sea_water_temperature`, `sea_water_salinity` and `sea_water_density` are all physically consistent. What do you think? This would not be a solution to the other existing modifiers of `standard_error` and `detection_minimum`, which are not dimensionless, but other discussions have suggested that those could be replaced with `cell_methods`. That would be a topic for a different ticket. Best wishes Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/74#comment:26> 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.
