Support for Vulnerability Curves [VA API]

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

Eventually we would need an API to access and modify the vulnerability curves stored in EMIKAT. ATM we just need some information we can put into the related Data Package Resource for VA.

See also this question: What can we currently put into he Data Package Description? Some static images + a description of the currently available vulnerability curves would be just enough!

[humerh]

As defined by PLINIVS in the Meeting in July in Vienna we dont have vulnerability curces any more. The model of calculation has completly to be changed.

[humerh]

See also: https://newrepository.atosresearch.eu/remote.php/webdav/CLARITY/Events/Project%20Events/Plenary%20Meetings/2019-07-03_05%20Project%20Meeting%20(Vienna)/Presentations/Impact%20modelling%20HW_PLINIVS.pptx

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

So and what do we show on the VA Tab in CSIS? VA is part of the methodology!

Any ideas @bernhardsk @DenoBeno ?

[humerh]

Maybe you can show one (or more) of the diagrams on page 9-11

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

Yes that's what I've asked for here! Maybe @bernhardsk is able to create the respective VA Resource in CSIS?

[humerh]

I cannot help to resolve this issue. Please @DenoBeno OR @patrickkaleta fix this.

[DenoBeno]

I need some time until I can do anything about this. If someone else can work on it, please do.

[DenoBeno]

https://newrepository.atosresearch.eu/remote.php/webdav/CLARITY/Events/Project%20Events/Plenary%20Meetings/2019-07-03_05%20Project%20Meeting%20(Vienna)/Presentations/Impact%20modelling%20HW_PLINIVS.pptx

[DenoBeno]

I have started working on this. There are basically two ways of implementing something "nice" for the vulnerability curves in Drupal:

1. By extending the dp_resource.
2. By adding a new content type.

At least for initial testing, I prefer the second approach. Thus, I have added a dp_vulnerability node type https://csis.myclimateservice.eu/admin/structure/types/manage/dp_vulnerability/fields

The next question is "what should be the data model"? Since the vulnerability links a hazard and element at risk (exposure) with risks and/or impacts, this is how the data model of dp_vulnerability must look like:

**1. Title

2. Some content to visualize (TBD) 3. link to a relevant hazard (or hazards?) 4. link to a relevant element at risk** (or elements at risk?)
3. some indication of a risk/impact this vulnerability curve will result in? (TBD)
4. Configuration file to be used by e.g. EMIKAT? (TBD)

For a start, I decided to implement the following data model, covering just the points 1-4

For a start, simply visualizing some text and an illustration or two should do. We can discuss more complex approaches later.

The next step would be to embed this in the data package. In theory, this could be done by referencing the URI of the relevant dp_vulnerability from the dp_resource, but then we would have to write some javascript applications to present the data.

Alternatively, I could also add the necessary fields directly to dp_resource.

Less drastic approach would be to embed dp_vulnerability in the dp_datapackage in the same way as the Adaptation options:

That is, we could logically treat dp_vulnerability as a "type of" dp_resource If done in this way, it would be easy to add drupal views that visualize the vulnerability curves.

WDYT?

[DenoBeno]

FYI: What I have in mind for the short-term is just to show the vulnerability curves.

In the mid-term, I could follow the same approach as for the adaptation options and add some data to these nodes that can be used by EMIKAT. This would allow us to eventually assure that adding new dp_vulnerability node to a data package (with correct data) is all we need for EMIKAT to calculate the risk/impact.

This is the "ideal" solutions that I have in my mind as a long-term vision for the dp_vulnerability node types.

[patrickkaleta]

... WDYT?

@DenoBeno Short answer: Looks good enough for me!

Couple of notes:

• I would probably prefer the second approach (model vulnerability as own content type) even for a long-term solution
  • 1. reason: would allow us to, at least partially, show vunerabilities without needing a datapackage or resource as context (just like adaptation options)
  • 2. reason: the data model for resources is already pretty big, I wouldn't add anything else to it unless it's absolutely necessary
• in favor of embedding them in the datapackage as entity references and therefore treating them like adaptation options
• regarding the data model structure (and your points 2, 5 and 6), I think we could include @humerh in this discussion
• regarding the data model structure and the cardinality of hazards and el@risk, I think that we should:
  • start of with a 1:1 relation (since it's the easiest and it's not a problem in Drupal to switch a field from a single element to multiple elements) and then later maybe
  • have 1 hazard with (potentially) multiple elements at risk
  • or (potentially) multiple hazards for just 1 element at risk
  • but not mix m hazards with n elements at risk (would probably make it harder for us and just confuse end-users)

[DenoBeno]

First dp_vulnerability defined https://csis.myclimateservice.eu/node/1350 Looks nice IMO

Not sure which hazard this really relates to

[DenoBeno]

I have started looking at the "Impact modelling flooding" description and the first thing that strikes the eye is that this one is talking about:

• one hazard (flood), but which hazard indices?
• FOUR elements at risk (buildings, industrial, roads, agricultural)
• (at least) two risk/impact indices for each combination of hazard & element at risk: direct and indirect damage; each in € and in % of the value

I reckon that we should have just one hazard/element at risk per vulnerability curve, but we could pack several output indices in one dp_vulnerability?

WDYT? What would be the disadvantage if more than one output indicator is packed in?

---

Beyond showing nice pictures to visitors This is already interesting enough, but now comes the next question: 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. this is complex, so I'll open a separate issue for it.

[DenoBeno]

I have implemented a way to associate the vulnerability curves with the data package and also to indicate which resources are used as input and where to look for the output of the risk/impact calculation. This is how it works:

1. I have added several edit forms for the data package. These are called step 1, step 2, ... in anticipation of the workflow module. They can already be used today, just without explicit workflow. Step 1 Step 2 Step 3 Step 4

The "VA relations" is a paragraph consisting of three fields that are filled in using a bit of a views magic.

end result:

the user can indicate what are the inputs (hazard, elements at risk, other) and outputs (risk/impact indicators) related to each of the vulnerability curves they added to the data package.

[DenoBeno]

OK, so we have a possibility to define some vulnerability resources, add them to the DP, and see what has been added on the data package overview page:

https://csis.myclimateservice.eu/node/50

OK, it's rudimentary but it's informative. Unfortunately, none of this is shown in the "vulnerability" step in the study.

[DenoBeno]

I have implemented a "quick and dirty" possibility to show vulnerability functions in the VA step. It's analogous to the way adaptation options table works.

This means that now the user has a possibility to easily decide which VFs to include in the report, the same as for the adaptation options. Only the buttons don't work yet (@patrickkaleta , pls fix.)

[DenoBeno]

Status update Friday, 13/09/2019 Technically, we are "almost there" to provide all the support EMIKAT could ever dream of. IMPLEMENTED

1. It's possible to define Vulnerability function nodes (dp_vulnerability). Attaching the vulnerability function (table) data to this node would be trivial and will be done as soon as it's possible to visualise this data in Drupal (waiting for https://github.com/clarity-h2020/csis/issues/98)
2. It's possible to indicate which vulnerability functions are relevant for the data package.
3. It's possible to indicate which resources are related to these vulnerability function as input and output in the data package. once the https://github.com/clarity-h2020/docker-drupal/issues/114 is resolved, this will work even better
4. It's possible to visualise the vulnerability functions and decide which ones to include in the report. This will work even better once the https://github.com/clarity-h2020/csis/issues/98) is resolved

TODO:

1. Assure that EMIKAT can make use of this information providing this data to EMIKAT is a question of JSON:API, extending the "helpers module" or adding a special view to generate what EMIKAT needs. Not sure how urgent, but it should be done eventually
2. Provide more/better vulnerability functions, including the actual data that's needed for calculations
3. Include this to data package/data packages it's easy to do this for the "expert" data packages, more work for the "screening"
4. various improvements, tbd.
5. other?

[patrickkaleta]

This means that now the user has a possibility to easily decide which VFs to include in the report, the same as for the adaptation options. Only the buttons don't work yet (@patrickkaleta , pls fix.)

Done! Adding Vulnerability functions to a GL-step is now supported by the CSIS helpers module.

[DenoBeno]

@patrickkaleta : indeed add/remove works now.

[DenoBeno]

Now we can very easily implement a simple but functional API for accessing and updating the machine-readable vulnerability curves:

1. Allow the users to attach a csv or json file to the dp_vulnerability
2. This file can be accessed and replaced over JSON:API

Optional but nice and "cheap":

3. Install the the chart suite (https://github.com/clarity-h2020/csis/issues/98) and we can visualise the curves on drupal too.

[DenoBeno]

This is labeled as "in progress" in T1.3. In reality, I have no idea what to do with it now and nobody else is working on it.

[humerh]

After the changes in the calculation of Impact we have no vulnerability curves any more. The new Mortality function was implement already months ago. Someone should close this issue.

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

we have no vulnerability curves any more

OK, closing. But then I don't understand why this has been implemented.

[DenoBeno]

Because we still have something playing the role of the va curve. And I wasn't aware of this change.

On Tue, 15 Oct 2019, 11:13 Pascal Dihé, notifications@github.com wrote:

Closed #13 https://github.com/clarity-h2020/emikat/issues/13.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/clarity-h2020/emikat/issues/13?email_source=notifications&email_token=AAWTC7UYMPTBC4UNQCNRUGDQOWCUZA5CNFSM4H42YX3KYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOUG36UCA#event-2713184776, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWTC7W3A3XO46KNWXLJNSTQOWCUZANCNFSM4H42YX3A .