Bring target safety evidence from AOPWiki

[ireneisdoomed]

As a user I want to explore the data include in the AOPWiki in the context of target safety because this source lists human targets that are implicated with adverse outcomes.

Background

This is developed under the umbrella of the target safety project. There is an existing ticket to find a data model for the AOPWiki data (#1605).

Ines has parsed the raw data (in XML format) to a table that enabled her to inspect the data. 2022-12-14_safety-targets-phenotypes_AOPWiki.xlsx

Now that we have it parsed we can integrate it into the current module to follow the safetyLiabilties schema. The intention is that for the next releases to parse directly the XML.

Tasks

• [x] Add the logic to ingest the AOPwiki data from the Excel above to the evidence parsers repo
• [x] Update the documentation

[buniello]

This task issue is also including a task for the Front End team: expose a new column capturing the humanRelevance field - this will be reviewed when the API will be ready for FE to jump in.

[ireneisdoomed]

This data is ingested in the whole safety dataset.

As an example of the type of information we extract from AOPWiki, let's use this pathway: Ether-a-go-go (ERG) voltage-gated potassium channel inhibition leading to reduced survival

1. This is an example safety evidence string we extract for an event that has not been reported in humans:

   {
   "id":"ENSG00000055118",
   "event":"Reduced, survival",
   "datasource":"AOP-Wiki",
   "effects":[
   {
     "direction":"Inhibition"
   }
   ],
   "isHumanApplicable":null,
   "url":"https://aopwiki.org/aops/95"
   }

Here we describe that an inhibition of KCNH2 - a potassium channel that acts as the molecular initiating event, eventually leads to a reduction in the life span.

2. For a human applicable example, we can take Cyp2E1 Activation Leading to Liver Cancer

{
  "id":"ENSG00000100644",
  "event":"Liver Cancer",
  "eventId":"MONDO_0002691",
  "datasource":"AOP-Wiki",
  "effects":[
    {
      "direction":"Activation"
    }
  ],
  "isHumanApplicable":true,
  "url":"https://aopwiki.org/aops/220"
}

Here we describe that an up regulation of HIF1A - a regulator of hypoxia leads to oxidative stress which eventually has a role in liver cancer.

Tagging @BZdrazil and @inessmit who have greatly contributed to this piece of work. The latest data can be explored here gs://otar001-core/TargetSafety/json/safetyLiabilities-2023-01-20.json.gz

[buniello]

Data and BE tasks f0r this ticket have been finalised - @LucaFumis could you please help us with exposing the new humanRelevance field in the context of the safety widget. @ireneisdoomed and myself are happy to discuss details

[buniello]

New header: Human applicability Visualisation: Blue tick when value is true, N/A when value is null - we can re-use blue tick from the Tractability widget.

[ireneisdoomed]

@buniello Probes actually have a star, not a tick. We have ticks in the Tractability widget, for example. Another thing is that we should also be consistent with the way we show a lack of information. Those assessments that do not have the human applicability set to true don't mean that there is negative evidence of their relevance in humans, but that it has not been tested. So instead of leaving them blank, we should show N/A as other places in the Platform.

The intention for the next iteration is to go back to the curated datasets and see if this applicability can be inferred so that we have this assessment beyond AOPWiki.

[buniello]

Thank you @ireneisdoomed - well spotted. I have now updated the instructions for @LucaFumis.

[LucaFumis]

Thank you @ireneisdoomed and @buniello. So do you mean the column should display three values, true | false | null as tick, blank, n/a ? Or for now just two (tick + n/a for everything else)?

[buniello]

During the ChEMBL meeting this morning, we have discussed taking a different approach to visualise these data. This should takes into account that at the moment we are missing the humanRelevance assessment for the other data sources for safety. @LucaFumis and myself have just gone through options for the new approach with a call. I will update this ticket pending further investigation.

[buniello]

In the Team Leads meeting this morning, we have decided not to expose the humanRelevance field in FE for this release. The task will be re-discussed if an assessment of the humanRelevance filed for all safety data sources is scoped in the near future. @LucaFumis