Open matamadio opened 10 months ago
From a non-expert point of view, it seems to me like that type of data better fits the description of exposure
:
Metadata that is specific to datasets that describe the situation of people, infrastructure, housing, production capacities and other tangible human assets located in hazard-prone areas.
Would it make sense to model those as exposure datasets?
There's no right answer; indeed these are properties of exposure, but they are used to model its vulnerability (see paper example). It might be easier to fit in the exposure schema, in terms of data type and associated properties.
From today's check-in call, agreed that this requires further discussion and won't be done as part of 0.2.
I agree it could fit into exposure
, and #256, which creates exposure_category
for social / economic indexes could address this, by allowing these index values as exposure category.
My suggestion: when data are clearly a social indicator like relative wealth index, it should be put into exposure
.
When a vulnerability index combining multiple factors has been created to measure vulnerability specifically to one or more hazards, it can go into vulnerability
.
My suggestion: when data are clearly a social indicator like relative wealth index, it should be put into
exposure
. When a vulnerability index combining multiple factors has been created to measure vulnerability specifically to one or more hazards, it can go intovulnerability
.
In practice, we need to understand how to fit it in the function-oriented V schema without dumbing it down.
What is the context or reason for the change?
There vulnerability component has several mandatory fields meant to describe a vulnerability function, e.g. the type of hazard and exp they apply to. In the same component, we also aim to accomodate _secategory which is a different kind of object; not a function but a geospatial layer or just a table with location values. Some examples:
Since these aren't model that connect hazard and exp values, the mandatory attributes of the schema can't be met:
What is your proposed change?
I don't see many options. Either:
Suggestions are welcome!