Dear Martin et al Some quantities are so specific to a particular dataset or model that it would not be worth the effect of defining a standard name for them, since they will never be compared with data from another source, the main reason for standard names being to indicate which quantities should be regarded as comparable. In those cases, I think having your own private attribute such as htap_standard_ name is the best solution. Other projects have done that before; for instance the aquaplanet model intercomparion project has APE_names. This is Steve's solution (2). The attribute is not standard and the vocabulary is private; it perfectly legal to have non-CF attributes in CF files.
If the project is itself comparing data from different sources, it would be make sense to use standard names. As Roy says, CF standard names aren't purely geophysical quantities any more. There are others related to measurements and technical details. I think it's fine to have standard names for such things in cases where different data sources are dealing with comparable quantities and they have to work out how to identify them in a common way. I would much prefer keeping to a single attribute and namespace. It's much more convenient to look at one attribute than to search for many, as John says. Fragmentation of the namespace can in principle be resolved by mappings, but in practice that would not happen, I am sure and Roy also suggests, just because it would be a lot of work, and if it's not done, that would seriously undermine the usefulness of standard names. Part of the reason why agreeing them takes so long is that we have to understand what they mean, in order to be sure that the new ones are not duplicating existing ones, and that they are constructed in a consistent way, which will make it easier for future users to understand them too. Therefore, like others, I prefer a fast-track approach, like John's suggestion and Steve's (1), to deal with new standard names. I think we need a CF central repository for proposed standard names. That would be useful anyway to monitor their progress. I know that BADC have been working in this direction, although I don't know the status. The repository should be kept up to date by modifying it as proposed standard names are amended, accepted or rejected. We could say that some reasonable interval after a standard name has been proposed, such as a small number of weeks, and if it's still under discussion at that time (i.e. hasn't been rejected or accepted yet), it would be allowed to use it in the standard_name attribute, prefixed by "proposed" e.g. standard_name="proposed: mass_concentration_of_alcohol_in_beer". That means, as others have said, that the record of proposed names and their eventual fate would have to be maintained indefinitely, but this should be easier to manage if there's just one such repository - a central CF one - than many separate project websites. With such a system, it worries me that some projects might propose standard names and start to use them without making a serious effort to agree them as standard. I think that effort is well worthwhile, in terms of clarifying both the concepts and the vocabulary. Cheers Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
