TRAPI 1.4 validation error: gain / loss of function qualifiers for Gene -> Disease

[colleenXu]

I was doing a quick performance review of the new BTE "treats" templates, and I used my notebook to run TRAPI validation on some responses (attached below):

• Timothy syndrome MONDO:0010979: timothy-syndrome.txt
• nephrotic syndrome MONDO:0005377: nephrotic.txt
• Familial dysautonomia / Riley-Day syndrome MONDO:0009131: riley-day.txt
• Huntington's disease MONDO:0007739: huntington.txt

For all 4 of these responses, the reasoner-validator raises the error: error.knowledge_graph.edge.qualifiers.qualifier.value.unresolved. Note that "errors" are "orange" in the ARAX UI, vs the red for "critical" errors.

This occurs on KG Edges from Text-Mining Targeted like these:

• (subject_form_or_variant_qualifier: loss_of_function_variant_form) Gene -> affects -> Disease
• (subject_form_or_variant_qualifier: gain_of_function_variant_form) Gene -> affects -> Disease

Example error code and object from my notebook (python):

error.knowledge_graph.edge.qualifiers.qualifier.value.unresolved

{'infores:text-mining-provider-targeted -> infores:biothings-explorer': {'gain_of_function_variant_form': [{'edge_id': 'NCBIGene:775[biolink:Gene]--biolink:affects->MONDO:0010979[biolink:Disease]',
    'qualifier_type_id': 'biolink:subject_form_or_variant_qualifier'},
   {'edge_id': 'NCBIGene:6330[biolink:Gene]--biolink:affects->MONDO:0010979[biolink:Disease]',
    'qualifier_type_id': 'biolink:subject_form_or_variant_qualifier'},
   {'edge_id': 'NCBIGene:857[biolink:Gene]--biolink:affects->MONDO:0010979[biolink:Disease]',
    'qualifier_type_id': 'biolink:subject_form_or_variant_qualifier'}]}}

---

As far as I can tell, this error has to do with the reasoner-validator and data-modeling (biolink-model + text-mining KP).

Reasoner-validator may depend on biolink-model having an association object that matches these Edges AND sets the values for its "subject form or variant qualifier".

• There is a very similar association object (uses contributes_to as the predicate), but it doesn't set values for the""subject form or variant qualifier". When I try to match the KG edges to this association (by replacing the affects predicate with contributes_to), the error still occurs.
• In comparison: the two chem-gene association objects set the "subject form or variant qualifier" range here and here.
• This is reminding me of a previous issue regarding the values qualifiers can have fix: chemical-affects-gene-association aspect qualifier range biolink/biolink-model#1362

[colleenXu]

@tokebe @andrewsu

These edges are occurring because of the templates intended to make the directionality of m4-Chem-Gene-DoP.json more specific.

• see templateGroups.json changes in PR
• Chem-increaseGeneWithFunctionLossIn-Disease
• Chem-decreaseGeneWithFunctionGainIn-Disease.

What do you think we should do?

• I'd prefer to keep these templates, since users have been asking for info like this for a long time. However, I'm not sure if this TRAPI validation error is a hint of any issues downstream...
• I think this should be brought up with Text-Mining Provider and that they should take the lead on data-modeling / reasoner-validator discussions.

[andrewsu]

Based on the discussion in this slack thread, we should undo our roll out of templates that take advantage of "directionality" in Gene/Variant -> Disease edges. Unfortunately, it's just not ready from a data modeling perspective...

[colleenXu]

We decided to remove the two templates with "more specific directionality with qualifiers" from the "treats" template group, because of TRAPI validation / data-modeling concerns. This leaves us w/ 3 templates.

I confirmed that removal of the templates addresses this issue. When all 4 of the example diseases were reran, their responses didn't trigger any validation errors.

Example: rerun timothy syndrome response: new_timothy.txt

---

Done editing the linked comment. No TRAPI errors (critical or normal) encountered at all!

[tokebe]

Closing this one as complete -- future tracking of the potential change that was rolled back can be done from #704