Answers.Body: <p>It is a valid multi-allelic entry, and most variant callers produce such entries. However, comparison between two such gets more complicated. With biallelic entries, 2 CHR-POS-REF-ALT entries either match or they don't. With multi-allelic entries, they can match completely, partially or not at all, which means you also need to be able to specify how much of a match is a partial match etc. This is a hindrance in annotation processes that annotate using the CHR-POS-REF-ALT fields.</p>
  <p>This also introduces cases where an indel can become a multi-allelic entry with a nearby SNV like so:</p>
  <pre><code>chr1    100    GA    G
  chr1    101    A    AA
  </code></pre>
  <p>can now be represented as</p>
  <pre><code>chr1    100    GA    G,AA
  </code></pre>
  <p>which can get confusing. Operations are always <em>more predictable</em> when VCF has been decomposed and left-aligned.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-10T14:44:22.290Z
Answers.Text: Good to know this is valid. I'm having trouble interpreting some of the genotypes I'm seeing. Is there a standard way to do this?
Answers.UserDisplayName: Dan Bolser
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-10T18:42:19.017Z
Answers.Text: Can you give me an example of the difficulty you're facing?
Answers.UserDisplayName: Ram RS
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-14T14:27:34.760Z
Answers.Text: Hi @Ram, there are several genotype call combinations that I don't know how to 'decode'. I've written up a report here:
  https://github.com/richarddurbin/pbwt/issues/52#issuecomment-1064125959
  
  The simplest way I can describe it is to say that, if the call is split across two lines (for a tri-allelic variant) the REF part of the call should be the same on both lines, no?
Answers.UserDisplayName: Dan Bolser
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-14T17:07:07.850Z
Answers.Text: I glanced through your thread there and I think you're in the gray area between biology and bioinformatics. VCF entries assume reference sequence is reality, so yes, a multi-allelic site, when split, will have the same REF bases. Assuming that the mutated site is still diploid, a tri-allelic variant will have GT `1/2` where 1 is ALT-1 and 2-ALT-2 (so no REF base)
Answers.UserDisplayName: Ram RS
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-16T14:42:19.747Z
Answers.Text: Right, I'd put that in VCF as something like `./1` and `./1` (assuming I had to split alternative alleles out into separate bi-allelic lines for some reason).
Answers.UserDisplayName: Dan Bolser
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-16T20:05:05.373Z
Answers.Text: Yes, that's what decomposers do - they give you `1/.` GT entries.
Answers.UserDisplayName: Ram RS
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-09T17:47:06.633Z
Answers.LastActivityDate: 2022-03-09T17:47:06.633Z
Answers.UserDisplayName: Ram RS
Body: <p>I'm seeing output from <a href="https://github.com/VertebrateResequencing/pbwt" rel="nofollow noreferrer">PBWT</a> that looks like this:</p>
  <pre><code>3   112841  rs78923776  C   G   .   PASS    RefPanelAF=0.000153988;AN=2;AC=0;INFO=1 GT:ADS:DS:GP    0|0:0,0:0:1,0,0
  3   112841  rs78923776  C   T   .   PASS    RefPanelAF=0.078534;AN=2;AC=1;INFO=1    GT:ADS:DS:GP    0|1:0,1:1:0,1,0
  </code></pre>
  <p>The first line says that my genome is <code>CC</code> at this position, but the second line (for the second alt allele) says that my genome is <code>CT</code> at this position. OK, the first line couldn't say this, so it calls me as REF/REF, but this call has to be interpreted in the context of the second call, and can't be taken at face value.</p>
  <p>That's why I wonder if this is valid VCF or if it's actually breaking the specification.</p>
  <p>The line should be 'squashed' down to the following (I think):</p>
  <pre><code>3   112841  rs78923776  C   G,T .   PASS    RefPanelAF=0.000153988,0.078534;AN=3;AC=0,1;INFO=1  GT:ADS:DS:GP    0|2:0,0:0:1,0,0
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-03-09T13:02:01.443Z
Comments.Text: Many pieces of software can only work with biallelic diploid calls, so they have to split up multiallelic genotypes into separate lines.
Comments.UserDisplayName: user438383
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-03-10T14:45:02.893Z
Comments.Text: Thanks. Is there a standard way to work out the genotype call?
Comments.UserDisplayName: Dan Bolser
Tags: <vcf><file-formats><pbwt>
Title: Is it valid VCF not to 'squash' positions with more than one ALT allele?
ThreadText: # Is it valid VCF not to 'squash' positions with more than one ALT allele?
  
  (Asked by: username_0 on 2022-03-09)
  
  I'm seeing output from [PBWT](https://github.com/VertebrateResequencing/pbwt) that looks like this:
  
  ```
  3   112841  rs78923776  C   G   .   PASS    RefPanelAF=0.000153988;AN=2;AC=0;INFO=1 GT:ADS:DS:GP    0|0:0,0:0:1,0,0
  3   112841  rs78923776  C   T   .   PASS    RefPanelAF=0.078534;AN=2;AC=1;INFO=1    GT:ADS:DS:GP    0|1:0,1:1:0,1,0
  
  ```
  
  The first line says that my genome is `CC` at this position, but the second line (for the second alt allele) says that my genome is `CT` at this position. OK, the first line couldn't say this, so it calls me as REF/REF, but this call has to be interpreted in the context of the second call, and can't be taken at face value.
  
  That's why I wonder if this is valid VCF or if it's actually breaking the specification.
  
  The line should be 'squashed' down to the following (I think):
  
  ```
  3   112841  rs78923776  C   G,T .   PASS    RefPanelAF=0.000153988,0.078534;AN=3;AC=0,1;INFO=1  GT:ADS:DS:GP    0|2:0,0:0:1,0,0
  
  ```
  
  **Tags:** vcf, file-formats, pbwt
  
  > **Comments:**
  > **username_1**: Many pieces of software can only work with biallelic diploid calls, so they have to split up multiallelic genotypes into separate lines.  
  > **username_0**: Thanks. Is there a standard way to work out the genotype call?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2022-03-09. Score: 2
  
  It is a valid multi-allelic entry, and most variant callers produce such entries. However, comparison between two such gets more complicated. With biallelic entries, 2 CHR-POS-REF-ALT entries either match or they don't. With multi-allelic entries, they can match completely, partially or not at all, which means you also need to be able to specify how much of a match is a partial match etc. This is a hindrance in annotation processes that annotate using the CHR-POS-REF-ALT fields.
  
  This also introduces cases where an indel can become a multi-allelic entry with a nearby SNV like so:
  
  ```
  chr1    100    GA    G
  chr1    101    A    AA
  
  ```
  
  can now be represented as
  
  ```
  chr1    100    GA    G,AA
  
  ```
  
  which can get confusing. Operations are always *more predictable* when VCF has been decomposed and left-aligned.
  
  > **Comments:**
  > **username_0**: Good to know this is valid. I'm having trouble interpreting some of the genotypes I'm seeing. Is there a standard way to do this?  
  > **username_2**: Can you give me an example of the difficulty you're facing?  
  > **username_0**: Hi @Ram, there are several genotype call combinations that I don't know how to 'decode'. I've written up a report here: https://github.com/richarddurbin/pbwt/issues/52#issuecomment-1064125959  The simplest way I can describe it is to say that, if the call is split across two lines (for a tri-allelic variant) the REF part of the call should be the same on both lines, no?  
  > **username_2**: I glanced through your thread there and I think you're in the gray area between biology and bioinformatics. VCF entries assume reference sequence is reality, so yes, a multi-allelic site, when split, will have the same REF bases. Assuming that the mutated site is still diploid, a tri-allelic variant will have GT `1/2` where 1 is ALT-1 and 2-ALT-2 (so no REF base)  
  > **username_0**: Right, I'd put that in VCF as something like `./1` and `./1` (assuming I had to split alternative alleles out into separate bi-allelic lines for some reason).  
  > **username_2**: Yes, that's what decomposers do - they give you `1/.` GT entries.  
  
  ---
  
  