CVs for all compulsory global attributes and Matt's wish list

[znichollscr]

The content side of ESGF/esgf-vocab#144

For now, targeting https://github.com/WCRP-CMIP/CMIP7-CVs/tree/esgvoc_prod_wip

The list of attributes is the one we agreed in the CVs TT. Spreadsheet is here: https://docs.google.com/spreadsheets/d/1yhW7CkY2sS6JhqTa_7hsUAbkM2vyxE8tmXJKe1Sdc4w/edit?pli=1&gid=1056516560#gid=1056516560. Zenodo version is here: https://zenodo.org/records/17250297

Proposals (☑️ indicates that they're in the esgvoc_dev branch or #310):

• activity
• area label
• branded variable
• branding suffix
• conventions
• creation date
• data specs version
• drs specs
• experiment
• forcing index
• frequency
• grid label
• horizontal label
• initialisation index
• institution
• license
• mip era
• nominal resolution
• physics index
• product
• realisation index
• realm
• region
• source
• temporal label
• terms of use
• tracking ID
• variable
• variant label
• vertical label
• branch time in child (not CV)
• branch time in parent (not CV)
• external variables (not CV)
• parent activity id (not CV)
• parent experiment id (not CV)
• parent mip era (not CV)
• parent source ID (not CV)
• parent DRS (note in the table, but was in the discussion sheet) (not CV)
• parent time units (not CV)
• parent variant label (not CV)
• directory date
• time range
• filename
• directory structure

Finalised:

• activity
• area label
• branded variable
• branding suffix
• conventions
• creation date
• data specs version
• drs specs
• experiment
• forcing index
• frequency
• grid label
• horizontal label
• initialisation index
• institution
• license
• mip era
• nominal resolution
• physics index
• product
• realisation index
• realm
• region
• source
• temporal label
• terms of use
• tracking ID
• variable
• variant label
• vertical label
• branch time in child
• branch time in parent
• external variables
• parent activity id
• parent experiment id
• parent mip era
• parent source ID
• parent DRS (note in the table, but was in the discussion sheet)
• parent time units
• parent variant label
• directory date
• time range
• filename
• directory structure

[znichollscr]

@matthew-mizielinski a couple of questions:

• terms of use link: which attribute does this apply to?
• what is 'simple set of attributes' ?
• do you have strong opinions on spelling i.e. whether it is initialization index or initialisation index?
• what is source type?

[matthew-mizielinski]

@matthew-mizielinski a couple of questions:

• terms of use link: which attribute does this apply to?

Sorry - indentation needed here. in the License text there is a terms of use link pointing at PCMDI pages -- we need to either remove or update the link

• what is 'simple set of attributes' ?

the required_global_attributes list is what I was referring to here -- I think this is just a subset of the global attributes, but CMOR uses this to ensure that the ones that have to be there are there.

• do you have strong opinions on spelling i.e. whether it is initialization index or initialisation index?

I suspect that making a change would be something that modelling groups and infrastructure providers would have to adapt to and 'z' is used in the global attributes document. I think if you check through the spelling of many fields from CMIP6 you'll find American English spellings used throughout (which has caught a few people out on occasion)

• what is source type?

Ooh, I hadn't realised that this had been quietly dropped -- it might be worth adding a list of fields that have been dropped since CMIP6 to the guidance pages. In CMIP6 there was a combination of codes to add to this field to describe the features of the model being used, e.g. AGCM AER would be an atmosphere only model with an aerosol scheme. The description of this field in the CMIP6 docs was

added partly because obs4MIPs defines this (e.g., “in-situ”); This should describe the model most directly 
responsible for the output (e.g., for dynamical downscaling output, it would describe the regional model, 
not the global model responsible for driving the regional model). Sometimes it is appropriate to list two 
(or more) model types here. Used in faceted searches.

I think you can remove this from the lists above, but I should look at the examples in with the CMOR tables to remove this (issue raised)

[znichollscr]

Sorry - indentation needed here. in the License text there is a terms of use link pointing at PCMDI pages -- we need to either remove or update the link

Got it

the required_global_attributes list is what I was referring to here -- I think this is just a subset of the global attributes, but CMOR uses this to ensure that the ones that have to be there are there.

Yep nice.

I suspect that making a change...

Yep let's stick with american then

I think you can remove this from the lists above, but I should look at the examples in with the CMOR tables to remove this (issue raised)

Ok great. Given it's a search facet, it feels like a front-end thing to me i.e. ideally something we can drop from the CVs' to-do list

[znichollscr]

Ooh, I hadn't realised that this had been quietly dropped...

Thinking about source type more. My view is that it's still not needed. If, for some reason, it is essential (I have thought about this a bit and can't see why), we do actually still have all the information in source via the model components. (If this is meant for search, the smarter solution to me seems to be to use the source value from the file combined with esgvoc to get the source type information for search interfaces after the data is published. This means users can still search, but we don't force ourselves to put this information in the file which, if we get it wrong, means the only way to fix it is to re-publish the entire file (which no-one will do for an issue which only affects metadata). Honestly, this logic can probably be applied to lots of fields, so I think we can keep the required attributes list as is without causing problems and while giving ourselves a lot more options than in previous phases.)

[znichollscr]

Sorry - indentation needed here. in the License text there is a terms of use link pointing at PCMDI pages -- we need to either remove or update the link

@matthew-mizielinski where should the link point to?