text: user8875: I'm seeing output from 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
  
  
  user650: 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.
  
original_text: 8875: <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>
   650: <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>
  