cell method data model/context

[znichollscr]

"description" isn't the right name for what is currently in that field. The current value of "description" is the cell method i.e. this should be called "definition". In addition, there should be a 1:1 mapping between id and "description"/"definition". At the moment there are multiple id's for the same cell methods (i.e. same value of "description"), which doesn't make sense (we are assigning two different id's to the same cell methods).

[znichollscr]

Given how it's used, what is currently description could also become "validation-key", as this is what appears in files

[znichollscr]

To confirm: the idea of having the cell methods split out is that we think the CF-conventions' information alone is not enough? (So, yes, we're sort of restating information that is already specified by the CF-conventions, but we're doing this on purpose to try and make life easier for users)

[wolfiex]

Description is a protected optional field that should say what something is across all files. It just happens to have existed in most of the CVs organically. There are cases where it might need to be discussed. Essentially it should answer 'What is this?', which in a very descriptive item could be the key or the ui-label. Ideally we would have a bit more information (more verbose) attached to it though.

Each cell method should have its own entry and description.

Additionally the current set of files were automatically generated with minimal information from the DR. They were meant to be a proof of concept and overwritten following discussion. The descriptions could also be automatically generated text compiled from the branding identifiers, or free text info / notes.

[znichollscr]

Ok all good.

A question for @taylor13 then. Masks are part of cell methods right? For example, "time: area: mean (mask=siconc)" and "time: area: mean (mask=siconca)" are two different cell methods. (I ask because right now these are captured as the same cell methods, "time: area: mean" with different masks as a separate part of the definition, but as I understand that isn't a thing. The cell methods are defined by the cell methods string, there is no other information/defintion.)

[taylor13]

No, not an official part. Specifying a specific mask in parentheses is not "understood" by CF. CF permits a single standardized text string to appear in the parentheses (specifying the sampling interval used in compiling a reported statistic) plus any non-standardized text whatever the user wants to include. "mask=siconca" is an example of such non-standardized text.

The "mask=" text was introduced in CMIP6 to indicate which of the two sea ice masks should be used with a variable. This information, however, is unnecessary, because which sea ice mask is used is determined by which grid the data are being reported on.

In CMIP7 there will only be a single sea ice variable defined ("siconc"), but that variable can be reported on different grids, which will be identified by the grid_id attribute. Users must use the siconc data that has the same grid_id as the variable they are masking. There is no ambiguity about this and no need for "mask=".

In the open office data request, we can either completely omit mask=siconc from cell_methods, which would be my strong preference, or change the 6 instances of mask=siconca to mask=siconc (which I think @matthew-mizielinski and @JamesAnstey prefer). In the variable register, I think we should omit mask=siconc and mask=siconca.

Note that we have additional issues with ice-sheet fraction. For most land-ice variables, cell_methods says "where land_ice" and there is no mask indicated. But when "where grounded_ice_sheet" is specified, then the cell_methods includes (mask=sfgrlf). Trouble is there is no variable with the name "sfgrlf", so this is unhelpful (you could say "wrong"). (Probably what was meant was "sftgrf"; IyrAnt.sftgrf. IyrGre.sftgrf, LImon.sftgrf, and Efx.sftgrf.) Even more confusing is that the same name appears in cell_methods even though different masks apply to the globe, Greenland, and Antarctica

I think it would be best if we simply eliminate all uses of "mask=" in cell_methods. I think it is easy for data providers to figure out how to mask consistent with "where ???" without specifying the name of a mask (which is often ambiguous anyway). And most analysts will simply use the variable where it is defined, so they usually won't need the mask that goes with that variable.

[taylor13]

Should have mentioned that another reason I think it best to remove "mask=..." is that it builds into the variable register a dependency of one variable (the variable reported) on another variable (the name of the variable mask). This will make it difficult for us to retrospectively apply the variable register definitions to past phases of CMIP, when, for example, a different name for sea ice area fraction was used: "sic". We'll have to look up two names for variables masked by sea ice fraction to find out the corresponding names in the variable register. If we leave off "where siconc", then we only have to look up the branded variable name of interest, and there won't be any inconsistency between the cell_methods used for CMIP3, CMIP5, CMIP6, and CMIP7 variables.