Inverse mapping

[znicholls]

The motivation

As a user, it would be helpful to be able to start with a branded variable and translate back to the variable name, dimensions and cell methods.

The proposed solution

• add a function like decompose_branded_variable_to_components

Alternatives

Additional context

The rules for inversion are less clear than mapping. For example, I don't think it is possible to know the cell methods in full just from the branded variables (because the branded variable doesn't capture everything). I'm not sure if dimensions are ambiguous or not either.

[taylor13]

I think inferring the name of the variable in the netCDF file is trivial as it should invariably be the same as the root name in the branded variable.

I don't see a use-case requiring that either the dimensions or the cell_methods should be inferable from the the branded variable name. The four "labels" from which the branding suffix is constructed are informational only, but they won't convey all the (often subtle) differences captured by the cell_methods. I haven't thought enough about dimensions, but I suspect they also may not be inferable from the branded variable name (except to look up the name in the variable register and obtain it from the "variable definition" metadata)

So why would we want to infer cell_methods and dimensions from the branded variable name without consulting the variable register? This information will be explicitly included there along with such things as standard_name, units, long_name, etc.)

[znichollscr]

Maybe I have misunderstood, but my understanding was that the data request was the key use case. Specifically, the data request wanted to be able to only store branded variable names, and leave all management of cell measures and dimensions to the variable register. For that work, the branded variable names must be usable as unique IDs. If there is not a 1:1 mapping between branded variables and cell measures/dimensions, then this use case isn't supported. The data request could not know exactly which cell measures/dimensions to retrieve given the branded variable alone.

If we don't support the ability to infer "cell_measures" and dimensions from the branded variable name alone, I think that's fine. The implications would be:

1. any user who wants to store a reference to the variable register needs to use some unique ID from the register, rather than the branded variable (as branded variable is not guaranteed to be a unique ID). This is fine, but my understanding is that this differs from the data request's current thinking, so we would just need to communicate and resolve that difference
2. we don't support the ability to invert the branding algorithm, and can therefore close this issue

(As another note, given the approach we're taking in CMIP7 at the moment, I don't think this has any immediate consequences for CVs/DR TTs, but whatever decision we make here will have (albeit minor, I think) implications for how the variable registry is used and linked to in future, specifically whether that linking key is the branded variable or whether we need a different unique ID)

[taylor13]

I've made a few corrections and clarifications in #11 (comment) , which might help.

My point was supposed to be that we can't infer from the branded variable name alone the variable's cell_methods and dimensions, but we can trivially obtain this information because they are included as metadata data under the branded variable name in the variable register. Isn't that quite sufficient?

[znichollscr]

Isn't that quite sufficient?

Only if the branded variable name can be used as a look up key. If a branded variable name can (even if only theoretically) correspond to two entries in the variable register (that differ only in cell methods, for example) then it's obviously not the right look up key as it doesn't lead to an unambiguous answer. If this is the case (and I think we agree it is), then users will need to use a different ID to uniquely identify entries in the variable register: branded variable is not guaranteed to be a unique ID.

[znichollscr]

Making it very simple, the question is: can the branded variable be used as a unique ID in the variable register?

I think we both agree that the answer is no, because the same branded variable can be generated from subtly different cell methods/dimensions.

That is fine, but I think we need to write it down and make it clear because I believe the DR TT was thinking the opposite i.e. that they could use the branded variable name as a unique ID for looking up entries in the variable register.