Review loss metadata modelling

[duncandewhurst]

The discussion and examples from https://github.com/GFDRR/rdl-standard/issues/135#issuecomment-1708577671 are very useful in clarifying the requirements for the loss component. After reviewing, I think that there are opportunities to improve the modelling of loss metadata so I'm sharing some initial thoughts below:

• .category: This field might need to be an array since, based on page 32 of the technical report associated with the Central Asia seismic risk Return Period summaries, it seems like one set of losses can cover multiple categories:

• cost: See comments in https://github.com/GFDRR/rdl-standard/issues/135#issuecomment-1709378039. Also need to consider the relationship between cost.dimension and .category.
• .impact: Suggest aligning metrics modelling between exposure and loss. Also need to use consistent terminology (losses rather than impact?)
• .type (loss_type codelist): We should review the semantics of this field and its codes because there seems to be quite a lot of cross-over with the impact_metric codelist and the code descriptions mix at least two different concepts:
  • The kind of quantity being measured (monetary amounts or counts)
  • How different types of insurance and reinsurance are accounted for in the losses
• impact.base_data_type, .approach, .hazard_analysis_type: Revist modelling and codelists to reduce semantic cross-over (see comments in https://github.com/GFDRR/rdl-standard/issues/135#issuecomment-1709378039)

[stufraser1]

.category: This field might need to be an array

Yes

.impact: Suggest aligning metrics modelling between exposure and loss. Also need to use consistent terminology (losses rather than impact?)

Lets keep this as it is at the moment.

loss.type cross-over with loss.impact.metric

Agreed - the followinng list would work under loss.impact.metric to define the type of information. When used with loss.impact.unit (requires addition of 'cost' and possibly 'index') will tell us whether its a cost value, ratio, count, index, etc. And we can remove loss.type. Suggested loss.impact.metric codelist: damage probability downtime casualties displaced_people economic_loss insured_ground_up_loss insured_gross_loss insured_net_precat_loss insured_net_postcat_loss at_risk_value at_risk_tail_value

cost: need to consider the relationship between cost.dimension and .category.

Curent cost.dimension: structure, content, product, disruption, population Curent .category: agriculture, buildings, infrastructure, population, natural_environment combined into a one or many .category: agriculture_crop, agriculture_livestock, buildings, content, product, disruption, infrastructure, population, natural_environment Tihs shhould work for Exposure.category too

impact.base_data_type, .approach, .hazard_analysis_type: Revisit modelling and codelists to reduce semantic cross-over

loss/impact/base_data_type: inferred, observed, simulated loss/approach: hybrid, analytical, empirical loss/hazard_analysis_type, deterministic, empirical, probabilistic, judgement I thihnkn we remove loss/approach - this is needed in Vulnerability but doesn't make sense in Loss component. loss/hazard_analysis_type should be renamed loss/analysis_type - it does not only refer to hazard component but the whole risk analysis process.

[matamadio]

Agree on the proposal.

.category: This field might need to be an array since, based on page 32 of the technical report associated with the Central Asia seismic risk Return Period summaries, it seems like one set of losses can cover multiple categories.

One loss dataset can cover multiple hazard types and exposure categories.

.impact: Suggest aligning metrics modelling between exposure and loss. Also need to use consistent terminology (losses rather than impact?)

I would maintain the distinction as losses are calculated from (one or usually more) impacts, as they are not the same thing.

Curent cost.dimension: structure, content, product, disruption, population Curent .category: agriculture, buildings, infrastructure, population, natural_environment combined into a one or many .category: agriculture_crop, agriculture_livestock, buildings, content, product, disruption, infrastructure, population, natural_environment. This should work for Exposure.category too

Makes sense to me. Content is related to buildings as opposed to building's structure, thus I would specify it and reorder as:

.category: building_structure, building_content, infrastructure, agriculture_crop, agriculture_livestock, population, product, disruption, natural_environment.

loss/impact/base_data_type: inferred, observed, simulated loss/approach: hybrid, analytical, empirical loss/hazard_analysis_type: deterministic, empirical, probabilistic, judgement I think we remove loss/approach - this is needed in Vulnerability but doesn't make sense in Loss component. loss/hazard_analysis_type should be renamed loss/analysis_type - it does not only refer to hazard component but the whole risk analysis process.

Agree to have just one approach/analysis_type attribute for the whole risk process. Codelist could be either:

1. simulated, inferred, observed
2. analytical, deterministic, empirical

[matamadio]

Pinning the issue as priority for next release - this is crititcal to be able to release Loss datasets. @stufraser1 should we plan a crunch on this?