<p>So, first off, as others have pointed out, I'm pretty sure that example is just wrong. At least, the numbers don't match as you've pointed out. </p>

<p>That said, it is impossible to be sure without showing us the header of the VCF file as well. The INFO field (the 5th field of a VCF file) is very, very variable and depends entirely on the header lines. Each program (or human) implementing a VCF is free to choose to have whatever they feel like in the INFO field. However, each <code>IDENTIFIER=</code> needs to have an associated INFO line at the beginning of the file. </p>

<p>So, the <code>SVTYPE</code>, <code>SVLEN</code>, <code>HOMLEN</code> etc will have commented (start with a <code>#</code>) lines at the beginning of the file explaining what these values are. So check those, even though they're relatively standard, you never know, the obvious reading you used might be wrong despite its seeming so reasonable. </p>

<p>Here's a newer example of a VCF line for an SV taken from the current <a href="https://github.com/samtools/hts-specs/blob/master/VCFv4.3.pdf" rel="nofollow noreferrer">VCF specification</a>:</p>

<pre><code>##fileformat=VCFv4.1
##fileDate=20100501
##reference=1000GenomesPilot-NCBI36
##assembly=ftp://ftp-trace.ncbi.nih.gov/1000genomes/ftp/release/sv/breakpoint_assemblies.fasta
##INFO=&lt;ID=BKPTID,Number=.,Type=String,Description="ID of the assembled alternate allele in the assembly file"&gt;
##INFO=&lt;ID=CIEND,Number=2,Type=Integer,Description="Confidence interval around END for imprecise variants"&gt;
##INFO=&lt;ID=CIPOS,Number=2,Type=Integer,Description="Confidence interval around POS for imprecise variants"&gt;
##INFO=&lt;ID=END,Number=1,Type=Integer,Description="End position of the variant described in this record"&gt;
##INFO=&lt;ID=HOMLEN,Number=.,Type=Integer,Description="Length of base pair identical micro-homology at event breakpoints"&gt;
##INFO=&lt;ID=HOMSEQ,Number=.,Type=String,Description="Sequence of base pair identical micro-homology at event breakpoints"&gt;
##INFO=&lt;ID=SVLEN,Number=.,Type=Integer,Description="Difference in length between REF and ALT alleles"&gt;
##INFO=&lt;ID=SVTYPE,Number=1,Type=String,Description="Type of structural variant"&gt;
##ALT=&lt;ID=DEL,Description="Deletion"&gt;
##ALT=&lt;ID=DEL:ME:ALU,Description="Deletion of ALU element"&gt;
##ALT=&lt;ID=DEL:ME:L1,Description="Deletion of L1 element"&gt;
##ALT=&lt;ID=DUP,Description="Duplication"&gt;
##ALT=&lt;ID=DUP:TANDEM,Description="Tandem Duplication"&gt;
##ALT=&lt;ID=INS,Description="Insertion of novel sequence"&gt;
##ALT=&lt;ID=INS:ME:ALU,Description="Insertion of ALU element"&gt;
##ALT=&lt;ID=INS:ME:L1,Description="Insertion of L1 element"&gt;
##ALT=&lt;ID=INV,Description="Inversion"&gt;
##ALT=&lt;ID=CNV,Description="Copy number variable region"&gt;
##FORMAT=&lt;ID=GT,Number=1,Type=String,Description="Genotype"&gt;
##FORMAT=&lt;ID=GQ,Number=1,Type=Float,Description="Genotype quality"&gt;
##FORMAT=&lt;ID=CN,Number=1,Type=Integer,Description="Copy number genotype for imprecise events"&gt;
##FORMAT=&lt;ID=CNQ,Number=1,Type=Float,Description="Copy number genotype quality for imprecise events"&gt;
#CHROM POS     ID        REF             ALT QUAL FILTER INFO                                               FORMAT NA00001
1      2827694 rs2376870 CGTGGATGCGGGGAC C   .    PASS   SVTYPE=DEL;END=2827708;HOMLEN=1;HOMSEQ=G;SVLEN=-14 GT:GQ  1/1:13.9
</code></pre>

<p>Note how the numbers do match and also note how each of the subfields in the INFO field is explained with an <code>##INFO</code> line. </p>

CC BY-SA 3.0
2017-05-29T22:34:37.427Z
2017-05-29T22:34:37.427Z
terdon
<p>I just received a reply from 1000Genomes regarding this. I'll post it in its entirety below:</p>

<blockquote>
  <p>Looking at the example you mention, I find it difficult to come up with an
  interpretation of the information whereby the stated end seems to be correct,
  so believe that this may indeed be an error.</p>
  
  <p>Since the v4.0 was created, however, new versions of VCF have been introduced,
  improving and correcting the specification. The current version is v4.3
  (<a href="http://samtools.github.io/hts-specs/" rel="noreferrer">http://samtools.github.io/hts-specs/</a>). I believe the first record shown on
  page 11 provides an accurate example of this type of deletion.</p>
  
  <p>I will update the web page to include this information.</p>
</blockquote>

<p>So we can take this as official confirmation that we were all correct in suspecting the example was just wrong.</p>

CC BY-SA 3.0
2017-06-06T14:15:44.753Z
that was an amazing follow up! :)
ivivek_ngs
CC BY-SA 3.0
2017-06-05T21:05:51.263Z
2017-06-05T21:05:51.263Z
Devon Ryan
<p>The IGSR has a <a href="http://www.internationalgenome.org/wiki/Analysis/Variant%20Call%20Format/VCF%20%28Variant%20Call%20Format%29%20version%204.0/encoding-structural-variants" rel="noreferrer">sample</a> for encoding structural variants in the VCF 4.0 format.</p>

<p>An example from the site (the first record):</p>

<pre><code>#CHROM  POS   ID  REF ALT   QUAL  FILTER  INFO  FORMAT  NA00001
1 2827693   . CCGTGGATGCGGGGACCCGCATCCCCTCTCCCTTCACAGCTGAGTGACCCACATCCCCTCTCCCCTCGCA  C . PASS  SVTYPE=DEL;END=2827680;BKPTID=Pindel_LCS_D1099159;HOMLEN=1;HOMSEQ=C;SVLEN=-66 GT:GQ 1/1:13.9
</code></pre>

<p>How to read it? From what I can see:</p>

<ul>
<li>This is a deletion (<code>SVTYPE=DEL</code>)</li>
<li>The end position of the variant comes before the starting position (reverse strand?)</li>
<li>The reference starts from <code>2827693</code> to <code>2827680</code> (13 bases on the reverse strand)</li>
<li>The difference between reference and alternative is <code>66</code> bases (<code>SVLEN=-66</code>)</li>
</ul>

<p>This doesn't sound right to me. For instance, I don't see where exactly the deletion starts. The <code>SVLEN</code> field says <code>66</code> bases deleted, but where? <code>2827693</code> to <code>2827680</code> only has 13 bases between.</p>

<p><strong>Q:</strong> How to read the deletion correctly from this structural VCF record? Where is the missing 66-13=53 bases?</p>

CC BY-SA 4.0
2019-05-07T11:43:49.467Z
This was fixed in the maintained VCF specifications in 2015 upon being reported as <https://github.com/samtools/hts-specs/issues/84>.
John Marshall
CC BY-SA 3.0
2017-05-29T06:49:45.190Z
I'm pretty sure the `END` value is simply wrong in that example. Maybe send the info@ email address a note regarding this so they can fix it.
Devon Ryan
CC BY-SA 3.0
2017-05-29T12:47:17.727Z
I've taken the liberty of asking the 1000 genomes project about this, I'll post the reply should it still be relevant when I receive it.
Devon Ryan
CC BY-SA 3.0
2017-05-29T13:40:45.410Z
This line is wrong in several aspects. VCF4.0 is something like 5 years old and has long been deprecated. Its spec has also been moved to github. You should read the [latest spec](https://samtools.github.io/hts-specs/VCFv4.3.pdf) instead. The SV example there is correct.
user172818
<vcf><variation><structural-variation>
How to read structural variant VCF?
# How to read structural variant VCF?

(Asked by: username_0 on 2017-05-29)

The IGSR has a sample for encoding structural variants in the VCF 4.0 format.
An example from the site (the first record):
#CHROM  POS   ID  REF ALT   QUAL  FILTER  INFO  FORMAT  NA00001
1 2827693   . CCGTGGATGCGGGGACCCGCATCCCCTCTCCCTTCACAGCTGAGTGACCCACATCCCCTCTCCCCTCGCA  C . PASS  SVTYPE=DEL;END=2827680;BKPTID=Pindel_LCS_D1099159;HOMLEN=1;HOMSEQ=C;SVLEN=-66 GT:GQ 1/1:13.9

How to read it? From what I can see:

This is a deletion (SVTYPE=DEL)
The end position of the variant comes before the starting position (reverse strand?)
The reference starts from 2827693 to 2827680 (13 bases on the reverse strand)
The difference between reference and alternative is 66 bases (SVLEN=-66)

This doesn't sound right to me. For instance, I don't see where exactly the deletion starts. The SVLEN field says 66 bases deleted, but where? 2827693 to 2827680 only has 13 bases between.
Q: How to read the deletion correctly from this structural VCF record? Where is the missing 66-13=53 bases?

**Tags:** vcf, variation, structural-variation
> **Comments:**
> **username_2**: I'm pretty sure the `END` value is simply wrong in that example. Maybe send the info@ email address a note regarding this so they can fix it.  
> **username_2**: I've taken the liberty of asking the 1000 genomes project about this, I'll post the reply should it still be relevant when I receive it.  
> **username_3**: This line is wrong in several aspects. VCF4.0 is something like 5 years old and has long been deprecated. Its spec has also been moved to github. You should read the [latest spec](https://samtools.github.io/hts-specs/VCFv4.3.pdf) instead. The SV example there is correct.  
> **username_1**: This was fixed in the maintained VCF specifications in 2015 upon being reported as <https://github.com/samtools/hts-specs/issues/84>.  

---

## 2 answers

### Answer by username_2 on 2017-06-05. Score: 9 | Accepted answer

I just received a reply from 1000Genomes regarding this. I'll post it in its entirety below:

> Looking at the example you mention, I find it difficult to come up with an
> interpretation of the information whereby the stated end seems to be correct,
> so believe that this may indeed be an error.
>
> Since the v4.0 was created, however, new versions of VCF have been introduced,
> improving and correcting the specification. The current version is v4.3
> (<http://samtools.github.io/hts-specs/>). I believe the first record shown on
> page 11 provides an accurate example of this type of deletion.
>
> I will update the web page to include this information.

So we can take this as official confirmation that we were all correct in suspecting the example was just wrong.

> **Comments:**
> **username_5**: that was an amazing follow up! :)  

---

### Answer by username_4 on 2017-05-29. Score: 4

So, first off, as others have pointed out, I'm pretty sure that example is just wrong. At least, the numbers don't match as you've pointed out. 
That said, it is impossible to be sure without showing us the header of the VCF file as well. The INFO field (the 5th field of a VCF file) is very, very variable and depends entirely on the header lines. Each program (or human) implementing a VCF is free to choose to have whatever they feel like in the INFO field. However, each IDENTIFIER= needs to have an associated INFO line at the beginning of the file. 
So, the SVTYPE, SVLEN, HOMLEN etc will have commented (start with a #) lines at the beginning of the file explaining what these values are. So check those, even though they're relatively standard, you never know, the obvious reading you used might be wrong despite its seeming so reasonable. 
Here's a newer example of a VCF line for an SV taken from the current VCF specification:
##fileformat=VCFv4.1
##fileDate=20100501
##reference=1000GenomesPilot-NCBI36
##assembly=ftp://ftp-trace.ncbi.nih.gov/1000genomes/ftp/release/sv/breakpoint_assemblies.fasta
##INFO=
##INFO=
##INFO=
##INFO=
##INFO=
##INFO=
##INFO=
##INFO=
##ALT=
##ALT=
##ALT=
##ALT=
##ALT=
##ALT=
##ALT=
##ALT=
##ALT=
##ALT=
##FORMAT=
##FORMAT=
##FORMAT=
##FORMAT=
#CHROM POS     ID        REF             ALT QUAL FILTER INFO                                               FORMAT NA00001
1      2827694 rs2376870 CGTGGATGCGGGGAC C   .    PASS   SVTYPE=DEL;END=2827708;HOMLEN=1;HOMSEQ=G;SVLEN=-14 GT:GQ  1/1:13.9

Note how the numbers do match and also note how each of the subfields in the INFO field is explained with an ##INFO line.


---

