GFDRR / rdl-standard

The Risk Data Library Standard (RDLS) is an open data standard to make it easier to work with disaster and climate risk data. It provides a common description of the data used and produced in risk assessments, including hazard, exposure, vulnerability, and modelled loss, or impact, data.
https://docs.riskdatalibrary.org/
Creative Commons Attribution Share Alike 4.0 International
16 stars 1 forks source link

[Proposal] Vulnerability Socio-economy index category codelist #74

Closed odscrachel closed 1 year ago

odscrachel commented 1 year ago

What is your proposed change?

To create a new codelist for field se_category within the vulnerability component. This field appears in DDH_v0.2.xlsx. Link to spreadsheet

Title Field name Description Type Codelist
Socio-economy index category se_category Type of socio-economic index string Economy, Education, Environment, Governance and Institutional Capacity, Health, Infrastructure, Population, Food Security, Risk awareness, Civil Society and Social Capital, Composite index

Unresolved question

Are the se_characteristic or se_indicator fields needed that appear in DDH_v0.2.xlsx?

odscrachel commented 1 year ago

Should the title be 'Socio-economic index category'?

matamadio commented 1 year ago

See this issue already covering the change: #27

Vulnerability is split into independent sub-components

The choice is exclusive, meaning if a dataset is an impact function, it can't be a socio-economic index.

matamadio commented 1 year ago

As from Mover, the SEI description can have 3 different levels of granularity:

Example:

Social Vulnerability Category Social Vulnerability Characteristic Indicator Level 3
Vulnerable population Social class (including caste, religious minority, ethnicity) % of population part of a minority
  Gender – work opportunities % of women in formal employment
  Ratio of average female to male income
  Gender – right to property % of female population who own a house
  % of female population who own land
  % of female population who own a business
  % of female population owning a motorised vehicle
  % of female population with a mobile phone account
  % of female population owning an account with a financial institution
  % of household with a female head (female headed households))

In our proposal, we could keep only the first or the first two levels:

Full list:

Social Vulnerability Category Social Vulnerability Characteristic
Vulnerable population Social class (including caste, religious minority, ethnicity)
  Gender – work opportunities
  Gender – right to property
  Gender – Decision power on well-being
  Sexuality
  Age
  Disability
  Migration
  Involuntary displacement
Institutional Governance Political stability and absence of violence and terrorism
  n. of acts of terror per 1000 population in a year
  Government Effectiveness
  Accountability
  Control of corruption
  Rule of Law
  Voice
Governance in Planning and Construction Risk-informed building coded
  Enforcement of building codes
  Risk-informed planning
Civil Society and Social Capital Social advocacy and civil society
Financial and Material welfare Income -remittances
  Income –disposable income
  Income level
  Employment and employment security
  Financial dependency on environmental resources
  Access to credit
  Poverty
Financial and Material welfare Access to insurance
  Capital assets
  Social Protection
Food Security Availability
  Access
  Stability
  Utilization
Preparedness and Local Risk Awareness Preventive measures
  Knowledge of local hazards
  Civil society and social capital in DRR
  Access to information in DRR
Access and Provision of services Transports
  Water and waste water services
  Telecommunications
  Energy
  Solid waste management
  Affordability
  Access to Emergency Services
Knowledge and education Education attainment
  Access to Education
  Technical skills and vocational training
  Existence of DRR curricula in schools
  Affordability
Health General population health
  Health resources and expenditure
duncandewhurst commented 1 year ago

Where is the proposed codelist in the issue description drawn from?

odscjen commented 1 year ago

Where is the proposed codelist in the issue description drawn from?

The proposed codelist is a combination of values from Mover (see Mattia's comment 2 above this one) and GED4ALL. There was a discussion in the spreadsheet about which we should use, with GED4ALL being the one implied by the current documentation but then not wanting to break compatibility with Mover, hence the new proposal combining the two.

But if we're going to use a codelist that isn't an exact match to Mover AND we also want to keep the Socio-economic vulnerability characteristics (a sub-set of the categories) then we'll need to ensure that this is also compatible with both Mover and GED4ALL.

duncandewhurst commented 1 year ago

If compatibility with Mover and GED4ALL is important and we choose to create a new codelist, we should document mappings from the Mover and GED4ALL codelists to the RDLS codelist so that publishers using those systems know what values to use. Otherwise, each publisher will need to do the mapping themselves. That creates a maintenance overhead because we'll also need to keep the mapping and RDLS codelist up to date with any changes in the Mover and GED4ALL codelists.

An alternative approach is to allow classification against either Mover or GED4ALL using a flexible classifications object, e.g.

{
  "se_category": {
    "description": "Vulnerable population",
    "scheme": "Mover" 
  }
}
{
  "se_category": {
    "description": "Population",
    "scheme": "GED4ALL"
  }
}

@matamadio @stufraser1 would that approach work or would the use of different classifications for different datasets cause problems?

If we were to use the multi-level approach from Mover, having separate fields for category and characteristic would be difficult to validate. We'd need to write an additional check to ensure that the characteristic and category are coherent. An alternative approach would be to have a single field and use a code.subcode structure for the codelist, e.g. 'vulnerablePopulation', 'vulnerablePopulation.socialClass', 'vulnerablePopulation.gender' etc.

Interestingly, the Mover codelist already seems to have an extra level of subcodes within the characteristic level, e.g. Gender – work opportunities, Gender – right to property, and Gender – Decision power on well-being. I wonder why there isn't a similar breakdown for Sexuality, Age, Disability etc.

matamadio commented 1 year ago

If compatibility with Mover and GED4ALL is important and we choose to create a new codelist, we should document mappings from the Mover and GED4ALL codelists to the RDLS codelist so that publishers using those systems know what values to use. Otherwise, each publisher will need to do the mapping themselves. That creates a maintenance overhead because we'll also need to keep the mapping and RDLS codelist up to date with any changes in the Mover and GED4ALL codelists. An alternative approach is to allow classification against either Mover or GED4ALL using a flexible classifications object.

The flexible approach is more in line with what we discussed for taxonomy implementation (see #14, #18).

Interestingly, the Mover codelist already seems to have an extra level of subcodes within the characteristic level, e.g. Gender – work opportunities, Gender – right to property, and Gender – Decision power on well-being. I wonder why there isn't a similar breakdown for Sexuality, Age, Disability etc.

I just added the first ones, but the Indicator Level 3 list goes on for all the Social Vulnerability Characteristic - see last tab in the excel reference from the pre-review version.

stufraser1 commented 1 year ago

@matamadio @stufraser1 would that approach work or would the use of different classifications for different datasets cause problems?

Providing users the option to use different classifications is what is being proposed for exposure taxonomies as Mat says above. It is also the direction we seem to be going in proposing open codelist in #5, so we should be consistent. Advantage of this is we enable more data to be coded using RDLS standard, but while we can encourage users to use consistent taxonomies in each component, we're not increasing data consistency by obliging people to use those.

duncandewhurst commented 1 year ago

Great. Shall we move this to agreed and ready on the basis of using a flexible classifications object then?