[ensembl-dev] Missing MAF numbers on VEP REST service

[Wolf Beat]

Great, thank you. Such a flag would indeed be very useful.

Best regards

Beat Wolf
________________________________
From: dev-bounces at ensembl.org [dev-bounces at ensembl.org] on behalf of Will McLaren [wm2 at ebi.ac.uk]
Sent: Monday, August 01, 2016 10:05 AM
To: Ensembl developers list
Subject: Re: [ensembl-dev] Missing MAF numbers on VEP REST service

Hi,

This variant and its MAF is not reported by the VEP REST endpoint because it has failed our QC process, as you can see from the message in the grey box at the top of the variant page you linked to.

Currently there's no way to force inclusion of such failed variants using the REST service, though it is a simple fix to add the flag necessary to do this. We'll look into getting this incorporated soon.

Regards

Will McLaren
Ensembl Variation



On 31 July 2016 at 15:50, Wolf Beat <Beat.Wolf at hefr.ch<mailto:Beat.Wolf at hefr.ch>> wrote:
Excellent question.

I essentially expect the REST interface to return the same information as the website and the biomart API.
Now, it could be that biomart and the website are both wrong in displaying the MAF number they display, but it should be coherent between all three ways to access.

What i would expect personnaly is:
As the 3 alleles are regrouped under the same rs number, i need to have the MAF of all 3 alleles combined. That what i would expect, as the rs number indicates that all 3 alleles map to it. I think thats a reasonably assumption?

Kind regards

Beat Wolf
________________________________________
From: dev-bounces at ensembl.org<mailto:dev-bounces at ensembl.org> [dev-bounces at ensembl.org<mailto:dev-bounces at ensembl.org>] on behalf of Paul Flicek [flicek at ebi.ac.uk<mailto:flicek at ebi.ac.uk>]
Sent: Sunday, July 31, 2016 3:38 PM
To: Ensembl developers list
Subject: Re: [ensembl-dev] Missing MAF numbers on VEP REST service

Hi Beat,

Could you give me some insight about what you are looking for in the
case of SNPs with more than two alleles.  For example, what do you
expect the MAF to return in these cases?

More specifically, MAF is not a property of a variant site itself.
Frequency is a property of the various alleles.  We are currently
loading and returning the dbSNP MAF for each SNP, which is defined as
the frequency of the second most common allele, but in reality, the SNP
has several alleles and each of them has a frequency.  As more
individuals are assayed, more SNPs will be found to have 3 or 4 alleles,
so this is an issue that will grow.

Thanks,
Paul



On 31 Jul 2016, at 8:39, Wolf Beat wrote:

> Hello,
>
> i recently migrated a lot of my code from the biomart interface to the
> ensembl rest service. I'm mainly using grch37 as my source.
> I made the following observation:
> When i query a multi allelic variant, the REST VEP service returns not
> MAF numbers.
> But when i query the biomart service or check the variant on the
> website manually, the MAF numbers are present.
> Just to give one example:
> Variant rs6687605 has an MAF number of 0.43 when looked at on the
> website and biomart:
> http://grch37.ensembl.org/Homo_sapiens/Variation/Explore?r=1:25889132-25890132;v=rs6687605;vdb=variation;vf=106422589
>
> But the REST service returns no MAF number:
> http://grch37.rest.ensembl.org/vep/hsapiens/id/rs6687605?content-type=application/json
>
> I observed the same behaviour for:
> rs2229546, rs6022, rs1058111
>
> I also observed that the VEP rest service specifies:
> http://grch37.rest.ensembl.org/documentation/info/vep_id_get
> That the ExAC information is by default off. But i do recieve it
> without specifying the option.
> In my case i actually want it, but its still interesting to note.
>
> The first problem is kind of a big issue for me, any help in solving
> it would be greatly appreciated.
>
> Kind regards
>
> Beat Wolf
>
> _______________________________________________
> 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 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/