dbSNP132 bug (human)

[mard]

Ok, thanks for the info.

Where did you get the fixed vcf file from?
I followed your link above but it brings me to the same 00-All.vcf.gz file I already have (dated Nov 2010):
ftp://ftp.ncbi.nih.gov/snp/organisms...9606/VCF/v4.0/

[csoong]

Luckily, dbSNP just released a fixed version in march (after I gone through all the hassle to get around the problem). They addressed the issue in the march release. I checked a few indel entries and they seemed fixed. Let me know what you find. Thanks.

[mard]

I've just run into this issue now and found your post csoong. For SNVs the REF base in my sample's vcf file match what is in the dbSNP132 vcf but the indels seem to be 1 base off (for the ones I've checked so far) e.g. from the dbSNP132 file REF is given as CC:
10 101478000 rs68137778 C CC . . dbSNPBuildID=130;VP=050000080001000000000200;WGT=1;VC=INDEL;INT

but for my sample it's TC (called used GATK)
10_101478000 . T TC

And if you check that position in both Ensembl and UCSC genome browsers it's also TC.

Did you find out anything more about this issue csoong?

[csoong]

The reason I am bringing this out is basically because calling indels could be tricky. Therefore , the field is emerging a consensus to call indels at its left most position possible. That is what programs like DINDEL is doing and what dbSNP132 intended to follow (since it published in VCF 4.0). But the calling between dbSNP132 and DINDEL is different ( I've run DINDEL on some of the indel records, and it correctly, I assume, prints the record with the correct position).

[csoong]

I can't agree.

"The value in the POS field refers to the position of the first base in the String:"
In the record the STRING's first base is not the base at position POS.

"For InDels, the reference String must include the base before the event (which must be reflected in the POS field)"
again, the reference before the event should be included. At the same time the previous rule should not be defied. since POS refered to A but the STRING's first base is something else.

[Richard Finney]

I think the VCF is right. It's the base before the insert, in this case it's a T.

[csoong]

Yes. That's why the VCF record is incorrect since the POS field was A while the reference String did not include it, instead it read T. Right?

[Richard Finney]

Looks like you ran into the first INDEL in the file. Indels are different than other "SNPS".

See documentation:

From VCF version 4.0 documentation at 1000genomes.org

Section 3. Data lines, "Fixed fields". subsection 4. REF reference base(s):

# REF reference base(s): Each base must be one of A,C,G,T,N. Bases should be in uppercase. Multiple bases are permitted. The value in the POS field refers to the position of the first base in the String. For InDels, the reference String must include the base before the event (which must be reflected in the POS field). (String, Required).

[csoong]

followed the follwoing URL:

http://www.ncbi.nlm.nih.gov/mailman/pipermail/dbsnp-announce/2010q4/000097.html

[Richard Finney]

It's annotated as -/TAC in UCSC tables.
What's the URL for the VCF file?

[csoong]

the above posst may sound a little vague...
so here is a record from the VCF file released by dbSNP for ver.132

1 121071 rs60992425 T TTAC . . dbSNPBuildID=129;VP=050000000009000000000200;WGT=1;VC=INDEL;CFL


If you go to the reference, location chr1: 121071 is A, not T.
This is not a 0/1-base issue since the snp records (single base variations) are correctly annotated.
Any thought?

[csoong]

Has anyone noticed the VCF version of dbSNP132 bug on reporting indels?
the called location doesn't match the A/T/C/G letter sequence on the genome. However, SNP calls were fine. I thought I threw this out to see if anyone knows if there's a fixed version or if dbSNP is on its way fixing the bug. Thanks.