[ensembl-dev] new VEP REST endpoint

Michael Heuer heuermh at gmail.com
Thu Dec 11 15:16:34 GMT 2014


On Thu, Dec 11, 2014 at 3:07 AM, Will McLaren <wm2 at ebi.ac.uk> wrote:

> You should no longer see the somatic status under the
> transcript_consequences objects; this was a bug and should only appear in
> the colocated_variants objects. I think if you check the output again you
> should see this has already been fixed.
>
> You can always get the reference allele from the allele_string field at
> the root of the JSON object; this is a "/"-separated string where the first
> allele is the reference allele.
>

ok, that works.


The allele given in allele_string and in the variant_allele field are
> always the alleles as input; typically this will be on the forward strand.
> This allows you to easily identify which of the alleles from allele_string
> the variant_allele refers to, particularly useful in the case of input
> variants with multiple alternate alleles.
>
> The HGVS representation is relative to the transcript that it overlaps, so
> if the transcript is on the reverse strand the alleles get
> reverse complemented, hence why A->T becomes T->A in the HGVS string for ENST00000479537
> (a reverse strand transcript, as indicated by "strand: -1"). You can see
> this also in the codons field.
>
> This is maybe clearer if you look at a variant where the ref/alt alleles
> are not the complement of each other, e.g.
> http://rest.ensembl.org/vep/human/id/COSM18443?content-type=application/json&hgvs=1
>

I realized this as soon as I sent that email, that the transcripts were on
the reverse strand.  Sorry for the noise.


The incorrect SO terms have been updated a while ago; those GEMINI
> documents refer to a non-current version of VEP.
>

Great, I'll see if I can get the GEMINI docs updated.

Thank you,

   michael


On 10 December 2014 at 21:55, Michael Heuer <heuermh at gmail.com> wrote:

> On Wed, Dec 10, 2014 at 12:05 PM, Michael Heuer <heuermh at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I'm finally getting the chance to update some code that depends on the
>>> VEP REST endpoint from the beta version to the current production version
>>> and have a few questions.  Looking specifically at this example
>>>
>>>
>>> http://rest.ensembl.org/vep/human/id/COSM476?content-type=application/json
>>>
>>> Under transcript_consequences in this example somatic is "1,1,1".  What
>>> is this supposed to represent?  There are three colocated_variants, so I
>>> assume this is referring to that.
>>>
>>> Under transcript_consequences allele_string="A/T" is now represented as
>>> variant_allele="T".  It would be useful to have a similar
>>> reference_allele="A".
>>>
>>
>> I'm sorry, I might have this backward; COSMIC defines this variation as
>>
>> Mutation Id: COSM476 AA Mutation: p.V600E ( Substitution - Missense ) CDS
>> Mutation: c.1799T>A ( Substitution )
>> http://cancer.sanger.ac.uk/cosmic/mutation/overview?id=476
>>
>> codons/amino_acids and HGVS appear correct but allele_string and
>> variant_allele have it flipped, shouldn't allele_string be "T/A",
>> variant_allele "A" and reference_allele "T"?
>>
>>    "id": "COSM476",
>>    "allele_string": "A/T",
>>
>>    "transcript_consequences": [
>>       {
>>         "variant_allele": "T",
>>
>>         "codons": "gTg/gAg",
>>         "hgvsc": "ENST00000479537.3:c.83T>A",
>>
>>         "amino_acids": "V/E",
>>         "hgvsp": "ENSP00000418033.1:p.Val28Glu",
>>   }
>>
>>    michael
>>
>>
>>
>> _______________________________________________
>> 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/20141211/7cd67531/attachment.html>


More information about the Dev mailing list