0
$\begingroup$

I have a dante labs dataset that I would like to cross reference with SNPedia but I am unclear about orientation. I've read the info on SNPedia and other places about it but I just don't get it yet. I realise this is my own stupidity, the explanations feel sound but they seem to be missing some key info that I can't find anywhere.

Anyway without being too tl;dr about what confuses me, I wonder if my dante vcf file has the orientation problem or not because it shows what the reference genome base is next to the sample base. So for example:

1 36571920 rs96067 G A

Chr:1, Pos: 36571920, rsid:rs96067, reference base:G, sample base: A, (another field later in the line defines that both bases are the alt base so this is an (A;A) where the reference had (G;G)).

​On SNPedia the genotypes mentioned for rs96067 are C;C, C;T and T;T. Since the reference base in my dante file is a G, which does not show up as a possible reference base on the SNPedia page, does this mean that the dante file is flipped with respect to this gene compared to SNPedia and so I should flip one or other if I want to compare them (flip the base in my file or the data from SNPedia that is)? So I guess flip G->C and A->T meaning my AA becomes TT?

​BTW what confuses me about the SNPedia explanation about orientation is this:

Unfortunately if this was instead a SNP where the two alleles are A or T the same flipping logic falls down. We don't (yet) have a way to know for sure if you should be flipped or not, since both forms of your flip rs1234(A;A) and rs1234(T;T) are possible.

Why is AA not the same as TT in this case? Surely this just reflects the direction that the bases were read from, so detection of an AA implicitly means that if we had read from the other direction we would have read TT? I appreciate this is wrong but I don't understand why.

@terdon: Re where I was quoting from, https://www.snpedia.com/index.php/Ambiguous_flip (https://www.snpedia.com/index.php/Orientation also has some info). I've been taking 'flip' as their word for inversion. Re the 'orientation problem' I meant the ambiguity re orientation mentioned in those pages. However you mentioned in your comment that the convention is to always use the + strand. I read up about that and understand now that VCFs use that convention, which answers my question (thanks!). Dbsnp states that it always uses +ve. So like can be compared with like, as long as you use SNP definitions for the correct reference build that your individual SNP VCF has been generated from, and you are using dbsnp as your database. The so called 'flipping' can happen between reference versions/builds and could trip you if you don't use the correct one. Thats what I have gathered to this point, do let me know if its not right.

On SNPedia however many rsid's seem to be defined as minus orientation. They have 2 fields, orientation and stabilised orientation. To quote from the above linked pages:

Orientation indicates the orientation reported in the most current build (currently GRCh38), which is reported below the genotypes in the Reference field. The chromosome number and nucleotide position in that reference build is shown next. StabilizedOrientation is the orientation that is relevant to the genotypes that have been defined in SNPedia for each SNP...

So they are saying that GRCh38 has both plus and minus orientation within and each genotype includes an orientation field? How does this fit with the standard '+ve' convention you mentioned? Maybe these are 2 different things and I just misunderstand. But it would seem far more sensible to simply adjust GRCh38 to all +ve. Is this 'orientation problem' just SNPedias problem? What exactly do they mean on the above linked pages on orientation and ambigous flips?

SNPedia seems pretty useful if it can be made to work - there is lots of associated data on each genotype page, the API is easy to use including for agregated queries etc, but it seems way less reliable than dbsnp despite apparently simply taking their data from dbsnp. Taking the above example I mentioned, rs96067 G>A, dbsnp defines this well, for GRCh37 it shows NC_000001.10:g.36571920G>A. There is also a 'COL8A2 RefSeqGene NG_016245.2:g.23766C>T' entry which I don't fully understand. However on SNPedia as I said all that shows up are C;C, C;T and T;T genotypes. Maybe they are referring to the COL8A2 C>A entry on dbsnp - or did they scrape this SNP def badly? Or are they showing transcript change rather than genomic as Ram RS suggested?

Improve this question
$\endgroup$
1
  • $\begingroup$ Try looking up the variant at varsome.com. We (I work for the company that builds VarSome, but it is a free tool) integrate data from very many different sources and also show a genome browser which can help put the variant in context. Having a third, orthogonal, source might help clarify the confusion. $\endgroup$
    – terdon ♦
    Mar 31 at 17:52

4 Answers 4

Reset to default
1
$\begingroup$

SNPedia seems to show transcript base change and not genomic base change, so their C>T is the same as the G>A you note.

I don't understand SNPedia's allele notations completely, other sources are more straightforward. Does their A;A mean A on both strands? Then why do they talk about dbSNP showing C;T when dbSNP would in fact show C>T - they seem to use ; to mean alleles and base change interchangeably, and that is confusing. I recommend sticking to dbSNP for all information not found in SNPedia - something tells me SNPedia is not as trustworthy.

Improve this answer
$\endgroup$
7
  • $\begingroup$ I see what you mean regarding SNPedia, the interchangeable use of the semicolon was actually one of the aspects that was confusing me so I'm glad its not just me. I spent a bit of time checking dbsnp and as you say its always clear. Two problems though, they don't seem to have an API that is as fast easy to use (although I am still trying to get my head round it). And SNPedia summarises related studies which is useful. Re the transcript vs base change, are you sure? I assumed this was just caused by the differences between hg19 and 38 because (once again) its inconsistent (no docs?). $\endgroup$
    – Pete
    Mar 31 at 9:46
  • $\begingroup$ "SNPedia summarizes related studies" - you're going to need to deal with them for that dataset, no way around it. As for dbSNP, you should be able to download a VCF from them that contains all the info you need. $\endgroup$
    – Ram RS
    Mar 31 at 15:16
  • $\begingroup$ I checked dbSNP and SNPedia for the transcript vs genomic change. SNPedia corresponds to dbSNP's hg38 transcript base change and your input matches dbSNP's hg19 genomic base change. That's the link from your input to SNPedia. I don't know how to proceed with SNPedia though, as their conventions are quite confusing. $\endgroup$
    – Ram RS
    Mar 31 at 15:18
  • $\begingroup$ Re needing to deal with SNPedia as you say there seems no other way. Although I haven't checked properly it looks like it is a true 'wikipedia' type db with users creating all the summaries and such - theres good and bad in that but when you have so many SNPs to scan I think their approach has value. No need to take what they write as fact but more as an indicator to look more deeply at a particular SNP, perhaps ignore their genotype specific data, instead look at what a particular rsid might have associated with it and if its interesting dig into specific genotypes via another tool. $\endgroup$
    – Pete
    Mar 31 at 22:12
  • $\begingroup$ SNPedia uses ; to separate the two alleles in a genotype. A;A means a (A,A) homozygous genotype. Similarly, C;T is a (C,T) heterozygous genotype. minus indicates the genotype on the GRCh38 strand is (G,A) instead. SNPedia doesn't care about the reference allele. $\endgroup$
    – user172818
    Mar 31 at 22:17
1
$\begingroup$

To answer (a small) part of my own question 'Why is AA not the same as TT in this case?' - I believe the answer to this is that the flanking sequence is important here. We can't just flip an AA to a TT in the middle of a strand without having any effect unless we also flip the flanking sequence also. What matters is the relation between the particular base in question and its flanking sequences. I didn't appreciate that before for some reason but its pretty obvious.

Improve this answer
$\endgroup$
1
$\begingroup$

SNPedia introduces its own orientation to cut the tie to a reference genome, such that the bulk data is independent of the reference genome in use. The intention is good. The implementation is ok. It is just a bit confusing.

First of all, orientation is always relative; there is no absolute orientation. When you talk about plus or minus, you have to set a "reference" which could be a reference genome, transcription orientation or even something arbitrary.

Then VCF. Orientation in VCF is always relative to the reference that is used to generate the VCF.

In case of SNPedia, "Orientation" is secondary information that is relative to GRCh38, the current human reference genome (PS: this field changes with the reference genome but the internal primary strand system doesn't). rs96067 has two alleles C and T. Because its "Orientation" is "minus", the alleles on the GRCh38 strand is G and A, consistent with the dbSNP information. I checked a few other SNPs. It seems that SNPedia doesn't tell you which is the allele in the reference genome. This is actually fine because what matters is the genotype.

"Stabilized" orientation is relative to an arbitrary orientation stored in the SNPedia database. It is not directly relevant to your question when both you and SNPedia use the same reference genome.

How to use SNPedia? When you have a VCF in the GRCh38 coordinate, traverse rsIDs in the VCF. For each rsID, extract the genotype in the GRCh38 coordinate. Then get the SNPedia "Orientation" and "Geno" based on the rsID. If the orientation is "minus", complement "Geno" (i.e. "A;C" to "T;G", etc). Compare the genoptype from the VCF to the genotype association from SNPedia to predict the effect of genotype.

PS (clarification in response to new comments): if you design a database that ties to GRCh38 from ground up, you may need to flip many genotypes when the reference genome is changed. This process is complex and error prone. With their current design, if the reference genome is changed, they only need to update "Orientation" without changing the core data. This is a thoughtful design, though the UI could be made clearer.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thanks, very helpful. But I'm unclear about this - 'SNPedia introduces its own orientation to cut the dependency to a reference genome.' vs 'In case of SNPedia, "Orientation" is relative to GRCh38, the current human reference genome.' Those seem to conflict. Surely if orientation is relative to GRCh38 we are still dependant on GRCh38? Otherwise it seems to me + or - is meaningless. What does orientation add? Why not just correct all SNPs to +ve orientation and miss out the orientation field? In fact where did the flip to minus come from - if dbsnp is all +ve, how come snpedia has -ve entries? $\endgroup$
    – Pete
    Mar 31 at 23:13
  • $\begingroup$ @Pete see update. Yes, the two sentences were a bit conflictive. Want to emphasize that "Orientation" is secondary. Their database has its own primary strand system independent of GRCh38. $\endgroup$
    – user172818
    Apr 1 at 0:08
  • $\begingroup$ 'Their database has its own primary strand system' - thanks that makes it all fall into place. IIRC even the patch version of the ref dataset matters here (strand can flip from patch version to patch version), so you need your VCF to have been generated against the exact GRCh38-patchX that SNPedia have used to generate their orientation values to be sure you have no errors. How can you map from what they have used (GRCh38-patchX) to GRCh38-patchY or even GRCh37-patchZ? Is the stabilised orientation field relevant there? I can think of a way using dbsnp but is there no simpler way? $\endgroup$
    – Pete
    Apr 1 at 22:08
0
$\begingroup$

Strand flips are common when using different VCF generation software. You've got one of the easier-to-determine variants there, because it's pretty clear that the orientation is incorrect between SNPedia and your VCF file. Illumina is particularly frustrating in this regard because they have a "top"/"bottom" definition, which can sometimes be inconsistent with the "reference positive" convention.

The reason strand for complementary variants can't be [easily] determined is because the usual way to fix strand in a bulk fashion is to check for which of the variant or it's complement are present in the reference database. If the variant is a complementary variant, then both will be found (one as the reference allele, and the other as the alternate variant allele). There are some statistical ways to work round this (e.g. looking at the most common variant in your dataset, and comparing it to the highest allele frequency in the reference database), but those methods will fail if the ancestral background of your study population is substantially different from the reference population (which was the case for the population genetics work I was doing).

The ultimate reference for RS numbers is dbSNP, because that's where the RS numbers are dished out for new SNPs.

Illumina claims that their top/bottom definition allows them to precisely determine complementary strand orientation, but it's useless unless the full sequence context is provided (i.e. the surrounding sequence up until strand can be determined by reverse complementation). Here's the explanation from Illumina:

For SNPs that are not [A/T] or [G/C], A is always on the top strand and T is always the bottom strand. A and T nucleotides are the “A alleles”; G and C nucleotides are the “B alleles”. If the SNP is [A/T] or [G/C]: Use sequence walking to determine TOP/BOT strands, then assign A/B alleles.

rs903997 ...ATGAGA*A*AGT[C/G]TGA*G*AGTGCA...

By Illumina's definition, the above sequence is designated "top", because if you walk outwards from the variant location, you eventually get to a situation where A is present on one side, and C or G is present on the other side. The reverse complement of this sequence would be designated "bottom":

rs903997 ...TGCACT*C*TCA[C/G]ACT*T*TCTCAT...

This is explained more exhaustively in Illumina's technical note:

https://www.illumina.com/documents/products/technotes/technote_topbot.pdf

When I was puzzling over this, I gave up trying to work this out, and filtered out all complementary variants in my dataset.

Improve this answer
$\endgroup$
3
  • $\begingroup$ I've been really struggling to understand this. Why will both a variant and its complement be found in the ref db if the variant is a complement? Just to check I understand, we are saying the ref is (say) a G, the variant changes that to a T (so G>T). The complement of the T is an A - right? But the ref db still only has GG at this position. Or is a complementary variant a more complex type of variant than a simple base change? Sorry for the probably dumb questions. I'm a beginner... $\endgroup$
    – Pete
    Mar 31 at 12:20
  • $\begingroup$ I've added additional clarification: "one as the reference allele, and the other as the alternate variant allele" $\endgroup$
    – gringer ♦
    Mar 31 at 19:06
  • $\begingroup$ What is this "top/bottom" approach of Illumina's? Can you link to some documentation of it? $\endgroup$
    – terdon ♦
    Apr 2 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.