Dear John Thanks for your helpful email and summary.
(a) Regarding > After a suitable opportunity for general comment > on the latest emails, can the moderators weigh in with suggestions to > resolve each issue one way or the other, or to create a TRAC proposal > discussion? I would like to point out that there are no moderators available. Those who are discussing it are responsible. CF doesn't have any other resources to resolve such issues. We can move to trac if you like. If there are specific proposals to amend the convention, trac is the way to make them. (b) Unprocessed/uncalibrated geophysical properties. I think this is my raw data. We could propose a standard name modifier for it. Since that has to specify a particular units transformation, I think the obvious options are dimensionless raw data (units not specified), or raw data with the same physical dimensions as the geophysical quantity. If both are useful, separate modifiers for each of them could be proposed. Nan also mentioned QC data; that is certainly a good purpose for standard_name modifiers and we already have some defined in the convention for that. Both you and Roy think that the modifier would be better if it was attached with some non-blank character to the rest of the standard name. That could be proposed as a change to the convention (although we'd have to keep blank-separation for backward compatibility). I would argue that if we do that it should be some character which we would prohibit from being used anywhere else in a standard name. For instance, we could use % for this purpose. I think hyphen would be confusing as it looks too much like underscore. (c) Sensor quantities. I don't think we should completely rule out defining standard names for these. For example, I think the "platform" names in the standard name table are well-defined and useful. However, I quite like your idea of defining generic standard names. If they are going to be standard names, they have to have canonical units, so they cannot be as vague as "sensor property". However, we could define a standard name for sensor_temperature, for instance. That would replace temperature_of_sensor_for_oxygen_in_sea_water, in your suggestion, I think. The more specific description would no longer be in the standard name. However, to some extent this just postpones the issue. Is it necessary to *standardise* the extra information, or could each dataset just record it in some informal way, for instance in the long_name? If that would be sufficient, it would be far easier. Deciding standards is a time- consuming business, as we all know. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
