Feature/id mapping

[mikekucera]

General information

Associated issues: bridgedb/BridgeDb#112

Checklist

Author:

• One or more reviewers have been assigned.
• Automated tests have been included in this pull request, if possible, for the new feature(s) or bug fix.
• The associated GitHub issues are included (above).
• Notes have been included (below).

Reviewers:

• All automated checks are passing (green check next to latest commit).
• At least one reviewer has signed off on the pull request. Reviewers have two business days to review the pull request, after which the author may merge in the pull request unilaterally.

Notes

Adds Ensembl ID mapping...

• Detects Ensembl IDs and makes a call to the BridgeDB service to map them to HGNC IDs.
• The UI displays the HGNC names.
• Logs any IDs that failed to get mapped in Sentry.
• The ClassChooser component now automatically sets non-numeric columns to "ignored".
• The sample data file 'GSE129943_rsem_counts_2016.txt' is now (finally) able to round-trip through the services and produces a usable network.
• Note an update to the FGSEA service is required. I don't want to push the change to FGSEA yet because it will automatically get deployed before this pull request is approved.

[maxkfranz]

Looks great. I suppose the main thing in merging this would be coordinating the timing with the FGSEA merge, as you mentioned.

Were there any things that stood out to you re. BirdgeDB? Any problems? Anything we should log for future? It looks straightforward to me at first glance, but you'd have a better sense of the details.

Unless you have something you'd like to raise or ask specifically, I think we should just merge this in.

[mikekucera]

No major problems using BridgeDB. I couple things to mention would be...

1. the endpoint has a query parameter to limit the results to a particular type, like HGNC, but it doesn't work. I get back a list of IDs for each Ensembl id and have to parse it. But its no big deal.
2. The sample data file from Ruth has 39% of the Ensembl ids not mappable (22594 of 57906). That file is from 2016 so probably not something to be concerned about but worth mentioning.

We should probably do better data validation up front at some point. Things like blank lines, randomly corrupted lines, or anything else will probably error out in the FGSEA service. It would be cleaner to catch all that on the client and report errors properly. But that's work that we can punt.

[maxkfranz]

OK, I’ll kick off an issue for preemptive client-side data validation tomorrow. We can use it to keep notes until we plan out the details. I’ll ask Ruth and Veronique if they have a newer file. It would be nice to have one that's a bit more representative. As for BridgeDB, it looks like it may be a known issue — although it doesn’t block us as you said: bridgedb/BridgeDbR#33

…

On Apr 25, 2023, at 19:39, Mike Kucera ***@***.***> wrote: No major problems using BridgeDB. I couple things to mention would be... the endpoint has a query parameter to limit the results to a particular type, like HGNC, but it doesn't work. I get back a list of IDs for each Ensembl id and have to parse it. But its no big deal. The sample data file from Ruth has 39% of the Ensembl ids not mappable (22594 of 57906). That file is from 2016 so probably not something to be concerned about but worth mentioning. We should probably do better data validation up front at some point. Things like blank lines, randomly corrupted lines, or anything else will probably error out in the FGSEA service. It would be cleaner to catch all that on the client and report errors properly. But that's work that we can punt. — Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHRO45EOPR3I4COISBAZDLXDBOBTANCNFSM6AAAAAAXKA2GYQ>. You are receiving this because your review was requested.

[maxkfranz]

It looks like this issue already addresses validation: Improved validation of input files bridgedb/BridgeDb#42