[ensembl-dev] Transcript variation alleles - - Bayesian Filter detected spam
Andrea Edwards
edwardsa at cs.man.ac.uk
Thu Feb 10 00:01:52 GMT 2011
Hi Will
Just to be 100% clear about this answer, are you saying that methods
that return more than one object don't return failed variants (in v61
and all previous versions) but in v61 you can call the method
include_failed_variations on the adaptors? If i am reading that right
you dont need to check the data returned by the adaptors for failed
variants as they are excluded by default.
On 07/02/2011 13:48, Will McLaren wrote:
> Hello Gavin,
>
> We apply some QC checking to the data that we import - we can assign
> variations a status of "failed", along with a description of why this
> has happened. You can access this through a variation object using the
> failed_description() method. The list Andrea gave is the list of all
> possible failed descriptions.
>
> The API is configured such that by default data associated with failed
> variations are not returned by methods that return more than one
> object (e.g. fetch_all_by_Slice in VariationFeatureAdaptor); you can
> force the retrieval of such data by retrieving the variation directly
> (e.g. using fetch_by_name in VariationAdaptor), or by calling the
> method include_failed_variations() on any adaptor from the Variation
> group (functionality only available from e!61 onwards).
>
> Thanks
>
> Will
>
>
> On 7 February 2011 09:29, Oliver, Gavin <gavin.oliver at almacgroup.com
> <mailto:gavin.oliver at almacgroup.com>> wrote:
>
> Those were the statuses I was referring to Will.
>
> Which leads me to ask – what were the statuses that Andrea listed?
>
> Gavin
>
> ------------------------------------------------------------------------
>
> *From:*dev-bounces at ensembl.org <mailto:dev-bounces at ensembl.org>
> [mailto:dev-bounces at ensembl.org <mailto:dev-bounces at ensembl.org>]
> *On Behalf Of *Will McLaren
> *Sent:* 04 February 2011 15:04
> *To:* Andrea Edwards
> *Cc:* Dev at ensembl.org <mailto:Dev at ensembl.org>
> *Subject:* [SPAM] - Re: [ensembl-dev] Transcript variation alleles
> - - Bayesian Filter detected spam
>
> Hello,
>
> I think there are some crossed wires here - validation_status is a
> property of a variation supplied to us by dbSNP.
>
> Their descriptions are here:
>
> http://www.ncbi.nlm.nih.gov/projects/SNP/snp_legend.cgi?legend=validation
>
> The pictures are, in order:
>
> cluster
>
> freq
>
> submitter
>
> doublehit
>
> hapmap
>
> 1000Genome
>
> Will
>
> On 4 February 2011 14:14, Andrea Edwards <edwardsa at cs.man.ac.uk
> <mailto:edwardsa at cs.man.ac.uk>> wrote:
>
>
> Gavin
>
> I believe the validatation statuses are just pass and fail
>
> If you query the variation schema directly you can find the
> reasons for failure when a variation is imported from say dbSNP
>
> mysql> select description from failed_description;
> +--------------------------------------------------------+
> | description |
> +--------------------------------------------------------+
> | Variation maps to more than 3 different locations |
> | None of the variant alleles match the reference allele |
> | Variation has more than 3 different alleles |
> | Loci with no observed variant alleles in dbSNP |
> | Variation does not map to the genome |
> | Variation has no associated sequence |
> +--------------------------------------------------------+
> 6 rows in set (0.06 sec)
>
> As will has said, they map all variants to the positive strand and
> make sure at least one of the variant alleles exists at the base
> position in the forward strand. If this failed you would get the
> error 'None of the variant alleles match the reference allele.' I
> think the others are fairly self explanatory though i'm not sure
> how a variant could have no associated sequence if it was imported
> from dbSNP
>
>
>
>
>
>
> On 02/02/2011 15:20, Oliver, Gavin wrote:
>
> Thanks Graham -
>
>
>
> Can you also tell me where to find information on the meaning of the
>
> possible validation statuses?
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: Graham Ritchie [mailto:grsr at ebi.ac.uk]
>
> Sent: 02 February 2011 15:12
>
> To: Oliver, Gavin
>
> Cc:dev at ensembl.org <mailto:dev at ensembl.org>
>
> Subject: [SPAM] - Re: [ensembl-dev] Transcript variation alleles - Email
>
> found in subject
>
>
>
> Hi Gavin,
>
>
>
> The alleles of a transcript variation always represent the genomic base
>
> change.
>
>
>
> Cheers,
>
>
>
> Graham
>
>
>
> Ensembl variation
>
>
>
>
>
> On 2 Feb 2011, at 15:02, Oliver, Gavin wrote:
>
>
>
>> Hi,
>>
>> When I pull transcript variation alleles via the API, does the allele
> shown (e.g. A/T) represent the genomic base change, or the
>
> transcriptomic one?
>
>>
>> Gavin
>>
>>
>> The contents of this message and any attachments to it are
> confidential and may be legally privileged. If you have received this
>
> message in error, you should delete it from your system immediately and
>
> advise the sender.
>
>>
>> Almac Group (UK) Limited, registered no. NI061368. Almac Sciences
> Limited, registered no. NI041550. Almac Discovery Limited, registered
>
> no. NI046249. Almac Pharma Services Limited, registered no. NI045055.
>
> Almac Clinical Services Limited, registered no. NI041905. Almac
>
> Clinical Technologies Limited, registered no. NI061202. Almac
>
> Diagnostics Limited, registered no. NI043067. All preceding companies
>
> are registered in Northern Ireland with a registered office address of
>
> Almac House, 20 Seagoe Industrial Estate, Craigavon, BT63 5QD, UK.
>
>>
>> Almac Sciences (Scotland) Limited, registered in Scotland no.
> SC154034.
>
>>
>> Almac Clinical Services LLC, Almac Clinical Technologies LLC, Almac
> Diagnostics LLC, Almac Pharma Services LLC and Almac Sciences LLC are
>
> Delaware limited liability companies and Almac Group Incorporated is a
>
> Delaware Corporation. More information on the Almac Group can be found
>
> on the Almac website:www.almacgroup.com <http://www.almacgroup.com>
>
>> _______________________________________________
>> Dev mailing list
>> Dev at ensembl.org <mailto:Dev at ensembl.org>
>> http://lists.ensembl.org/mailman/listinfo/dev
> mailman/listinfo/dev
>
>
>
>
>
> _______________________________________________
>
> Dev mailing list
>
> Dev at ensembl.org <mailto:Dev at ensembl.org>
>
> http://lists.ensembl.org/mailman/listinfo/dev
>
>
> _______________________________________________
> Dev mailing list
> Dev at ensembl.org <mailto:Dev at ensembl.org>
> http://lists.ensembl.org/mailman/listinfo/dev
>
> ****
>
> The contents of this message and any attachments to it are
> confidential and may be legally privileged. If you have received
> this message in error, you should delete it from your system
> immediately and advise the sender.
>
> Almac Group (UK) Limited, registered no. NI061368.Almac Sciences
> Limited, registered no. NI041550.Almac Discovery Limited,
> registered no. NI046249. Almac Pharma Services Limited, registered
> no. NI045055.Almac Clinical Services Limited, registered no.
> NI041905.Almac Clinical Technologies Limited, registered no.
> NI061202. Almac Diagnostics Limited, registered no. NI043067.All
> preceding companies are registered in Northern Ireland with a
> registered office address of Almac House, 20 Seagoe Industrial
> Estate, Craigavon, BT63 5QD, UK.
>
> Almac Sciences (Scotland) Limited, registered in Scotland no.
> SC154034.
>
> Almac Clinical Services LLC, Almac Clinical Technologies LLC,
> Almac Diagnostics LLC, Almac Pharma Services LLC and Almac
> Sciences LLC are Delaware limited liability companies and Almac
> Group Incorporated is a Delaware Corporation. More information on
> the Almac Group can be found on the Almac website:
> www.almacgroup.com <http://www.almacgroup.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20110210/4dde0f4f/attachment.html>
More information about the Dev
mailing list