Opened 6 years ago

Last modified 3 months ago

#66 accepted defect

conformance requirement for standard name modifiers

Reported by: jonathan Owned by: davidhassell
Priority: medium Milestone:
Component: cf-conventions Version:
Keywords: Cc:

Description

In section 3.1 of the conformance document, I propose that the item

The units of a variable that specifies a standard_name must be consistent with the units given in the standard name table. The units must also be consistent with a specified cell_methods attribute, if one is present.

should be modified to read

The units of a variable that specifies a standard_name must be consistent with the units given in the standard name table and with the standard_name modifier, if there is one. The units must also be consistent with a specified cell_methods attribute, if one is present.

That will make it consistent with section 3.3 of the CF standard.

Change History (5)

comment:1 Changed 6 years ago by jonathan

In addition, I think we should change the sentence in section 3.3 of the CF standard:

Unless it is dimensionless, a variable with a standard_name attribute must have units which are physically equivalent (not necessarily identical) to the canonical units, possibly modified by an operation specified by either the standard name modifier (see below and Appendix C, Standard Name Modifiers) or by the cell_methods attribute (see Section 7.3, “Cell Methods” and Appendix E, Cell Methods).

In this sentence, the word "either" should be deleted, and "or both (with the standard_name modifier operating first)" should be appended.

comment:2 Changed 6 years ago by stevehankin

I'd argue that the proposed wording change is not a sufficient solution. The purpose of the canonical units in the standard_name table is to provide the kind of straight-forward, unambiguous guidance that a piece of software requires (say, for conformance checking purposes). The proposed wording does not address the needs of CF client software writers; the notion of "be consistent with" is too vague, when it refers to 3 pieces of information that superficially seem to be in conflict (standard_name, modifier, and cell_measure):

The units of a variable that specifies a standard_name must be consistent with the units given in the standard name table and with the standard_name modifier, if there is one. The units must also be consistent with a specified cell_methods attribute, if one is present.

There is a dual challenge here: not only are the units rendered ambiguous by the standard_name modifier and cell_methods, similarly the variable's proper name is rendered ambiguous. For example a sea surface temperature that has been modified by a cell_methods of time:variance is no longer a variable of simply sea surface temperature. It needs a new name that is something like time-variance of sea surface temperature (as well as needing new units). This new name string is what a data discovery service ought to show to users. The CF document needs to provide clear rules on how to formulate the true name of the variable, suitable for data discovery engines.

comment:3 Changed 6 years ago by jonathan

Dear Steve

I agree with you about data discovery and, as you and I have discussed by email, there is a need to indicate which combination of metadata describes the quantity. That is related to the discussion of common concepts. In this ticket, I am proposing only to clarify the conformance document, which is what the CF checker implements. The broader point needs an addition to the CF standard, doesn't it? Would this be adequate wording for the conformance document:

The units of a variable that specifies a standard_name must be physically equivalent to the canonical units given in the standard name table, as modified by the standard_name modifier, if there is one, according to Appendix C, and then modified by all the methods listed in order by the cell_methods attribute, if one is present, according to Appendix E.

I think software should be able to do that. The operations required are well-defined and can be carried out by udunits.

Best wishes

Jonathan

comment:4 Changed 6 years ago by jonathan

I argue above that Steve's point is a broader one about an additional need in the CF standard than this particular proposal to correct a defect in the current standard. Steve hasn't reasserted his objection, so I believe that according to the rules this ticket can be accepted now.

Jonathan

comment:5 Changed 3 months ago by davidhassell

  • Owner changed from cf-conventions@… to davidhassell
  • Status changed from new to accepted
Note: See TracTickets for help on using tickets.