VCFToJSON: recognise all HGMD accession prefixes in xref - #6
Open
ChristopheH wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
getAnnotSummary()classifies the IDs of the VEP fieldExisting_variationintoxrefusing the prefix of each ID. HGMD is only detected through the prefixCM.HGMD encodes the variant class in the second letter of the accession, so
CMonlycovers missense and nonsense variants:
CMCSCDCICXCRCGCNCLAll the other classes fall in
xref["Unknown"]and raise, for each ID of eachvariant, the warning:
Two consequences: the downstream consumers of the JSON lose the HGMD cross
reference for every non-missense HGMD variant, and the logs of an exome-scale run
are flooded with warnings.
Solution
Replace the chain of
startswith()by a table of patterns and a smallgetXrefDB()helper:The dbSNP and COSMIC patterns are strictly equivalent to the previous
startswith()calls, so their behaviour is unchanged: only the HGMD detection ismodified, which keeps the review surface minimal. The HGMD pattern is anchored on
the trailing digits, since an HGMD accession is always two letters followed by
digits. This recognises every class without capturing the IDs of another database
starting with the same letters.
The
xrefdictionary already declares theHGMDkey: the JSON schema isunchanged.
Behaviour change
One case is classified differently than before: an ID matching
CMbut notfollowed only by digits (for example the GenBank accession
CM000663.2) waspreviously reported as HGMD and is now reported as unknown. This is the intended
outcome, but it is a change and is worth a look during review.
Testing
getXrefDB()returns the expected database on:rs587776767COSV57482192,COSM476,COSN123CM1414230,CS1414230,CD094312,CI012345,CX1234,CR930125,CG1234,CN1234,CL1234None(unknown, as expected):CIVIC123,CM000663.2,ENST00000123,TMP_ESP_1_123,VCV000012345,esv3364878,C1234Version
__version__of the script bumped from2.9.2to2.10.0, since the content ofxrefchanges for files containing non-missense HGMD IDs. Tell me if you wouldrather also bump the package version.