[ensembl-dev] inconsistency when mapping the same variant from protein to genomics vs genomics to protein
David Tamborero
david.tamborero at gmail.com
Thu Jan 10 11:08:41 GMT 2019
that s great, thanks Sarah !
I will indeed come back with other issues if I found any, although for the
moment I will move to other tools to address HGVS processing issues.
It would be indeed great if the Ensembl tools can cover that in the future!
likely an API (as variant recoder) and not VEP should address these tasks,
but it is important for VEP to not provide results that may be
confusing/misinterpreted for the operations that are attempted.
thanks again for your great work!
br
d
El mié., 2 ene. 2019 a las 13:14, Sarah Hunt (<seh at ebi.ac.uk>) escribió:
>
> Hi David,
>
> Thanks for passing this on. Our March release of VEP will include a check
> that the transcript picked to map the variant from gene+protein change to
> genomic sequence is compatible with the reference allele supplied. As
> Andrew says, we aim to add VCF output to VariantRecoder in the future too.
>
> Do let us know if you come across any other examples which do not behave
> as you expect. While we may not be able to support some of the stranger and
> more vague HGVS-like descriptions, we are very interested to know about and
> consider common use cases.
>
> Best wishes,
>
> Sarah
>
>
> On 30/12/2018 02:22, David Tamborero wrote:
>
> (Sorry for the late response, i m currenrly with no much internet access)
>
> Thanks Andrew for your answer. I m a bit surprised of the general lack of
> tools addressing these issues. Maybe it is not that required by the
> community, although i would say the contrary.
>
> In any case, i will be tuned to see whether your next releases can address
> some of them.
>
> Thanks again!
> Br
> D
>
>
> El vie., 21 dic. 2018 20:57, Andrew Parton <aparton at ebi.ac.uk> escribió:
>
>> Hi David,
>>
>> 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.
>>
>> 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.
>>
>> Kind Regards,
>> Andrew
>>
>>
>>
>>
>> On 17 Dec 2018, at 15:24, David Tamborero <david.tamborero at gmail.com>
>> wrote:
>>
>> thanks for your answer!
>>
>> 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.
>>
>> 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.
>>
>> 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)?
>>
>> many thanks for your time (and your work!)
>> best regards from Stockholm
>> d
>>
>> El dom., 16 dic. 2018 a las 14:19, Andrew Parton (<aparton at ebi.ac.uk>)
>> escribió:
>>
>>> Hi David,
>>>
>>> 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: perl vep
>>> -id 'TP53:p.E285V' --database --force_overwrite --hgvs --port 3337
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Sorry that I couldn’t be of more help.
>>>
>>> Kind Regards,
>>> Andrew
>>>
>>>
>>> On 14 Dec 2018, at 18:00, David Tamborero <david.tamborero at gmail.com>
>>> wrote:
>>>
>>> Hi there,
>>>
>>> regarding the conversion from protein to genomic representation
>>> supported by VEP, I ve found a funny case; if I input
>>>
>>> TP53:p.E285V
>>>
>>> VEP gives as output (vcf format)
>>>
>>> 17 7565261 TP53:p.E285V T A
>>>
>>> And then if I input to VEP that vcf entry, I obtain two TP53 protein
>>> annotations:
>>>
>>> downstream_gene_variant for ENST00000359597
>>> missense_variant for ENST00000413465
>>>
>>> However, the missense variant is annotated as 285 Y/F (and not the E/V
>>> that I had at the start !)
>>>
>>> so it looks that some inconsistency happened here, not sure why. Am I
>>> missing some point ?
>>>
>>> thanks in advance!
>>> d
>>>
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list Dev at ensembl.org
>>> Posting guidelines and subscribe/unsubscribe info:
>>> http://lists.ensembl.org/mailman/listinfo/dev
>>> Ensembl Blog: http://www.ensembl.info/
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list Dev at ensembl.org
>>> Posting guidelines and subscribe/unsubscribe info:
>>> http://lists.ensembl.org/mailman/listinfo/dev
>>> Ensembl Blog: http://www.ensembl.info/
>>>
>> _______________________________________________
>> Dev mailing list Dev at ensembl.org
>> Posting guidelines and subscribe/unsubscribe info:
>> http://lists.ensembl.org/mailman/listinfo/dev
>> Ensembl Blog: http://www.ensembl.info/
>>
>>
>> _______________________________________________
>> Dev mailing list Dev at ensembl.org
>> Posting guidelines and subscribe/unsubscribe info:
>> http://lists.ensembl.org/mailman/listinfo/dev
>> Ensembl Blog: http://www.ensembl.info/
>>
>
> _______________________________________________
> Dev mailing list Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/
>
> _______________________________________________
> Dev mailing list Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info:
> http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20190110/0179ada3/attachment.html>
More information about the Dev
mailing list