<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi David,<div class=""><br class=""></div><div class="">One of the improvements that we could make that would make this process a little easier would be if variant_recoder gave a VCF output, this is something that we will look into. Thanks.</div><div class=""><br class=""></div><div class="">VEP could definitely do a better job of predicting HGVSg from HGVSp. Officially, we require that input HGVS is relative to genomic or transcript coordinates. VEP and Variant Recoder will successfully convert from HGVSp to HGVSg sometimes, but as you’ve noticed, there are distinct improvements that we can make. And while the ability of variant recoder to convert from HGVSp will improve over time, and I’ve added your comments to our list of things to look at in the future, but I can’t guarantee when or even if it’ll happen.</div><div class=""><br class=""></div><div class="">Kind Regards,</div><div class="">Andrew</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 17 Dec 2018, at 15:24, David Tamborero <<a href="mailto:david.tamborero@gmail.com" class="">david.tamborero@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">thanks for your answer!</div><div class=""><br class=""></div><div class="">mmm i understand that the protein representation can lead to a non-univocal genomic mapping, but i m unsure of why VEP tries to infer the genomic coordinates without considering the passed aminoacid of reference, (if this is what is happening !). Note that this particular aminoacid change (TP53:p.E285V) maps to a unique genomic missense mutation in all TP53 transcripts. <br class=""></div><div class=""><br class=""></div><div class="">FYI (likely you know it), but when the mapping is not univocal, is not uncommon for other tools dealing with HGVS to give a guess --which is normally the 'most probable' based on different metrics-- as a first 'hit' (and detail the rest). This is specially needed when dealing with indels. <br class=""></div><div class=""><br class=""></div><div class="">Although maybe this is too complicated for VEP. However, I m still not finding a good way for --by using your tools-- passing from HGVS protein representation to genomic coordinates (in 'vcf format', meaning chr pos ref alt). This is not an uncommon need in the field. If I may use this forum to ask, are you planning to support that in e.g. one of your API (i.e. like the 'hgvs conversor' but supporting the vcf-like output)?</div><div class=""><br class=""></div><div class="">many thanks for your time (and your work!)</div><div class="">best regards from Stockholm</div><div class="">d<br class=""></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">El dom., 16 dic. 2018 a las 14:19, Andrew Parton (<<a href="mailto:aparton@ebi.ac.uk" class="">aparton@ebi.ac.uk</a>>) escribió:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><span class="">Hi David,</span><span class=""><br class=""></span><span class=""><br class=""></span><span class=""></span><span class="">I’ve taken a look at this issue this morning and I think I can see what’s going on. I can reproduce this issue with the query: </span><span class="">perl vep -id 'TP53:p.E285V' --database --force_overwrite --hgvs --port 3337</span><span class=""><br class=""></span><span class=""><br class=""></span><span class="">VEP guesses the genomic location based on this HGVS input (17:7565261), and identifies that overlapping transcript ENST00000413465 has a protein product. However, the 285th amino acid of this transcript is not E, but Y. The alternate allele is guessed by VEP from a collection of options that it has. For example, with the input HGVS 'TP53:p.M237I’, then VEP has 3 potential alternate alleles it can use to do this, by converting the given ATG to one of ATA, ATC or ATT.<br class=""></span><span class=""><br class=""></span><span class="">While VEP supports HGVS input, due to the complexity of HGVS and the variety of ways in which people use it, then we require that input HGVS is relative to genomic or transcript coordinates. In protein cases, we give a best guess where we can, but this is not guaranteed.<br class=""></span><span class=""><br class=""></span><span class="">Sorry that I couldn’t be of more help.<br class=""></span><span class=""><br class=""></span><div class=""><span class="">Kind Regards,</span></div><div class=""><span style="background-color:rgb(255,255,255)" class="">Andrew<br class=""></span><br class=""><br class=""><blockquote type="cite" class="">On 14 Dec 2018, at 18:00, David Tamborero <<a href="mailto:david.tamborero@gmail.com" target="_blank" class="">david.tamborero@gmail.com</a>> wrote:<br class=""><br class="">Hi there, <br class=""><br class="">regarding the conversion from protein to genomic representation supported by VEP, I ve found a funny case; if I input <br class=""><br class="">TP53:p.E285V<br class=""><br class="">VEP gives as output (vcf format)<br class=""><br class="">17 7565261 TP53:p.E285V T A<br class=""><br class="">And then if I input to VEP that vcf entry, I obtain two TP53 protein annotations:<br class=""><br class="">downstream_gene_variant for ENST00000359597<br class="">missense_variant for ENST00000413465<br class=""><br class="">However, the missense variant is annotated as 285 Y/F (and not the E/V that I had at the start !)<br class=""><br class="">so it looks that some inconsistency happened here, not sure why. Am I missing some point ?<br class=""><br class="">thanks in advance!<br class="">d<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">Dev mailing list <a href="mailto:Dev@ensembl.org" target="_blank" class="">Dev@ensembl.org</a><br class="">Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank" class="">http://lists.ensembl.org/mailman/listinfo/dev</a><br class="">Ensembl Blog: <a href="http://www.ensembl.info/" target="_blank" class="">http://www.ensembl.info/</a><br class=""></blockquote><br class=""></div></div>_______________________________________________<br class="">
Dev mailing list <a href="mailto:Dev@ensembl.org" target="_blank" class="">Dev@ensembl.org</a><br class="">
Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev" rel="noreferrer" target="_blank" class="">http://lists.ensembl.org/mailman/listinfo/dev</a><br class="">
Ensembl Blog: <a href="http://www.ensembl.info/" rel="noreferrer" target="_blank" class="">http://www.ensembl.info/</a><br class="">
</blockquote></div>
_______________________________________________<br class="">Dev mailing list <a href="mailto:Dev@ensembl.org" class="">Dev@ensembl.org</a><br class="">Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev" class="">http://lists.ensembl.org/mailman/listinfo/dev</a><br class="">Ensembl Blog: <a href="http://www.ensembl.info/" class="">http://www.ensembl.info/</a><br class=""></div></blockquote></div><br class=""></div></body></html>