<p>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 &quot;top&quot;/&quot;bottom&quot; definition, which can sometimes be inconsistent with the &quot;reference positive&quot; convention.</p>
<p>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 <em>both</em> 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).</p>
<p>The ultimate reference for RS numbers is <a href="https://ncbi.nlm.nih.gov/snp/" rel="nofollow noreferrer">dbSNP</a>, because that's where the RS numbers are dished out for new SNPs.</p>
<p>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 <a href="https://knowledge.illumina.com/microarray/general/microarray-general-reference_material-list/000001521" rel="nofollow noreferrer">Illumina</a>:</p>
<blockquote>
<p>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.</p>
</blockquote>
<pre><code>rs903997 ...ATGAGA*A*AGT[C/G]TGA*G*AGTGCA...
</code></pre>
<p>By Illumina's definition, the above sequence is designated &quot;top&quot;, 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 &quot;bottom&quot;:</p>
<pre><code>rs903997 ...TGCACT*C*TCA[C/G]ACT*T*TCTCAT...
</code></pre>
<p>This is explained more exhaustively in Illumina's technical note:</p>
<p><a href="https://www.illumina.com/documents/products/technotes/technote_topbot.pdf" rel="nofollow noreferrer">https://www.illumina.com/documents/products/technotes/technote_topbot.pdf</a></p>
<p>When I was puzzling over this, I gave up trying to work this out, and filtered out all complementary variants in my dataset.</p>

CC BY-SA 4.0
2023-03-30T20:01:29.700Z
2023-04-02T20:30:51.587Z
2023-04-02T20:30:51.587Z
gringer
<p>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.</p>

CC BY-SA 4.0
2023-03-31T21:56:26.677Z
2023-03-31T21:56:26.677Z
Pete
<p>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.</p>
<p>First of all, orientation is always relative; there is no absolute orientation. When you talk about plus or minus, you have to set a &quot;reference&quot; which could be a reference genome, transcription orientation or even something arbitrary.</p>
<p>Then VCF. Orientation in VCF is always relative to the reference that is used to generate the VCF.</p>
<p>In case of SNPedia, &quot;Orientation&quot; 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 &quot;Orientation&quot; is &quot;minus&quot;, 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.</p>
<p>&quot;Stabilized&quot; 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.</p>
<p>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 &quot;Orientation&quot; and &quot;Geno&quot; based on the rsID. If the orientation is &quot;minus&quot;, complement &quot;Geno&quot; (i.e. &quot;A;C&quot; to &quot;T;G&quot;, etc). Compare the genoptype from the VCF to the genotype association from SNPedia to predict the effect of genotype.</p>
<hr/>
<p>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 &quot;Orientation&quot; without changing the core data. This is a thoughtful design, though the UI could be made clearer.</p>

CC BY-SA 4.0
2023-03-31T23:13:44.997Z
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?
Pete
CC BY-SA 4.0
2023-04-01T00:08:23.610Z
@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.
user172818
CC BY-SA 4.0
2023-04-01T22:08:12.193Z
'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?
Pete
CC BY-SA 4.0
2023-03-31T22:13:45.110Z
2023-04-01T01:03:48.453Z
2023-04-01T01:03:48.453Z
user172818
<p>SNPedia seems to show transcript base change and not genomic base change, so their C&gt;T is the same as the G&gt;A you note.</p>
<p>I don't understand SNPedia's allele notations completely, other sources are more straightforward. Does their <code>A;A</code> mean <code>A</code> on both strands? Then why do they talk about dbSNP showing <code>C;T</code> when dbSNP would in fact show <code>C&gt;T</code> - they seem to use <code>;</code> 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.</p>

CC BY-SA 4.0
2023-03-31T09:46:54.300Z
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?).
Pete
CC BY-SA 4.0
2023-03-31T15:16:33.357Z
"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.
Ram RS
CC BY-SA 4.0
2023-03-31T15:18:12.723Z
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.
Ram RS
CC BY-SA 4.0
2023-03-31T22:12:45.067Z
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.
Pete
CC BY-SA 4.0
2023-03-31T22:17:43.637Z
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.
user172818
CC BY-SA 4.0
2023-03-31T23:02:25.600Z
@user172818 thanks - I don't understand the advantage of this though. Why use C;T and a 'minus' for a genotype that is G;A - why not just use G;A? Can a user of SNPedia always confidently just use the orientation field being minus to flip A-T and G-C in order to get an 'always positive' dataset that will match VCF files and dbsnp without further processing?
Pete
CC BY-SA 4.0
2023-04-03T15:12:55.820Z
From @user172818's comment, it looks like SNPedia lists genotype on cDNA (which makes no sense since transcripts are not double stranded). This semicolon notation is not consistent with 23andMe's online report either. I wonder why this website is popular at all given how different its representation of variants is.
Ram RS
CC BY-SA 4.0
2023-03-29T20:29:05.523Z
2023-03-30T19:39:05.003Z
2023-03-30T19:39:05.003Z
Ram RS
<p>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.</p>
<p>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:</p>
<pre><code>1 36571920 rs96067 G A
</code></pre>
<p>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)).</p>
<p>​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-&gt;C and A-&gt;T meaning my AA becomes TT?</p>
<p>​BTW what confuses me about the SNPedia explanation about orientation is this:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>@terdon: Re where I was quoting from, <a href="https://www.snpedia.com/index.php/Ambiguous_flip" rel="nofollow noreferrer">https://www.snpedia.com/index.php/Ambiguous_flip</a> (<a href="https://www.snpedia.com/index.php/Orientation" rel="nofollow noreferrer">https://www.snpedia.com/index.php/Orientation</a> 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.</p>
<p>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:</p>
<blockquote>
<p>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...</p>
</blockquote>
<p>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?</p>
<p>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&gt;A, dbsnp defines this well, for GRCh37 it shows NC_000001.10:g.36571920G&gt;A. There is also a 'COL8A2 RefSeqGene    NG_016245.2:g.23766C&gt;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&gt;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?</p>

CC BY-SA 4.0
2023-03-31T17:52:28.267Z
Try looking up the variant at https://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.
terdon
<snp>
Can you infer orientation from vcf file data?
# Can you infer orientation from vcf file data?

(Asked by: username_0 on 2023-03-29)

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?

**Tags:** snp
> **Comments:**
> **username_1**: Try looking up the variant at https://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.  

---

## 4 answers

### Answer by username_2 on 2023-03-30. Score: 1

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.


---

### Answer by username_0 on 2023-03-31. Score: 1

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.


---

### Answer by username_3 on 2023-03-31. Score: 1

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.

> **Comments:**
> **username_0**: 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?  
> **username_3**: @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.  
> **username_0**: '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?  

---

### Answer by username_4 on 2023-03-29. Score: 1

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.

> **Comments:**
> **username_0**: 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?).  
> **username_4**: "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.  
> **username_4**: 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.  
> **username_0**: 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.  
> **username_3**: 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.  
> **username_0**: @user172818 thanks - I don't understand the advantage of this though. Why use C;T and a 'minus' for a genotype that is G;A - why not just use G;A? Can a user of SNPedia always confidently just use the orientation field being minus to flip A-T and G-C in order to get an 'always positive' dataset that will match VCF files and dbsnp without further processing?  
> **username_4**: From @user172818's comment, it looks like SNPedia lists genotype on cDNA (which makes no sense since transcripts are not double stranded). This semicolon notation is not consistent with 23andMe's online report either. I wonder why this website is popular at all given how different its representation of variants is.  

---

