I noticed that the coding non-synonymous function code has been subdivided. Can you list and define the subdivisions?

Function Code 41: “Nonsense” (coding nonsynonymous)

changes to the Stop codon

Function Code 42: “Missense” (coding nonsynonymous)

alters codon to make an altered amino acid in protein product

Function Code 44: “Frameshift” (coding nonsynonymous)

indel SNP causing frameshift

You can find up-to-date function codes and their definitions in the SnpFunctionCode.bcp.gz table located in the /shared_data directory of the dbSNP FTP site. (10/27/08)

I noticed that b127 SNPs are no longer associated with function class codes 1,2,5, and 7. Does dbSNP no longer use these function class codes?

As of build 127, function codes 1, 5 and 7 have been modified into two digit codes that will more precisely indicate the location of a SNP. The two digit codes have function codes 1, 5 or 7 as the first digit, each of these numbers keeping its original meaning, and 3 or 5 as the second digit, indicating whether the SNP is 3’ or 5’ to the region of interest. So the new function codes are as follows:

Function code13: “nearGene-3”

Where:
1=locus region
3= SNP is 3’ to and 0.5kb away from gene

Function code 15: “nearGene-5”

Where:
1=locus region
5= SNP is 5’ to and 2kb away from gene

Function code 53: “UTR-3”

Where:
5= UTR (untranslated region)
3= SNP located in the 3’ untranslated region

Function code 55: “UTR-5”

Where:
5= UTR (untranslated region)
5(as the second digit)= SNP located in the 5’ untranslated region

Function code 73: “splice-3”

Where:
7=splice site
3=3’ acceptor dinucleotide

Function code 75: “splice-5”

Where:
7=splice site
5=5’ donor dinucleotide

Function code 2, however, was retired permanently as of b127, as it identified a SNP as being in the coding region of a gene, but that other details about its location were unknown. Since mapping and annotation have improved dramatically since function code 2 was defined, it is no longer used. (4/30/07)

Why do the functional classifications for some variations change when a genome is re-assembled?

Functional annotation varies from build to build because the reference genome sequence, upon which SNPs are mapped, is itself changing from assembly to assembly. During each assembly, the algorithms used to define “genes” are refined to improve accuracy. Since gene features can be defined by various classes of evidence that vary in their certainty, fine-tuning is required in estimates of gene numbers and their precise exon structure on the genome. As an organism’s annotation pipeline is developed, duplicate SNPs are identified and merged, spurious annotations are removed, and new evidence is included.

Depending on the organism, the net result of the alterations in assemblies and annotations mentioned above is that a SNP may be in an exon (or more generally, located in a gene) in one build, but then locate to an intron or UTR (or intergenic DNA) in the next build if the exon (gene) is removed between build releases. Once an organism’s genome assembly comes closer to its finishing point, like that of the human genome, its annotation will become more stable, as will its SNP functional classification. (04/05/06)

Where can I find the mapping table changes for SNP positional data on genomes and GenBank sequence records?

Please see the build 125 mapping doc, located in the “specs” subdirectory of the SNP FTP directory. (10/03/05)

Why is the physical position of all of the SNPs in B125 less than in previous builds?

Build 125 mapping tables are now 0 based — that is, the position of the first base is 0 instead of 1 as in previous builds. For other mapping table changes, please see the build 125 mapping doc, located in the “specs” subdirectory of the SNP FTP directory. (10/04/05)

Since b125 SNPs are mapped to both the NCBI reference assembly and to the Celera assembly, if an rs number is located on both assemblies, will they in the same position? Which assembly should we use?

The NCBI reference and the Celera assembles will differ depending on the region, but for any one region, one assembly may be more accurate than the other. Please note that the Celera assembly is not updated with new build cycles, and is therefore essentially static. The NCBI reference assembly is updated periodically. (1/12/06)

Is it possible for the alleles and the orientation of a refSNP flanking sequence, change either between builds, or upon a new build of dbSNP (e.g. rs17871378: could aacaaaggct [A/C] acggaaggag change to ctccttccgt[G/T]agcctttgtt)?

The case you describe should never happen. (9/22/06)

Individual refSNP Mapping Changes

Do you have tables that show those rs numbers that have changed between builds and those that have not?

RefSNP (rs) numbers will change only when a refSNP cluster merges with another cluster. When two clusters merge, the higher rs number is retired, and merged cluster takes the lower rs number.

You can now retrieve a list of merged rs numbers from Entrez SNP. Just type “mergedrs” (without the quotation marks) in the text box at the top of the page and click the “go” button. Each entry in the returned list will include the old rs numbers that has merged, and the new rs number it has merged into (with a link to the refSNP page for the new rs number). You can limit the output to merged rs numbers within a certain species by clicking on the “Limits” tab and then selecting the organism you wish from the organism selection box.

You can also find the dbSNP rs merge history in the RsMergeArch table, which is located in the organism_data directory for a particular organism in the dbSNP FTP site, . (12/03/07:11/03/08)

I find that 20% of the refSNP (rs) numbers in Build 129 cannot be found in Build 130. 20% seems rather high. Is this correct?

20% of b129 rs numbers have been merged in b130. And you’re right, this percentage is rather high, and is the result of inappropriate rs number assignment to non-novel SNPs in several large submissions that contained only a small percentage (10-20%) of novel SNPs. We later corrected this mistake by merging the non-novel rs numbers from these submissions with existing rs numbers. (06/15/09)

Are new SNPs added to dbSNP between dbSNP builds?

In general, new SNPs are added to dbSNP only during a build. If you want your local copy of dbSNP to stay current, it is necessary to update your local database every time dbSNP releases a new build.

There might be, however, some rare instances when a new dbSNP build has no new SNPs—just new frequency data, genotype data, or new mapping information. When dbSNP announces a new build, check the snp_summary page to see details on the content of that build.

Why is it that when I searched with human genome on dbSNP three weeks ago, the search retrieved 2456 records, but when I performed the same search today, it retrieved only 2127 records?

The human genome is still undergoing occasional changes between builds. This may have caused some SNPs to recluster to different locations on the genome during dbSNP build 121, and/or they have been annotated with a different functional class.

Why is there a large discrepancy between the numbers of submitted mouse SNPs(ss) and refSNPs(rs) reported for build 125 (b125) on the dbSNP summary page, and the numbers of b125 mouse ss and rs that can be loaded from the dbSNP FTP files?

The numbers of submitted SNPs and refSNPs reported on the summary page for b125 are correct. Around the time build 125 (b125) was released to the public, PERLEGEN submitted millions of mouse SNPs to dbSNP. These submissions did not get clustered, however, until build 126, so the number of submitted SNPs was over 6 million in the b125 summary, while the total number of refSNPs for the same build was only about 1.8 million. I suggest that you download the b126 FTP files since they contain three to four times more mouse SNPs than do the b125 files.

For future reference, you can see the number of SNPs submitted for a particular organism and the date the submissions were made by going to the dbSNP Summary page, and clicking on the number of new submission (ss#s) for a particular organism. (4/6/06)