Augmenting CVs beyond the basic information captured in CMIP6

[vnaik60]

Can this level of information be captured via CVs?

[durack1]

Thanks @vnaik60 - this should likely be created across in the CMIP6Plus_CVs so we catch needed data during the first pass, which we're still working on.

@wolfiex @matthew-mizielinski @davidhassell @glevava @taylor13

[durack1]

FYI, the AR6 Table AII.5 needed the information that you have linked to above, in addition to the information in the CMIP6_source_id.json. I note that the AR6 table was built from the AR5 Table 9.A template, and the AR4 Table 8.1 before it, and TAR Table 8.1 before it.

[taylor13]

Perhaps this should also be discussed with the CMIP documentation task team. (David and Guillaume). Don't see why that level of information can't be included in CVs if it is needed.

[glevava]

I'm not sure all these information are strictly what we call "Controlled Vocabulary". For instance answering the question "Is there an active land carbon cycle?" by "Yes/No" is not related to CV. But such a level of information is clearly useful to be included in the *_source_id.json. I agree with @taylor13 this could be easily catched in the MVD to do so. We should think about CV to only define and centralise the typography and syntax of CMIP terms, so that it can be used consistently by other services when necessary, for example for certain elements of model documentation here.

[taylor13]

I agree we should probably make a distinction between "controlled vocabulary" and the more extensive information recorded in some of our CMIP .json files. Most of the CV's are structured as pretty simple json files. In the simplest case we name the vocabulary (e.g., "table_id") and then list all the acceptable values:

    "table_id":[
        "3hr",
        "6hrLev",
        "6hrPlev",
        "6hrPlevPt",
        "AERday",
        "AERhr",
        .
        .
        .

In a slightly more complex case, which I think we can still refer to as a controlled vocabulary, we name the vocabulary (e.g., "acitivity_id") we include short "definitions" of what is meant by each word in the vocabulary:

    "activity_id":{
        "AerChemMIP":"Aerosols and Chemistry Model Intercomparison Project",
        "C4MIP":"Coupled Climate Carbon Cycle Model Intercomparison Project",
        "CDRMIP":"Carbon Dioxide Removal Model Intercomparison Project",
        "CFMIP":"Cloud Feedback Model Intercomparison Project",
         .
         .
         .

There are other json files we have called "controlled vocabularies", but which I think we might better refer to as "registries". Two clear examples are the "experiment_id" file and the "source_id" file.
Would distinguishing between these two types of information (a CV vs. a registry) make sense?
The documentation task team would be concerned first with expanding the "source" registry, and hopefully eventually also help with the experiment registry and help decide how to record how models have "conformed" their simulations to the experiment design.

[durack1]

While I think we should get the nomenclature right, we shouldn't get too buried in the weeds here. If we wanted to be explicit, CMIP should probably be renamed ESMIP (Earth System Model Intercomparison Project), and that's not going to happen.

Following that example, we can refer to the project information in a project_CVs repo, and this information will be a mix of true controlled vocabularies and registered information (registries). We had hoped that reusable (across many projects) "controlled vocabularies" could be migrated upstream to the mip-cmor-tables repo, which means we have e.g. institution registrations in a single place, and these can then be reused across projects (e.g. CCCma is contributing to CMIP3, CMIP5, CMIP6, CMIP6Plus, input4MIPs, ...) so makes sense that "CCCma" the institution_id is registered in a single place, and that same identifier reused, consistently across projects

[vnaik60]

Thanks Paul for tracing the source of the table. This googledoc was sent out to the modeling centers three weeks before the FGD deadline. I brought this up here so that this information is captured in a more formal way in the CMIP model documentation effort.