[ensembl-dev] VEP ClinVar information
Guillermo Marco Puche
guillermo.marco at sistemasgenomicos.com
Mon Aug 17 12:44:29 BST 2015
Could the check be done using dbSNP rs as matching identifier?
I mean OMIM phenotype feature has "rs", can this be retrieved from tva
also to match them?
Regards,
Guillermo.
On 17/08/15 13:16, Will McLaren wrote:
>
> Yes, I'm afraid that's one of the consequences of OMIM being a
> manually curated resource - you have to scan the OMIM page by eye to
> find that sort of detail.
>
> Will
>
> On 17 Aug 2015 12:09, "Guillermo Marco Puche"
> <guillermo.marco at sistemasgenomicos.com
> <mailto:guillermo.marco at sistemasgenomicos.com>> wrote:
>
> Hi Will,
>
> Awesome! ClinVar is so direct to check $tva->feature_seq with
> $pf->risk_allele.
>
> As you said, for other PhenotypeFeatures like OMIM there's no
> risk_allele, allele_symbol or allele_accession_id.
>
> *1 2228866 rs387907306 G A,T
>
> *For this case I'm getting two OMIM phenotype features I can't
> "check" if correct since risk_allele association provides the OMIM
> allelic variant number*. *I guess then there's no way to associate
> OMIM phenotype feature to a specific allele.
> *
> *
>
> **# omim_feature: 1**
> ****phenotype_description: Shprintzen-Goldberg
> craniosynostosis syndrome
> source_name: OMIM
> external_reference: MIM:164780
> is_significant: 1
> variation allele: A
> The risk allele is: 0004
>
> ****
>
> **# omim_feature: 2**
> ****phenotype_description: Shprintzen-Goldberg
> craniosynostosis syndrome
> source_name: OMIM
> external_reference: MIM:164780
> is_significant: 1
> variation allele: A
> The risk allele is: 0005
>
> *# omim_feature: 1*
> **phenotype_description: Shprintzen-Goldberg craniosynostosis
> syndrome
> source_name: OMIM
> external_reference: MIM:164780
> is_significant: 1
> variation allele: T
> The risk allele is: 0004
> **
> *# omim_feature: 2*
> **phenotype_description: Shprintzen-Goldberg craniosynostosis
> syndrome
> source_name: OMIM
> external_reference: MIM:164780
> is_significant: 1
> variation allele: T
> The risk allele is: 0005
>
>
>
> Regards,
> Guillermo.
> **
> On 17/08/15 10:25, Will McLaren wrote:
>> Hi Guillermo,
>>
>> The plugin run() sub-routine is executed for each allele +
>> transcript combination; the object is a
>> TranscriptVariationAllele, and you can find to which allele you
>> are referring with either $tva->variation_feature_seq() or
>> $tva->feature_seq(); these give you the allele relative to the
>> input variant and transcript respectively (i.e. the two will
>> differ if the transcript is on the reverse strand. See
>> http://www.ensembl.org/info/docs/Doxygen/variation-api/classBio_1_1EnsEMBL_1_1Variation_1_1TranscriptVariationAllele.html
>>
>> The data you return from the run() sub will only appear in the
>> block of output for that allele.
>>
>> If you are retrieving phenotype data from Ensembl, then you may
>> find that we don't always have an allele-specific annotation
>> stored. For some PhenotypeFeature objects, they will have an
>> attribute "risk_allele", "allele_accession_id" or
>> "allele_symbol", but many will not. You may also find that due to
>> strand or reporting issues, the sequence in the associated allele
>> may not match exactly one of the alleles from the
>> VariationFeature or VCF.
>>
>> Regards
>>
>> Will
>>
>> On 14 August 2015 at 14:49, Guillermo Marco Puche
>> <guillermo.marco at sistemasgenomicos.com
>> <mailto:guillermo.marco at sistemasgenomicos.com>> wrote:
>>
>> Dear devs,
>>
>> I would like to know what's the correct way to handle
>> information when multiple alleles appear in a VCF record.
>>
>> For example, Homo_sapiens_clinically_associated.vcf dataset:
>>
>> *1 2228866 rs387907306 G A,T*
>>
>> Each one of alternative alleles has different OMIM and
>> Clinvar allele info.
>>
>> The plugin code is using the following scope:
>>
>> *sub feature_types {**
>> ** return ['Transcript'];**
>> **}
>>
>> *Is there another feature_type level like Transcript, Allele?*
>> *
>> I'm trying to solve it with the iteration code you provided
>> me Will:
>>
>> * foreach my $known_var(@{$vf->{existing} || []}) {**
>> ** foreach my
>> $pf(@{$pfa->fetch_all_by_object_id($known_var->{variation_name})}){**
>> ** #do_stuff**
>> ** }**
>> **}*
>>
>> However this is getting me the phenotype information for both
>> alternative alleles (A and T) (transcript level) and this
>> being wrote in output for every alternative allele
>> consequence twice. So I'm getting phenotype info of A,T
>> written in allele A consequences and in allele T consequences.
>>
>> How can I get the phenotype informartion for each allele
>> sperately? I think Ensembl can handle this since in VCF
>> output consequences are separated not only by transcript but
>> also by alternative allele.
>>
>> Thank you,
>>
>> Best regards,
>> Guillermo.
>>
>>
>>
>> On 26/03/15 12:57, Will McLaren wrote:
>>> You will probably see odd behaviour if you mix versions of
>>> the script / API / caches / databases. Feel free to
>>> experiment, though we can't support such setups obviously.
>>>
>>> It works fine for me on 75 or 79 (i.e. using "git checkout
>>> --release 75" in ensembl-tools, ensembl-variation, ensembl-core)
>>>
>>> Will
>>>
>>> On 26 March 2015 at 11:26, Guillermo Marco Puche
>>> <guillermo.marco at sistemasgenomicos.com
>>> <mailto:guillermo.marco at sistemasgenomicos.com>> wrote:
>>>
>>> I guess it's a problem with my API installation then.
>>>
>>> If I install latest API(79) and continue to use
>>> variant_effect_predictor.pl
>>> <http://variant_effect_predictor.pl> from version 75
>>> will it continue working or I'll get conflicts/weird
>>> behaviours?
>>>
>>> Thanks!
>>>
>>> Regards,
>>> Guillermo.
>>>
>>>
>>>
>>> On 26/03/15 11:53, Will McLaren wrote:
>>>> Example output (I set $Data::Dumper::Maxdepth = 1;):
>>>>
>>>> > echo "rs699" | perl -I ~/Git/guillermo/vep/
>>>> variant_effect_predictor.pl
>>>> <http://variant_effect_predictor.pl> -plugin Clinvar
>>>> -data -force -db 75
>>>> 2015-03-26 10:51:38 - Reading input from STDIN (or
>>>> maybe you forgot to specify an input file?)...
>>>> 2015-03-26 10:51:38 - Starting...
>>>> 2015-03-26 10:51:38 - Detected format of input file as id
>>>> 2015-03-26 10:51:38 - Read 1 variants into buffer
>>>> 2015-03-26 10:51:38 - Checking for existing variations
>>>> [===================================================================================================================================================================================================]
>>>> [ 100% ]
>>>> 2015-03-26 10:51:38 - Reading transcript data from
>>>> cache and/or database
>>>> [===================================================================================================================================================================================================]
>>>> [ 100% ]
>>>> 2015-03-26 10:51:38 - Retrieved 4 transcripts (0 mem, 0
>>>> cached, 4 DB, 0 duplicates)
>>>> 2015-03-26 10:51:38 - Analyzing chromosome 1
>>>> 2015-03-26 10:51:38 - Analyzing variants
>>>> [===================================================================================================================================================================================================]
>>>> [ 100% ]
>>>> 2015-03-26 10:51:38 - Calculating consequences
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '2853',
>>>> 'name' => undef,
>>>> 'description' => 'HYPERTENSION, ESSENTIAL,
>>>> SUSCEPTIBILITY TO'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '20384',
>>>> 'name' => undef,
>>>> 'description' =>
>>>> 'Susceptibility_to_progression_to_renal_failure_in_IgA_nephropathy'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '20369',
>>>> 'name' => undef,
>>>> 'description' => 'Preeclampsia,_susceptibility_to'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '26451',
>>>> 'name' => undef,
>>>> 'description' =>
>>>> 'HYPERTENSION,_ESSENTIAL,_SUSCEPTIBILITY_TO'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '1',
>>>> 'name' => 'HGMD_MUTATION',
>>>> 'description' => 'Annotated by HGMD but no phenotype
>>>> description is publicly available'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '6522',
>>>> 'name' => undef,
>>>> 'description' => 'COSMIC:tumour_site:large_intestine'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '6529',
>>>> 'name' => undef,
>>>> 'description' => 'COSMIC:tumour_site:breast'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '2853',
>>>> 'name' => undef,
>>>> 'description' => 'HYPERTENSION, ESSENTIAL,
>>>> SUSCEPTIBILITY TO'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '20384',
>>>> 'name' => undef,
>>>> 'description' =>
>>>> 'Susceptibility_to_progression_to_renal_failure_in_IgA_nephropathy'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '20369',
>>>> 'name' => undef,
>>>> 'description' => 'Preeclampsia,_susceptibility_to'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '26451',
>>>> 'name' => undef,
>>>> 'description' =>
>>>> 'HYPERTENSION,_ESSENTIAL,_SUSCEPTIBILITY_TO'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '1',
>>>> 'name' => 'HGMD_MUTATION',
>>>> 'description' => 'Annotated by HGMD but no phenotype
>>>> description is publicly available'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '6522',
>>>> 'name' => undef,
>>>> 'description' => 'COSMIC:tumour_site:large_intestine'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> $VAR1 = bless( {
>>>> 'adaptor' =>
>>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>>> 'dbID' => '6529',
>>>> 'name' => undef,
>>>> 'description' => 'COSMIC:tumour_site:breast'
>>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>>> 2015-03-26 10:51:38 - Processed 1 total variants (1
>>>> vars/sec, 1 vars/sec total)
>>>> 2015-03-26 10:51:38 - Wrote stats summary to
>>>> variant_effect_output.txt_summary.html
>>>> 2015-03-26 10:51:38 - Finished!
>>>>
>>>> On 26 March 2015 at 10:43, Guillermo Marco Puche
>>>> <guillermo.marco at sistemasgenomicos.com
>>>> <mailto:guillermo.marco at sistemasgenomicos.com>> wrote:
>>>>
>>>> Hello Will,
>>>>
>>>> I already had enabled "check_existing" on my VEP
>>>> config template, however I followed your advice and
>>>> updated code to force in the new() method with your
>>>> code.
>>>> I'm still getting no prints of line 64:
>>>>
>>>> printDumper($pf->phenotype());
>>>>
>>>> Are you getting any output printed? As I said I get
>>>> no errors but nothing is printed neither. This data
>>>> dumper should be printing result of phenotype()
>>>> method call.
>>>>
>>>> Regards,
>>>> Guillermo.
>>>>
>>>>
>>>>
>>>> On 26/03/15 11:05, Will McLaren wrote:
>>>>> I think perhaps you haven't enabled
>>>>> --check_existing; this is required for
>>>>> $vf->{existing} to get populated.
>>>>>
>>>>> You can force it on in the new() method of your
>>>>> plugin:
>>>>>
>>>>> $self->{config}->{check_existing} = 1;
>>>>>
>>>>> It then works for me on release/75 and release/79.
>>>>>
>>>>> Will
>>>>>
>>>>> On 25 March 2015 at 17:35, Guillermo Marco Puche
>>>>> <guillermo.marco at sistemasgenomicos.com
>>>>> <mailto:guillermo.marco at sistemasgenomicos.com>> wrote:
>>>>>
>>>>> Hello Will,
>>>>>
>>>>> With your explanations I'm trying to call
>>>>> phenotype (as you said I was accessing the
>>>>> hashref directly).
>>>>> I'm using input set you linked. However my
>>>>> local Ensembl installation is v75.
>>>>>
>>>>> This is the code of the plugin:
>>>>> https://github.com/guillermomarco/vep/blob/master/Clinvar.pm
>>>>>
>>>>> I'm getting absolutelty no info nor errors.
>>>>> I've no idea if this is an issue with my
>>>>> database/API version or with the plugin code
>>>>> itself.
>>>>>
>>>>> Regards,
>>>>> Guillermo.
>>>>>
>>>>>
>>>>>
>>>>> On 16/03/15 17:50, Will McLaren wrote:
>>>>>> The "is_significant" field is an internal
>>>>>> flag that doesn't necessarily have the
>>>>>> meaning you expect; it is used to distinguish
>>>>>> between genuine reported associations and
>>>>>> e.g. non-significant associations reported
>>>>>> from genome-wide studies.
>>>>>>
>>>>>> You should not see undef for phenotype; I
>>>>>> suspect you are accessing the hashref
>>>>>> directly ($pf->{phenotype}) rather than
>>>>>> making the method call ($pf->phenotype()).
>>>>>>
>>>>>> You could try
>>>>>> ftp://ftp.ensembl.org/pub/release-79/variation/vcf/homo_sapiens/Homo_sapiens_clinically_associated.vcf.gz
>>>>>> as a test input set.
>>>>>>
>>>>>> Will
>>>>>>
>>>>>> On 16 March 2015 at 16:39, Guillermo Marco
>>>>>> Puche <guillermo.marco at sistemasgenomicos.com
>>>>>> <mailto:guillermo.marco at sistemasgenomicos.com>>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Will,
>>>>>>
>>>>>> Thank you for your quick response! Very
>>>>>> clarifying.
>>>>>>
>>>>>> I guess that the way to retrieve ClinVar
>>>>>> data I posted is correct. With my test
>>>>>> dataset I've only seen "is_significant"
>>>>>> values of "1" and undef 'phenotype'
>>>>>> values. I think I need a synthetic vcf
>>>>>> with ClinVar annotation variants to very
>>>>>> that the plugin is working.
>>>>>>
>>>>>> I've been looking on Ensembl website for
>>>>>> a test dataset. I think you don't provide
>>>>>> any right? Correct me if I'm wrong.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Regards,
>>>>>> Guillermo.
>>>>>>
>>>>>>
>>>>>> On 16/03/15 16:16, Will McLaren wrote:
>>>>>>> Hi Guillermo,
>>>>>>>
>>>>>>> To get the rest of that data in the
>>>>>>> table you need to access the additional
>>>>>>> attributes of the PhenotypeFeature
>>>>>>> object, something like:
>>>>>>>
>>>>>>> my $attr = $pfs->[0]->get_all_attributes;
>>>>>>> print "$_:".$attr->{$_}."\t" for keys
>>>>>>> %$attr;
>>>>>>> print "\n;
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Will
>>>>>>>
>>>>>>> More info: the reason these data are
>>>>>>> stored as attributes is due to the
>>>>>>> diverse data sources and types that we
>>>>>>> import into our phenotype schema; to
>>>>>>> create a database column and
>>>>>>> corresponding API method for each data
>>>>>>> type (p-value, review status, risk
>>>>>>> allele, external ID etc etc) would be
>>>>>>> cumbersome and inefficient. To this end
>>>>>>> we provide a few methods that shortcut
>>>>>>> the attribute approach for the most
>>>>>>> common data types; everything else must
>>>>>>> be accessed through the attributes
>>>>>>> method. This is a common theme across
>>>>>>> the Ensembl API.
>>>>>>>
>>>>>>> On 13 March 2015 at 12:03, Guillermo
>>>>>>> Marco Puche
>>>>>>> <guillermo.marco at sistemasgenomicos.com
>>>>>>> <mailto:guillermo.marco at sistemasgenomicos.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm trying to retrieve ClinVar
>>>>>>> information with the code example
>>>>>>> you provided.
>>>>>>>
>>>>>>> my $self = shift;
>>>>>>> my $tva = shift;
>>>>>>> my $vf = $tva->variation_feature;
>>>>>>> my $pfa =
>>>>>>> $self->{config}->{reg}->get_adaptor('human','variation','phenotypefeature');
>>>>>>>
>>>>>>> foreach my
>>>>>>> $known_var(@{$vf->{existing} || []}) {
>>>>>>> foreach my
>>>>>>> $pf(@{$pfa->fetch_all_by_object_id($known_var->{variation_name})})
>>>>>>> {
>>>>>>> if ($pf->{'source'} eq
>>>>>>> "dbSNP_ClinVar"){
>>>>>>> print
>>>>>>> "$pf->{'source'}\t$pf->{'external_id'}\t$pf->{'is_significant'}\t$pf->{'phenotype'}\n",
>>>>>>> ;
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> As you can see I'm "filtering" the
>>>>>>> results to only output phenotype
>>>>>>> feature when source is
>>>>>>> dbSNP_ClinVar. I don't know why but
>>>>>>> I guess filtering should be done
>>>>>>> when doing the "fetch_all".
>>>>>>>
>>>>>>> On the other hand I'm trying to
>>>>>>> retrieve Disease, Source and
>>>>>>> Clinical Significance from this
>>>>>>> example table:
>>>>>>> http://www.ensembl.org/Homo_sapiens/Variation/Phenotype?db=core;r=8:19955518-19956518;v=rs268;vdb=variation;vf=266
>>>>>>>
>>>>>>> I think I'm doing something wrong I
>>>>>>> got totally lost in Phenotypefeature.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Guillermo.
>>>>>>>
>>>>>>>
>>>>>>> On 02/03/15 16:05, Will McLaren wrote:
>>>>>>>> If you enable the --check_existing
>>>>>>>> flag when you run the VEP, you'll
>>>>>>>> be able to see any known co-located
>>>>>>>> variants attached to the
>>>>>>>> VariationFeature object in your
>>>>>>>> plugin:
>>>>>>>>
>>>>>>>> sub run {
>>>>>>>> my $self = shift;
>>>>>>>> my $tva = shift;
>>>>>>>> my $vf = $tva->variation_feature;
>>>>>>>>
>>>>>>>> foreach my
>>>>>>>> $known_var(@{$vf->{existing} || []}) {
>>>>>>>> # do stuff
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> The $known_var is not an API object
>>>>>>>> but a simple hashref with a number
>>>>>>>> of fields; you're probably
>>>>>>>> interested in $known_var->{clin_sig}
>>>>>>>>
>>>>>>>> However, as I mentioned, this is
>>>>>>>> the only data that is stored in the
>>>>>>>> cache. To access the rating and the
>>>>>>>> specific disease association,
>>>>>>>> you'll need to make calls to the
>>>>>>>> database by getting an adaptor,
>>>>>>>> something like:
>>>>>>>>
>>>>>>>> sub run {
>>>>>>>> my $self = shift;
>>>>>>>> my $tva = shift;
>>>>>>>> my $vf = $tva->variation_feature;
>>>>>>>> my $pfa =
>>>>>>>> $self->{config}->{reg}->get_adaptor('human','variation','phenotypefeature');
>>>>>>>>
>>>>>>>> foreach my
>>>>>>>> $known_var(@{$vf->{existing} || []}) {
>>>>>>>> foreach my
>>>>>>>> $pf(@{$pfa->fetch_all_by_object_id($known_var->{variation_name})})
>>>>>>>> {
>>>>>>>> # do stuff
>>>>>>>> }
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> Be aware that this will access the
>>>>>>>> database, so unless you have a
>>>>>>>> local copy please don't run this
>>>>>>>> sort of code on genome-wide VCFs
>>>>>>>> using our public DB server.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Will
>>>>>>>>
>>>>>>>> On 2 March 2015 at 14:47, Guillermo
>>>>>>>> Marco Puche
>>>>>>>> <guillermo.marco at sistemasgenomicos.com
>>>>>>>> <mailto:guillermo.marco at sistemasgenomicos.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Will,
>>>>>>>>
>>>>>>>> Indeed I'm looking to retrieve
>>>>>>>> this information from VEP plugin.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Guillermo.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 02/03/15 15:25, Will McLaren
>>>>>>>> wrote:
>>>>>>>>> Hi Guillermo,
>>>>>>>>>
>>>>>>>>> The detailed ClinVar
>>>>>>>>> information is stored against
>>>>>>>>> PhenotypeFeature objects (each
>>>>>>>>> SNP/disease pairing gets its
>>>>>>>>> own entry in ClinVar, e.g.
>>>>>>>>> http://www.ncbi.nlm.nih.gov/clinvar/RCV000019691.2,
>>>>>>>>> http://www.ncbi.nlm.nih.gov/clinvar/RCV000019692.2/,
>>>>>>>>> http://www.ncbi.nlm.nih.gov/clinvar/RCV000019693.2/
>>>>>>>>> for rs699).
>>>>>>>>>
>>>>>>>>> The rating (and indeed the
>>>>>>>>> clinical significance) is
>>>>>>>>> stored as an attribute on the
>>>>>>>>> PhenotypeFeature object; you
>>>>>>>>> can retrieve this with the
>>>>>>>>> get_all_attributes() method.
>>>>>>>>>
>>>>>>>>> See
>>>>>>>>> http://www.ensembl.org/info/docs/Doxygen/variation-api/classBio_1_1EnsEMBL_1_1Variation_1_1PhenotypeFeature.html
>>>>>>>>> and
>>>>>>>>> http://www.ensembl.org/info/docs/api/variation/variation_tutorial.html#phenotype
>>>>>>>>> for more info.
>>>>>>>>>
>>>>>>>>> Bio::EnsEMBL::Variation::Utils::VEP::get_clin_sig()
>>>>>>>>> is an internal method that you
>>>>>>>>> should not use.
>>>>>>>>>
>>>>>>>>> The VEP cache contains the
>>>>>>>>> list of clinical significance
>>>>>>>>> states for each variant, but
>>>>>>>>> neither the disease
>>>>>>>>> association or the rating. If
>>>>>>>>> you want help getting access
>>>>>>>>> to this data via a plugin, let
>>>>>>>>> me know as it's a little more
>>>>>>>>> involved than the API methods
>>>>>>>>> above (though it is faster as
>>>>>>>>> no database access is required).
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> Will McLaren
>>>>>>>>> Ensembl Variation
>>>>>>>>>
>>>>>>>>> On 2 March 2015 at 14:06,
>>>>>>>>> Guillermo Marco Puche
>>>>>>>>> <guillermo.marco at sistemasgenomicos.com
>>>>>>>>> <mailto:guillermo.marco at sistemasgenomicos.com>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Dear devs,
>>>>>>>>>
>>>>>>>>> I'm looking forward to
>>>>>>>>> retrieve ClinVar
>>>>>>>>> information and add it to
>>>>>>>>> VEP annotation. From my
>>>>>>>>> understanding I should be
>>>>>>>>> able to retrieve "Clinical
>>>>>>>>> significance" and "ClinVar
>>>>>>>>> Rating".
>>>>>>>>>
>>>>>>>>> I've been looking the
>>>>>>>>> Varation API, and I'm
>>>>>>>>> confused. I guess for
>>>>>>>>> significance I should use
>>>>>>>>> Bio::EnsEMBL::Variation::Utils::VEP::get_clin_sig()
>>>>>>>>> or
>>>>>>>>> Bio::EnsEMBL::Variation::VariationFeature::get_all_clinical_significance_states().
>>>>>>>>>
>>>>>>>>> What about ClinVar rating?
>>>>>>>>> Is it possible to retrieve
>>>>>>>>> it from API?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Guillermo.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Dev mailing list
>>>>>>>>> Dev at ensembl.org
>>>>>>>>> <mailto: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
>>>>>> <mailto: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 listDev at ensembl.org <mailto: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
>>>>> <mailto: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 listDev at ensembl.org <mailto: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
>>>> <mailto: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 listDev at ensembl.org <mailto: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 <mailto: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 listDev at ensembl.org <mailto: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 <mailto: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 listDev at ensembl.org <mailto: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 <mailto: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/20150817/72da1b43/attachment.html>
More information about the Dev
mailing list