SO term listed instead of "Missense variant" on Evidence page (Genetic associations)

[ElaineMcA]

We no longer list "missense variant" etc, but rather its SO term e.g. https://www.targetvalidation.org/evidence/ENSG00000258839/EFO_0000756?view=sec:genetic_association Whereas for rare variants we have now a mix of SO term and trinucleotide expansion, although the latter has a SO term as well i.e. SO_0002165 e.g. https://www.targetvalidation.org/evidence/ENSG00000102081/Orphanet_908?view=sec:genetic_association

Although the users can hover and click on the '?' in the column name for the common diseases and be redirected to the /variants page where the user will find out what SO 0001583 means...

this functionality (of being redirected to /variants page and find out what the SO term is) is not available for rare diseases (or the rare variants section):

(reported by @deniseOme on 2nd Jan 2019)

[ElaineMcA]

@LucaFumis initial investigations:

Seems like it could be an issue with one of the OT util services - perhaps otUtils.getEcoLabel

The thing is in the response we pick “gene2variant”: { “functional_consequence”: “http://purl.obolibrary.org/obo/SO_0001583” and look it up in the response for a more human friendly description but there isn’t anything…

"evidence_codes_info": [
[
{
"eco_id": "GWAS",
"label": "Genome-wide association study evidence"
}
],
[
{
"eco_id": "cttv_mapping_pipeline",
"label": "CTTV-custom annotation pipeline"
}
],
[
{
"eco_id": "ECO_0000205",
"label": "curator inference"
}
]
],```
So in there we look for ‘SO_0001583’
but there isn’t anything.

[LucaFumis]

Just to elaborate a little on the initial investigation (apologies my English was a little "rusty").

The function otUtils.getEcoLabel is a convenience method that looks up a code in an array. It takes the following from the API response:

1. evidence.evidence_codes_info that's the list of code-labels as per comment above
2. evidence.gene2variant.functional_consequence from which we extract the code at the end of the string, e.g. SO_0001583 in http://purl.obolibrary.org/obo/SO_0001583

If the code is not in the array, it just returns the code. This is what's happening here.

[afaulconbridge]

This might be a data thing too. I know there are fake ontology terms are passed straight to the UI from evidence strings. We should return both the ontology URI and the human readable label in the API and then the UI can display a hyperlink.

[ElaineMcA]

19 may be related. Needs to be investigated fully with 19.02 in mind.

• issue from data provider or pipeline? TBD.

Training on 31Jan2019 - options (i) FE workaround (ii) amend training pending 19.02 release.

[iandunham]

This needs fixing - Do we only get the labels from the evidence_codes_info array, or are we supposed to get them from the service i.e. http://www.ontobee.org/ontology/SO?iri=http://purl.obolibrary.org/obo/SO_0001583

If the former we must not be building this correctly

[afaulconbridge]

There is the ECO elasticsearch index, which is already used by the rest API elsewhere. I think the simplest solution is to use that to lookup labels instead of the hard-coded static mapping.

[mkarmona]

@iandunham @ElaineMcA @LucaFumis It will be addressed by this issue #388 and this PR

[ElaineMcA]

Now requires pipeline rerun to resolve - this will be coordinated to include fixes (i.e. #382 )ongoing post 18.12.

[Docproc]

Just to add that we spotted this with the Genomics England tiering data as well.

[ElaineMcA]

382 and this ticket will be resolved in production once 18.12.05 pipeline code containing the fixes has been re-run.

[ElaineMcA]

QA approved 17Jan2019. Ready to push to production.