How do I determine the top/bottom strand in the Illumina SNP array data?

First of all, be sure to read the ILLUMINA guide to their method for determining strand.

There are two ways you can get the top/bottom designation:

1.

You can compute the top/bottom designation yourself using the data in the ​/organisms/human_9606/GWAS_arrays/ directory on the dbSNP FTP site.

2.

You can look at dbSNP's top/bottom assignment, which you can access if you download the SubSNP.bcp file located in the ​/database/organism_data/ directory for human. The field that includes the top/bottom data is called SubSNP.top_or_bot_strand. You can access the table DDL for SubSNP in the ​/database/organism_schema directory.
The downside of this approach is that you need to download the entire SubSNP table, which includes 50million+ submitted SNPs.

(09/22/08)

Can you tell me what “Validation by HapMap” really means?

"Validation by HapMap" in dbSNP simply means that a SNP was genotyped in HapMap (phase 1 & 2 over 270 samples, phase 3 over 1115 samples (not in dbSNP yet).

For some SNPs, HapMap found homozygous genotype results in the 270 samples. In these cases, the SNPs still have the "Validation by HapMap" flag, but will not have the "Validation by Frequency" flag ("Validation by Frequency" requires at least 2 minor alleles).

You should therefore look at "Validation by HapMap" in conjunction with "Validation by Frequency" to verify that the SNP’s minor allele has been observed at least twice. (07/09/08)

What exactly does it mean when a SNP is validated? Could you explain what validation is?

In order for a RefSNP(rs) to be validated, at least one of its clustered submitted SNPs (ss) must either have been ascertained using a non-computational method or have frequency information associated with it.

When a ss is withdrawn from a validated rs cluster, and the withdrawn ss was the only ss in that cluster to have frequency information or to be ascertained using a non-computational method, then the rs cluster changes to"non-validated" status. For example, the submitter "SNP500CANCER" found all their SNPs using non-computational methods, and routinely withdrew SNPs during their quality control cycles. So when "SNP500CANCER" submitted a ss into dbSNP and it clustered into a non-validated rs, that rs became validated. When"SNP500CANCER" later withdrew the same ss, the rs cluster it was associatedwith lost its validation status.

You can also find information on variation validation by going to the dbSNP Handbook, and search for the text: "Validation" (scroll to the bottom of the page). You will find the following statement:

“dbSNP accepts individual assay records (ss numbers) without validation evidence. When possible, however, we try to distinguish high-quality validated data from unconfirmed (usually computational) variation reports. Assays validated directly by the submitter through the VALIDATION section show the type of evidence used to confirm the variation. Additionally, dbSNP will flag an assay as validated (Table 4) when we observe frequency or genotype data for the record.top link.” (04/21/08)

dbSNP’s “Validation status description” states that one mode of validation is ”Validation by Frequency or Genotype data”. What is the difference between a validation by frequency or by geneotype?

Validation by Frequency includes both population frequency data AND genotype data. In fact, the number of SNPs that have genotype data is bigger then the number of SNPs with only population frequency data. We compute frequency based on genotype data. (10/25/07)

What criteria you have for your four validation parameters—cluster, frequency, submitter, and double hit?

You can access this information in the SNP handbook. The handbook, however, doesn't contain double hit information, but you can find it in the dbSNP docsum spec, which states: “doublehit (3)—refSNPs with both alleles seen twice. Data for NSE-rs.validated-by-2hit-2allele.”

Does dbSNP check that submissions in the multiple reporting validation method are independent of each other?

“By Cluster” validation is currently the only check used that will confirm that an rs cluster has at least two subSNPs (ss), and that at least one of the ss is derived from a non-computational method. Although we could check to determine if the ss are from two different submitters, it may not be possible because some submitters do not report this information.

How do you decide what validation status to use for a SNP?

You can access this information in the SNP chapter of the NCBI handbook.

How can validation status go from validated to not validated?

A change in validation status can happen in the following cases:

In order for a RefSNP(rs) to be validated, at least one of its clustered submitted SNPs (ss) must either have been ascertained using a non-computational method or have frequency information associated with it. When a ss is withdrawn from a validated rs cluster, and the withdrawn ss was the only ss in that cluster to have frequency information or to be ascertained using a non-computational method, then the rs cluster changes to “non-validated” status. For example, the submitter “SNP500CANCER” found all their SNPs using non-computational methods, and routinely withdrew SNPs during their quality control cycles. So when “SNP500CANCER” submitted a ss into dbSNP and it clustered into a non-validated rs, that rs became validated. When “SNP500CANCER” later withdrew the same ss, the rs cluster it was associated with lost its validation status.

When there is a bug in dbSNP that accidentally makes a rs “validated”, and this bug is later fixed, the rs status changes back to “not validated. (2/11/05)

rs1801127 is validated by frequency data (according to the icon), yet has no heterozygosity data, while rs3219014 is not listed as validated but has frequency information.

1.

Go to the refSNP page for rs3219014.

If you scroll down to the Validation Summary section at the bottom of the refSNP page, and click on the text “Validation Status” just below the section divider, you will see that the validation by frequency rule is “Validated by frequency or genotype data: minor alleles observed in at least two chromosomes.”

If you scroll back up the refSNP page for rs3219014 to the “Submitter Records for this RefSNP Cluster” section and click on the only member (as of this date) submitted SNP (ss) (ss4480378) for this cluster, you will get the submitted SNP detail report. This report indicates that there is only one member of the population with the “A” allele (found in genotype “A/G”) for all 90 people in the PDR90 population. The remaining members of the population have genotypes “G/G” or “N/N” (indetermindate).

As the Validation-by-frequency rule as shown in the first paragraph states that the minor allele count should be two or greater, rs3219014 (ss4480378) is not considered validated since even though it has available frequency data.

Even though rs3219014 lacks validation, this doesn't mean rs3219014 is not real. rs3219014 could be a rare SNP. If dbSNP gets future genotyping submissions from different submitters, it may be these submissions might show that rs3219014 is indeed rare.

2.

As for rs1801127, the frequency/genotype data were submitted on member ss5586811 of the cluster. Looking at the data for ss5586811, you can see that this also seems to be a rare SNP, as it does not meet the validation by frequency rule that the minor allele count must be greater than or equal to two, and as such we will remove the "Validated by Frequency" flag from this SNP in a later update. Please note, however, that this SNP does meet the first validation rule, which states that a SNP can be ” Validated by multiple, independent submissions to the refSNP cluster”. (5/10/07)

dbSNP shows a SNP as having been “validated by the HapMap project”, but the genotype data shows this SNP to have just one allele in all 269 samples. How will dbSNP represent such conflicting genotyping results, and how will this play into the notion of refSNP “validation status”?

We are considering a new processing rule that does not allow monomorphic refSNPs to be validated. A HapMap flag on the validation really indicates that the SNP was "genotyped by HapMap". Our current validation rule deliberately makes HapMap “validation” and "validated by having minimum of two minor alleles", two separate validation conditions. It is easy to see how those refSNPs with HapMap genotype data would turn out to have no variation when you use a simple query such as: Select count(*) from SNP where validation_status-16 = 0 62479
(4/20/05)

Examples are:
snp_id
----------- 
26441
26716
26733
26943
27073
27490
29151
30970
31411
31742

Can I assume that if a SNP is validated, it is also validated in all the proteins in to which it maps?

SNPs are experimentally validated through observation, and because SNPs are observed as variations in the nucleotide sequence, SNPs are experimentally validated at the nucleotide sequence level. The amino acid variations are predicted from their corresponding nucleotide variations — they have not been confirmed by protein sequencing — therefore they cannot be considered experimentally validated. (6/14/05)

How were SNPs in Build 121 validated?

You can find this out for yourself. As an example of how to accomplish this, look in the second section of the page, called Submitter Records by RefSNP Cluster. Click on the words Validation Status (the heading of the third field of that section), and you will see a pop-up window containing the validation codes. You can also see the validation status code definitions on the dbSNP FTP site.

I have noticed many SNPs that are not validated. Why doesn’t dbSNP purge these SNPs?

Currently, dbSNP does not unilaterally remove SNPs that are not validated. We will, however, process a submitters' withdrawal request if they later find their submission to be an artifact.

dbSNP also does not remove “un-validated” SNPs since it is possible that a SNP derived computationally may later be successfully genotyped by another lab.

If you are interested in using an SNP for your research, you should first make an informed decision about the usefulness of the SNP by reviewing the validation status (found on the refSNP cluster report) and detection method (links for available detection methods can be found on the submitted SNP detail report) of the SNPs under consideration.

(12/06/07)

How does dbSNP code alleles for SNPs from multiple studies across multiple platforms so that they are comparable?

A submitted SNP has a fixed orientation that is defined by its flanking sequence which allows us to map the alleles to the refSNP, the reference genome, or any number of genomic sequences/assemblies.

Top / Bottom orientation can be determined by a simple algorithm applied to the alleles and flanking sequence, however, the algorithm is defined for single base alleles only and may not work with some palendromic flanking sequences. Note: To orient linked SNPs in a haplotype, you cannot use submitted SNP (ss), refSNP (rs) or top/bottom orientations; instead you must use the orientation to a common sequence or assembly. (08/08/08)

How do I find the set of alleles that you used to instantiate a SNP allele sequence?

We do not choose the alleles for a SNP. We include all alleles reported by submitters for a refSNP cluster. If a submitted SNP is on the reverse strand relative to the refSNP sequence, we reverse the alleles. For example, in the refSNP(rs) cluster rs268, rs268and ss268 have the allele A/G, while ss48420135 shows the C/T allele on the reverse strand. So the reported allele set for refSNP cluster rs268 is reported as A/G.

(6/21/06)

The genotype results for rs34958084 shows are strange: in the ss48428804 assay, 100% of CEU, HCB and JPT individuals are homozygous for T; but, in the assay ss66405533 assay, 100% of CEU, HCB and JPT individuals are homozygous for C.

You will see as you examine the reports for rs34958084, that the submitter of the genotype data was "GAIN-BROAD-QC".

We have noticed the genotype data quality issues for a number of batches from "GAIN-PERLEGEN-QC" and "GAIN-BROAD-QC", and one of our staff members has been working with these submitters to fix the genotype data. We hope the data will be corrected in time to be released with the next build (B130). (07/17/08)

The refSNP report for rs2839858 doesn’t provide the frequency of each allele and the population diversity section of the report shows that all individuals have the A/A genotype. How can this be a SNP if there are no other observed alleles?

Frequency and genotype data is not required in order to submit SNP assay data, although dbSNP does encourage its submitters to provide frequency and genotype information when submitting a new SNP.

Sometimes SNPs are discovered using a computational algorithm, and in such a case, there are no frequency and genotype data available. Other submitters, however, may submit the frequency/genotype data for such a SNP at a later date. In the case of rs2839858, you can see in the “Population Diversity” section of the report that the exemplar submitted SNP (ss4021194) genotype data was generated by HapMap. It is hard to say if this is truly a "Novariation" site. It might be a rare allele.

I encourage you to contact the submitter directly for more information. You can get the submitter’s contact information by clicking on a submitted SNP number (ss#). For example, if you click on ss48294011, you’ll go to the detail page for that SNP which contains the submitter information. Once on the detail page, click on the submitter’s handle, in this case "SNP500CANCER" to get the contact information.

You can also click on the handle/ submitted SNP ID located in the “Submitter Records” section of the refSNP report to get information on the method of discovery directly from the submitter. For example, if you click on "SNP500Cancer ID|DIO2-05" for ss48294011, you’ll go to the SNP500CANCER page , which contains further details about this particular submitted SNP.(9/14/06)

The refSNP report for rs7503991 shows an A/T variation, but the population diversity section shows the variation was 100% T in all populations. Why is this is listed as a SNP if only 1 allele is observed in all populations?

This refSNP cluster was based on a single submission, which you can look at by clicking on the submitted SNP (ss) number located in the "Submitter records for this refSNP Cluster" section of the refSNP report, which will take you to the . Submitted SNP Detail Report.

The Submitted SNP Detail Report shows that this submission was based on a computer algorithm called SsahaSNP. If you would like to see the publication that describes the SNP discovery method, go to the Assay section of the Submitted SNP Detail Report and click on the method id number to see a description of the method.

The fact that the SNP was shown to be monomorphic in the four populations tested by HapMap could mean a few things. It could mean that there is no variation at this site since the computational method has its limitations. It could also mean that this is a rare SNP that is not present in the four populations tested.(7/3/06)

How do I verify dbSNP’s genotype data sources?

Population descriptions are provided to dbSNP by the submitter, and as such, the submitter is entirely responsible for any quality control of the submitted population description. You will therefore have to ask the submitter about the source of the genotype data. Please contact vog.hin.mln.ibcn@nimda-pns if you need help contacting the submitter.

C and G are listed as alleles in the “Summary of Genotypes” section of the detail report for ss15377600, yet the “Allele” section in the same report shows that the observed alleles are -/T.

One of the idiosyncrasies of dbSNP is that genotype & frequency data need to be linked to one of the submitted-SNP(ss) records within a refSNP(rs) cluster — specifically the ss exemplar for that cluster — because a refSNP will sometimes merge away. Linking genotype & frequency data to the ss exemplar becomes a problem when different submitted SNPs contribute different variations to the refSNP cluster. This is the problem with the submitted SNP (ss15377600) you mention in your question. In this case, ss15377600 happens to be the exemplar for the refSNP cluster, and is an in/del variation, while all other ss in the rs2070922 cluster are true SNPs and contribute the allele frequencies you found in the “Summary of Genotypes” section of the report.

The SNPdev team is thinking about separating refSNP clusters if the exemplar submitted SNPs within that cluster is of a different class from the other submitted SNPs in the cluster (such as indel vs. true SNP, as in this example). I will try to determine how many ss exemplars do not have the alleles reported in their refSNP genotypes. In the meantime, please look at the refSNP allele list to see if a submitted SNP genotype allele is valid or not. (2/28/05)

HapMap Data

The reported frequency of a minor variant is GCGATTGGCC{G/A}GGACCACGAC 0.102 plus/minus 0.012. Can I assume that the minor variant is A?

When a SNP is submitted as (G/A), we do not assume that the "G" allele is the major (wild-type) variant, and the “A” allele is the minor variant. Because the minor allele in one population can be the major allele in an other population, we do not assume allele order implies allele frequency information, and do not interpret the data at all — to bdSNP, both the "G" variant and the "A" variant have been observed at the SNP location, and that is all.

At the same time, however, we have been, and will continue to encourage dbSNP users to submit individual genotype data or genotype/allele frequency data for both new and existing SNPs. Once we have allele frequency data, we can then state the minor allele and its frequency. (5/1/06)

Does dbSNP use the summary of genotypes table to produce the submitted frequency table, or vice versa?

dbSNP summarizes the submitted genotypes and shows the results in the table dbSNP summary of genotypes, whereas the numbers in the submitted frequency table are provided by the submitter.

Why are four nucleotides listed for the average allele frequency of rs702424?

I checked the submission records and found inconsistencies in the original data. rs702424 has two ss with frequency data: ss1724861 and ss152049; both of these are located on the forward strand of the rs. The ss152049 frequency data is for “T” and “C”, while the ss1724861 frequency submission was on the wrong strand. The submitter listed “A” and “G” on the FORWARD strand of ss1724861in the frequency file, but listed “A” and “G” on the REVERSE strand of ss1724861 in the genotype file. The frequency for ss1724861 should be listed as “C” and “T” on FORWARD strand, or “A” and “G” on the REVERSE strand. To reduce the effect of submission error in our computation of allele frequency, we have recently started to use the following rules:

For the same ss number and population:

• When there is genotype data, we ignore the genotype frequency and allele frequency data.
• When there is only genotype frequency data, we ignore allele frequency data.
• When there are different submitted allele frequencies, we choose the one which has the largest sample size.
• When different frequency data are submitted with same sample size, we ignore them.

The results computed using the above rules are kept in a table named SNPAlleleFreq, which is located in the organism_data directory (this link is to the human_9606 directory) of your organism’s database. The data on the wrong strand (“A” and “G”) was considered in calculating the average allele frequency since the web page was still using all data sources at the time the calculation was performed.

I downloaded human XML and ASN reports for build 125, but found that many of the SNPs in these reports do not have population frequency data.

Some submitters did not submit genotype or frequency data to dbSNP in their submissions; therefore, there is no population frequency data for these SNPs. There are approximately 27 million submitted SNPs in dbSNP, and only 3.5 million of those have frequency data associated with them. (1/9/06)

Frequency Data Discrepancies

Population (2N) Sample Size

Total Sample Size

Population Source Data