[ensembl-dev] precedence of snp consequences

[Will McLaren]

Hi,

Just to add to this, you can find the order of precedence we use in the hash
towards the top of the module Bio::EnsEMBL::Variation::ConsequenceType.

You can import this hash into any scripts you are writing to order your
consequences. You can also call display_consequence() on any variation
feature object to retrieve the most severe consequence type.

Cheers

Will

On 24 January 2011 10:18, Andrea Edwards <edwardsa at cs.man.ac.uk> wrote:

> Hi
>
> You replied at the same time as me :)
>
> I was simply trying to look for the 'worst consequence' in the
> snp_effect_predictor script to try and mimic the results you could get from
> the api with this script. I wasn't trying to find it for any biological
> reason - just to get parity between the 2. Though of course if the perl api
> has employed some logic on the list of possible consequences for the
> transcript in the context of that transcript, i didn't want to lose that
> possible enrichment of my data by switching to the snp_effect_predictor.
> Naturally you look at the consequences in more detail manually but, with the
> number of SNPs in a data set, i considered any hints in the right direction
> from a value-added integrator such as ensembl with lots of knowledge at its
> fingertips to be worth keeping hold of.
>
> Cheers
>
>
>
>
>
>
> On 24/01/2011 09:55, Fiona Cunningham wrote:
>
>>  Hello Andrea,
>>
>> You should really be considering the consequence of the particular
>> variant  for each transcript that it falls in. This is the correct
>> thing to do from a biological point of view and this is what the
>> variant effect predictor does.
>> For display purposes on the region in detail page only, as we display
>> of SNPs track that is independent of the transcripts but you should
>> take the transcript in to consideration when calculating your
>> consequences. we have internally produced a ranking of consequence so
>> that the "worst" consequence is used to colour code of variants on
>> this page but this really is only for display purposes only as an
>> indication, and has not been independently scientifically verified.
>> There is no such thing as an "main consequence".
>>
>> Best regards,
>>
>> Fiona
>>
>> ------------------------------------------------------
>> Fiona Cunningham
>> Ensembl Variation Project Leader, EBI
>> www.ensembl.org
>> www.lrg-sequence.org
>> t: 01223 494612 || e: fiona at ebi.ac.uk
>>
>>
>>
>> On 23 January 2011 20:01, Andrea Edwards<edwardsa at cs.man.ac.uk>  wrote:
>>
>>> Hello
>>>
>>> What are the rules that ensembl uses to determine the display_consequence
>>> of
>>> a SNP from all of its possible consequences?
>>>
>>> As an example I am looking at a SNP whose main consequence
>>> (display_consequence) = 3PRIME_UTR and all consequences
>>> (consequence_type)
>>> are given as NMD_TRANSCRIPT, 3PRIME_UTR
>>>
>>> Is there a list or ranking you use for consequences to say that
>>> 3PRIME_UTR
>>> is more important than NMD_TRANSCRIPT?
>>>
>>> Will the main consequence always be last in the list of the
>>> consequence_type
>>> property?
>>>
>>> One reason I ask is because I am trying to apply the same consequence
>>> ranking to the results returned by the snp_effect_predictor script. That
>>> script returns one row/line for every consequence in the consequence_type
>>> field and the order of the consequences in the rows returns seems to be
>>> the
>>> same as the order of the consequences in the consequence_type property.
>>> If
>>> the display_consequence is always last in the list then i can assume the
>>> last row returned for a transcript variant is the 'main consequence'
>>>
>>> thanks
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at ensembl.org
>>> http://lists.ensembl.org/mailman/listinfo/dev
>>>
>>>
>
> _______________________________________________
> Dev mailing list
> Dev at ensembl.org
> http://lists.ensembl.org/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20110124/6dd6999e/attachment.html>