Reliance on metadata

[matt-long]

I think we need a clear philosophy regarding the operation of esmlab in the context of it's reliance on metadata attributes.

I think there are two fundamental concerns.

1. Are we consistent and compliant with CF conventions in our interpretation and setting of attributes? @kmpaul might have the best perspective on this.

2. I think we should consider clear fallback strategies to enable functionality in the absence of CF compliant data. The package should either do something sensible, or there should be clear means by users can supply necessary information.

[andersy005]

Ccing @marylhaley since we had a discussion about how this is done in NCL last week.

[andersy005]

Are we consistent and compliant with CF conventions in our interpretation and setting of attributes? @kmpaul might have the best perspective on this.

@kmpaul any thoughts?

[andersy005]

I think we should consider clear fallback strategies to enable functionality in the absence of CF compliant data. The package should either do something sensible, or there should be clear means by users can supply necessary information.

@matt-long, @kmpaul, @jukent

Can we define what these are going to be moving forward?

[kmpaul]

First, sorry for the delay. I'm finally getting back to deal with my backlog...

I think that Matt is correct with his second point; we need to write code that behaves "appropriately" in the absence of (optional) metadata, like attributes. That should be the first layer of code... in OO speak, that should be the "base class." Then, invoke specialized code only when certain metadata is present.

Regarding Matt's first point, this is actually tricky. The point of ESMLab is to remove the need for users to deal with annoying "data wrangling" issues surrounding use of "our data" with Xarray. However, "our data" is not always compliant or consistent with the CF Conventions! ...So, which tack to we take? Do we make our code work for "our data," complying with the conventions of "our data"? Or do we make our code work with the CF Conventions?

The problem with CF compliance is that the CF Conventions are just an english-language document. Interpretation of the conventions document leads to a wide variety of different attribute encodings. So, this is very difficult to do in practice.

So, in the end, my thoughts are to "just make it work." And damn the CF conventions. It is not our job to tell the model developers or the data producers how to interpret the CF conventions... or to use them at all. It is our job just to make it easy for users to analyze that data. Do it by hook or by crook.