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

[Will McLaren]

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> 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 [dev-bounces at ensembl.org] on behalf of Paul
> Flicek [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
> > 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/
>
> _______________________________________________
> 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/20160801/3b60de7f/attachment.html>