Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement querying ZOOMA to get possible mappings for a trait #30

Closed
tskir opened this issue Jun 6, 2020 · 8 comments · Fixed by #49
Closed

Implement querying ZOOMA to get possible mappings for a trait #30

tskir opened this issue Jun 6, 2020 · 8 comments · Fixed by #49
Labels
Priority: High Should be prioritised over other issues Scope: Backend Backend logic & data processing scripts

Comments

@tskir
Copy link
Member

tskir commented Jun 6, 2020

This should essentially be done by copying the code from the main Open Targets repository, specifically from the trait_mapping directory.

@tskir tskir added Priority: High Should be prioritised over other issues Scope: Backend Backend logic & data processing scripts labels Jun 6, 2020
@joj0s joj0s added this to To do in Project Progress Jun 7, 2020
@joj0s joj0s moved this from To do to In progress in Project Progress Jun 12, 2020
@joj0s
Copy link
Collaborator

joj0s commented Jun 16, 2020

When should we trigger ZOOMA queries? My guess is whenever a new trait is being imported?

@tskir
Copy link
Member Author

tskir commented Jun 17, 2020

When should we trigger ZOOMA queries? My guess is whenever a new trait is being imported?

Yeah, that's a good question. Currently we have ClinVar, OLS and ZOOMA queries, and eventually we should have a situation where:

  • Each import can be triggered manually and separately. E.g. there will be buttons "Update ClinVar", "Update OLS", "Update ZOOMA" etc. which will trigger full updates from the respective datasources.
  • Also, some imports will probably trigger other imports for a subset of records. For example, when we do ClinVar import, it makes sense to also do OLS and ZOOMA queries at least for the newly added records.

So here's what we are going to do. For this ticket, it's enough to just implement the functionality itself, and add an "Update ZOOMA" button somewhere which will trigger the full manual import.

For the future, we have issue #32 which is about a UI mockup of a page to display import status and all those buttons for triggering imports. When we get to this part, let's use that issue to discuss which imports will trigger each other under which circumstances.

@joj0s
Copy link
Collaborator

joj0s commented Jun 18, 2020

After reviewing the code you linked, I think that it contains a lot more functionality than we currently need. Would it be ok if I created my own code to get ZOOMA suggestions and used this code as help?

Also, we currently don't have any fields in the DB model for ZOOMA confidence. Do we need that?

@tskir
Copy link
Member Author

tskir commented Jun 18, 2020

After reviewing the code you linked, I think that it contains a lot more functionality than we currently need.

Eventually we are looking to port all functionality from there, including the entire trait mapping pipeline. One way this could work is that, if the pipeline considers the mapping to be of "high quality", it will assign it automatically and move the trait directly into review (rather than starting with the unmapped status). However, in this ticket it's fine to only implement the core of that functionality (only querying ZOOMA itself). I've created a follow-up ticket, #44.

Would it be ok if I created my own code to get ZOOMA suggestions and used this code as help?

Yes, that would fine. When convenient, you can also just copy-paste blocks from there and adjust as needed. Once everything is ported into the app, I'll just get rid of that part in the original repository altogether.

Also, we currently don't have any fields in the DB model for ZOOMA confidence. Do we need that?

Yes, it would be useful. We need to store and display it. You can either implement it here or do it in #44, whichever is more convenient.

@joj0s
Copy link
Collaborator

joj0s commented Jun 19, 2020

Alright so to define the scope of this and #44, this issue regards querying ZOOMA and getting back the results, and #44 regards automatically mapping suggestions with HIGH confidence and querying OLS to check the status of the suggestion?

@joj0s
Copy link
Collaborator

joj0s commented Jun 19, 2020

Also am I missing something regarding ontology filtering in Zooma? For example this request http://www.ebi.ac.uk/spot/zooma/v2/api/services/annotate?propertyValue=cerebral+creatine+deficiency+syndrome&filter=ontologies:[efo]
should return only EFO terms or nothing, but instead returns an Orphanet one. I am confused because this is how the ontology filters are built in the trait_mapping directory you provided.

@joj0s
Copy link
Collaborator

joj0s commented Jun 19, 2020

Also am I missing something regarding ontology filtering in Zooma? For example this request http://www.ebi.ac.uk/spot/zooma/v2/api/services/annotate?propertyValue=cerebral+creatine+deficiency+syndrome&filter=ontologies:[efo]
should return only EFO terms or nothing, but instead returns an Orphanet one. I am confused because this is how the ontology filters are built in the trait_mapping directory you provided.

Nevermind, it turns out I have to first specify the 'required' filter as none to have the ontologies filter working

@tskir
Copy link
Member Author

tskir commented Jun 20, 2020

Alright so to define the scope of this and #44, this issue regards querying ZOOMA and getting back the results, and #44 regards automatically mapping suggestions with HIGH confidence and querying OLS to check the status of the suggestion?

That's right.

Nevermind, it turns out I have to first specify the 'required' filter as none to have the ontologies filter working

Yes. If I remember correctly, there should be two fields, once specifies the filter and another one the priority order of the different ontologies.

@joj0s joj0s moved this from In progress to In review in Project Progress Jun 30, 2020
@tskir tskir closed this as completed in #49 Jul 4, 2020
Project Progress automation moved this from In review to Done Jul 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: High Should be prioritised over other issues Scope: Backend Backend logic & data processing scripts
Projects
Development

Successfully merging a pull request may close this issue.

2 participants