CF Roadmap - Vocabularies management & development

[efisher008]

Topic for discussion

@japamment @feggleton @efisher008

Considerations:

• What is our longer term vision for interoperability with other controlled vocabularies for parameter naming (not governed by CF)
• Are units part of vocabulary management in terms of providing interoperability (UDunits/UCUM/QUDT, etc)?

More detail to follow...

Mid/end October deadline for meeting to give status updates on this section of the roadmap.

[efisher008]

Further items for discussion/inclusion in this section:

• Pointing to external domain-specific controlled vocabularies i.e. chemistry, biological taxa, modelling & observational quantities
• Implementation of I-ADOPT framework ontology (ensuring CF standard names are interoperable)
• Prevalence of open source repositories for vocabularies - what is out there? Does CF have a responsibility to scope this?
• Overlap with NVS vocabs - not replicating terms between collections, pointing to what exists
• Using NVS P07 as the canonical source of CF standard names - summarising outcome of this discussion

[davidhassell]

Hello,

The second half (24-25 September) of the 2025 CF workshop is dedicated to the CF roadmap, including hackathons dedicated to advancing the road map topics. These hackathons have no pre-determined structure and can be used for anything from further debate to writing an actual proposal - whatever would be most useful the topic at this time.

If there is interest in working on this roadmap topic in this way, please let us know in a comment on this discussion soon, so that we can advertise it on the meeting agenda - this is a good opportunity to possibly bring in fresh ideas from people who may not yet have engaged with the roadmap.

Thanks, on behalf of the workshop committee.

[japamment]

I would be willing to organise a hackathon on this topic as I feel we still need to make progress on vocabulary interoperability.

[mkavulich]

Hi, I represent the efforts of the ESM Standard Names committee, which is an extension of the CF standard names for use in the Common Community Physics Package, JEDI, and potentially other future applications in Earth Systems Modeling, especially in the Unified Forecast System ecosystem. While our vocabulary is mostly a back-compatible extension of the CF Standard Names, we do have some deviations, and we could certainly benefit from any interoperability efforts that are underway, especially with regards to software at the interfaces between different naming conventions. I'd love to engage with any ongoing or future efforts in this vein.

[JonathanGregory]

@mkavulich, thank you for your comment. It would be helpful to hear about the kinds of extension you have made to standard names, and why you decided to deviate from them. Have you or your colleagues previously raised CF issues about these needs?

[mkavulich]

@JonathanGregory This was originally borne out of the needs of the CCPP project around 5 years ago. We control the flow of information between different physics schemes and the host model via metadata, and we required specifications beyond and more fine-grained than the CF conventions allowed. For example, some information is explicitly encoded in many of our standard names, such as:

• dimensionality (variables at vertical layer centers vs interfaces, e.g. air_pressure_at_surface_adjacent_layer, geopotential_at_interfaces)
• timing (e.g. air_pressure_at_surface_on_previous_timestep, air_temperature_two_timesteps_back)
• specific process and origin (e.g. tendency_of_x_wind_due_to_model_physics, absolute_momentum_flux_due_to_nonorographic_gwd)

In addition, there are many flags and control variables that do not seem to fit in CF conventions, e.g. namelist options like do_myj_pbl_scheme and control_for_edmf_in_mynn_pbl_scheme

I did not join the project until after this time, so I do not know if there were any conversations with members of the CF conventions committee at that time, but the decision was made that this was well beyond the scope of the existing CF standard names (we have well over 1000 names outside of the CF standard) and it made sense to maintain our own dictionary. In the years since, JEDI has adopted this standard and other projects have expressed interest, so the dictionary was renamed from CCPPStandardNames --> ESMStandardNames, and we convened a committee representing all interested parties that meets on a roughly biweekly basis.

I'm happy to answer any more questions or engage in further dialog, so please reach out if you like! My email is kavulich@ucar.edu

[taylor13]

Some of these names (especially, dimensionality and timing) provide information that in CF normally would be recorded by other means. Your full vocabulary could be accommodated by CF by assigning the specialized terms you need to long_name. Datasets conforming to your requirements could rely on long_name to then uniquely identify your variables. If you wanted the larger CF community to interpret these terms, they would have to be added to the CF standard names list. If the "rules" governing standard names fall short of the kinds of consideration needed to describe your variables, then it would be good to propose how to augment those rules.

I think it is a mistake to stand up an alternative "standard_name" list. When there are two different lists, that breaks the "standard". I hope that over time, the names developed by JEDI will be proposed as CF standard_names and through the established procedures, the ones that are needed can be accepted.

I also hope we can avoid confusion about your list of "standard names" being somehow part of CF. I think casual users of both CF and JEDI will not understand the fundamental differences between these two sets of names. Could you call your names "JEDI variable names" (or "JEDI variable identifiers"), or something similar, that would distinguish them from the official CF standard names?

[JonathanGregory]

Dear Michael @mkavulich

Thanks for your reply. I agree with Karl about the importance of not confusing these names with CF standard names. If there's a string in the standard_name attribute that doesn't come from the CF standard name table, the dataset is erroneous according to the CF convention. On the other hand, CF doesn't require data variables to have a standard_name attribute. You can comply with CF if you put these strings, standardised for your project, in an attribute of any name that isn't standardised by CF.

Even better, to the benefit of all, would be to work towards incorporating your metadata needs into the CF convention and standard name table, if it's appropriate. Indeed, it might not be appropriate in cases which are of very restricted use, but it's always debatable whether a use-case has sufficient currency for inclusion in CF.

Best wishes

Jonathan