[ensembl-dev] VEP - start_lost consequence on first codon of transcripts with incomplete CDS 5'

[Cyriac Kandoth]

Keeping variant consequence separate from the quality of the transcript,
neatly limits the complexity of VEP. A solution for you, might be to pick
and report the consequence of the variant on the "canonical transcript". Or
maybe the transcript that is actually expressed in the tissue you're
studying. This is they motivation behind the --pick and --pick-order
options in VEP:

http://useast.ensembl.org/info/docs/tools/vep/script/vep_options.html#opt_pick

~Cyriac
On Jun 8, 2016 6:37 AM, "Jose M. Gonzalez" <jmg at sanger.ac.uk> wrote:

> Hi,
>
> We have noticed that VEP calls a "start_lost" consequence on variants
> affecting the first codon of transcripts with an incomplete CDS 5', i.e.
> those tagged with a 'cds_start_NF' attribute. In most cases this first
> codon is not even a canonical start codon. Here is an example:
>
> http://www.ensembl.org/Homo_sapiens/Variation/Explore?db=core;g=ENSG00000116198;r=1:3829193-3829524;t=ENST00000461667;v=rs763522630;vdb=variation;vf=129057128
>
> These are partial transcripts for which the true start codon is not known,
> so we believe that a "start_lost" consequence does not seem appropriate in
> this case. Perhaps a consequence such as "missense_variant" or
> "synonymous_variant" would be more adequate for variants falling on these
> codons.
>
> Would it be possible for VEP to handle transcript attributes indicating
> partial length in order to call these types of consequences more accurately?
>
> Thanks,
> Jose
>
> --
> Jose M. Gonzalez
> Senior Bioinformatician - GENCODE
> HAVANA Team
> Wellcome Trust Sanger Institute
> Hinxton, UK
>
>
> _______________________________________________
> 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/20160608/41070013/attachment.html>