Rework the **MetaValidator** class

[danielhuppmann]

For the ScenarioCompass Initiative processing, we need to extend the MetaValidator:

1. Allow checking not just for a list of values but also value-ranges (upper_bound/lower_bound/range/value/rtol/atol) similar to the DataValidator

2. Configuration from file with the structure like

   - name: Sustainability Concern|Exceeding Prudent Limit For Geological Carbon Storage|World
     meta: Emissions Diagnostics|Cumulative CCS [2020-2100, Gt CO2]
     validation:
       - warning_level: high
         upper_bound: 1490
       - warning_level: medium
         upper_bound: 1290
   # this is a a hard check that the Project meta-indicators must be one item from the list     
   - meta: Project
     values: [ECEMF, ENGAGE, NAVIGATE]

3. Check that any files in the folder validate_meta can be parsed as MetaValidator (similar to the validate_data folder, I think?)

One problem that I see is that the pyam-method set_meta() uses the args name and meta differently.

• pyam: meta is the values, name is the column in the IamDataFrame.meta dataframe
• nomenclature.DataValidator: name is the column that will be assigned by the validation, so I chose meta as the arg-name of the column to be used for the validation (because that column can be accessed as df.meta["Project"]

Any thoughts @phackstock @dc-almeida?

[dc-almeida]

Just to clarify: the challenge is that for pyam, the name means the meta indicator name, and meta its value, whereas DataValidator populates the meta table with name being the field to be validated and meta the verdict of that validation?

[danielhuppmann]

Not quite, sorry for not explaining sufficiently right away...

Doing IamDataFrame.set_meta(name="Column name", meta="foo") will add a column "Column Name" to df.meta where all values are "foo".

For the DataValidator, we use the "name" attribute for the column to be added, so I think we have to keep that consistent with the MetaValidator. So the question is how to name the argument of which meta-column to use for the validation. I'd go for "meta" but wanted to point out that this is not consistent with pyam. Or you suggest a different argument-name...

[phackstock]

Following the eternal advice of the zen of python, in this case the second principle, "explicit is better than implicit", I'd suggest using meta_column_name (or meta_column_to_validate) in the definition of the validator, so the above example would be:

- name: Sustainability Concern|Exceeding Prudent Limit For Geological Carbon Storage|World
  meta_column_name: Emissions Diagnostics|Cumulative CCS [2020-2100, Gt CO2]
  validation:
    - warning_level: high
      upper_bound: 1490
    - warning_level: medium
      upper_bound: 1290
# this is a a hard check that the Project meta-indicators must be one item from the list     
- meta_column_name: Project
  values: [ECEMF, ENGAGE, NAVIGATE]

[dc-almeida]

Looking into this, MetaCodeList already sets allowed meta indicators (meta column names) and their values.
So, correct me if I'm wrong, that accounts for:

- meta_column_name: Project
  values: [ECEMF, ENGAGE, NAVIGATE]

The remaining validation should resemble DataValidator with ranges/bounds/etc.
Should the hard value check (codelist check) be reimplemented inside the validator?
I can see how it's cleaner/clearer for a user to have all the validation in a single config yaml but it also seems a duplication something already existing.

[danielhuppmann]

I suggest to follow the strategy on the data side:

• have a MetaValidator class to do the actual validation (supporting both values as a list and numerical checks)
• add a from_codelist() class-method
• refactor the MetaCodeListso that it works as input to the above method
• add MetaValidator.from_codelist(..).apply() to the validation using DataStructureDefinition.validate()

[dc-almeida]

Is it expected to specify other dimensions alongside the meta indicator column, or purely meta? That is, would validation need to filter by both dimension values and meta column name?

[danielhuppmann]

For future reference, as just discussed: the MetaValidator should only focus on the meta dataframe (in a first implementation at least), just as the DataValidator only works on (filtered) data.