How to make Vulnerability curves usable for EMIKAT? [VA API]

[DenoBeno]

related to: #13, #7

If we want to make the vulnerability curves usable for the backend processing, we (EMIKAT) would need to know which resources/which references can be used as input for the calculation. But how to do this?

One thing is sure: if we add some machine-readable vulnerability curve material (e.g. a csv table) to dp_vulnerability, this material will ONLY work for very specific resources/references

Let's us look at the simplest case: heat mortality.

hazard = heat.
But which heat index? Maybe consecutive tropical nights? Or consecutive days with temperature above some threshold? Or??
In https://csis.myclimateservice.eu/node/682, we have following types of resources:

• Maximum consecutive days (summer) 75th percentile ensemble mean (${emission_scenario}, ${period})

I suppose this is what we currently use as input to screening calculation, but how would EMIKAT know that these are the right resources? What if someone adds 50th or 90th percentile ressources? What if someone uses the tropical nights instead? - each of these would need a similar but different vulnerability curve. And in how many different forms could this data be presented?

Element@risk = population.
We already had a case where population was disaggregated in three classes. currently we don't use this in the screening package.

risk/impact indices
In a way, this is the smallest of my problems since these indices need to be calculated - they are output, not input. However, we need to know what they are and list them extra in the DP so that they can be visualized.

In short: there are too many possibilities here. we need some simple and robust method that will assure that we (e.g. EMIKAT) match right resources/references with the VA - otherwise this will never work .

And we need to agree what it will be bevore I start designing this in CSIS. :-(

[DenoBeno]

Some thoughts:

1. Explicitly link all the resources that can be used from dp_vulnerability. This would be sufficient but unmaintainable.
2. Explicit linking of the relevant dp_vulnerability node(s) from the ressource. MAybe a bit better but still too much work IMO.
3. Stricter "resource type"/"reference type" definition than what we have today. This might be a way to go, but it could also easily lead to inflation of the types.
4. Strict definition of how each of the resource type/reference type MUST look like and insisting on a very limited number of such types. Realistically something we must do anyway, but very easily broken. Plus, no such limitation needs to be made for the expert data.
5. Explicit linking of resources and dp_vulnerability nodes as part of the data package definition. This might be a bit of a challenge to define, but it could be the best solution. The burden of assuring things fit together is on data package maintainer, our software can then work easily with the data.

Any ideas/comments/recommendations?

[DenoBeno]

Looking further into the possibility 5, what we would need for this is a GUI that allows the user to choose one or more of the resources that are already listed in the data package and link them together. For instance, something like this:

Here H1, H2 etc mean: "hazard resources that are already linked in this data package". So it's not "heat" (taxonomy term) but a specific dp_resource or even a specific dp_reference we are linking her.

Considering the look & feel of this, it doesn't have to look like a table. The "nicest" implementation would be a workflow where the user first chooses one of the dp_vulnerabilities and then the hazard, element at risk and risk/impact choices are already limited to those that might fit. An alternative would be something similar to the way we are tagging the resources now.

Advantage: we already know how to do this...

[DenoBeno]

This may not be absolutely necessary, but it would be good to combine this with "form steps" module (https://www.drupal.org/project/forms_steps):

step 1: define the data package as we have it now (could be cut in more steps if we like it that way...)
step 2: define the relations.

The problem is that the relations can only be defined once the resources have been added to the data package, so we need to save the data package before doing this. With a form step, this would be done automatically.

[DenoBeno]

@fgeyer16 : I have thought of a way to add existing data packages to this workflow once we design it. It's simpler than I thought, see http://driver-pos-ticket.atosresearch.eu/content/please-implement-way-add-existing-entities-workflow and https://www.drupal.org/project/forms_steps/issues/3034105

With some luck, we might get this done through DRIVER+

[p-a-s-c-a-l]

Is this still relevant and feasible? Does it it have a realistic change to become implemented and is it going to provide any benefits for end users of the public screening service? If not, please close.

[p-a-s-c-a-l]

Closed due to inactivity. Re-open if it becomes relevant again.