Understood. I repeated the process as I did earlier today. What had initially prompted me to send the email was that when I clicked the reference link as directed from the UCSC 132 allsnps track for rs12777, i was getting "invalid snp cluster" result from NCBI, whereas this was not the case for rs10479002.
Regardless, for the former, I now get a report instead of a broken link, and for the latter, it now reports that it has been merged (to the former). So it seems that the inconsistency was theirs, not yours. Anyway, both y'all do great work, and thanks for the service. ~alden On Wed, Mar 21, 2012 at 5:13 PM, Steve Heitner <[email protected]> wrote: > Hello, Alden. > > I input your first two SNP IDs in the position/search box on hg19 > (rs10479002 is located at chr5:131,671,412-131,671,912 and rs10510146 is > located at chr10:127,295,895-127,296,395). If I click on one of the HapMap > results on the search results page and then click on the items in the HapMap > SNPs main track display, at the very top of the results page is an item > called SNP rsId which takes you to NCBI. When I clicked on the links, I > found that rs10479002 had been merged into rs12777 > (http://www.ncbi.nlm.nih.gov/SNP/snp_ref.cgi?type=rs&rs=rs10479002) and > rs10510146 had been merged into rs9422897 > (http://www.ncbi.nlm.nih.gov/SNP/snp_ref.cgi?type=rs&rs=rs10510146). > > It is also important to note that the older SNP IDs you listed are part of > the HapMap SNPs track and not the Common SNPs(132) track. In the Browser, > if you scroll down to the Variation and Repeats section of the track > listings, you will see the number "18" to the left side of the HapMap SNPs > track name. This indicates that the coordinates for the data in this track > were lifted over from hg18 (please see > http://genome.ucsc.edu/goldenPath/help/hg18ToHg19LiftOver.html). If you > perform your search in the Table Browser using hg18 and the HapMap SNPs > track, you will find the IDs you listed. When you search Common SNPs(132) > in hg19 in the Table Browser, however, you will only find the newer IDs. > > I hope this helps. > > Please contact us again at [email protected] if you have any further > questions. > > --- > Steve Heitner > UCSC Genome Bioinformatics Group > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Alden Huang > Sent: Wednesday, March 21, 2012 12:12 PM > To: [email protected] > Subject: [Genome] dbsnp invalid cluster ids > > Hi, > > I just happen to be looking at a bunch of snps. Ive noticed some issues with > these in particular: > rs10479002 > rs10510146 > rs7422339 > rs7826222 > rs8192284 > They are listed as non-existent when I do a table search for those > particular RSIDs in dbSNP 132. > > However, when I search in the UCSC Genome Browser interface (that i guess > queries all tables) I do get those as hapmap snps. > > When I click on the browser location result for the snp query there are > entries that appear on the dbSNP track; however these are invalid cluster > ids for dbsnp. > > I only checked like the first three of the list above. > > Thanks, > > alden > _______________________________________________ > Genome maillist - [email protected] > https://lists.soe.ucsc.edu/mailman/listinfo/genome > _______________________________________________ Genome maillist - [email protected] https://lists.soe.ucsc.edu/mailman/listinfo/genome
