VCF specs - Clarification of <DUP> vs <DUP:TANDEM>

[davmlaw]

Hi, thanks for all your hard work maintaining the specs

I recently processed a Manta VCF that had alt=<DUP:TANDEM>

In the VCFv4.5 spec (also 4.2, and possibly earlier) the symbolic alts are defined as:

DUP Region of elevated copy number relative to the reference, or a tandem duplication breakpoint
DUP:TANDEM Tandem duplication

I am wondering are there any cases where <DUP> represents a duplication that is not tandem?

If not, is there a a reason for having both? A downside of multiple representations for the same molecular event is tools / users miss that a variant is the same

[d-cameron]

Yrs. A <DUP> call made by a CNV caller may be a dispersed duplication. For example a dup call at the donor site of a MEI insertion is not a tandem duplicate of the mobile element. Generally speaking, <DEL>/<DUP> calls made by an SV caller are implicitly SVCLAIM=J and those from a CNV caller are all SVCLAIM=D. SVCLAIM was added in 4.4 to remove this ambiguity.

…

On Wed, 5 Feb 2025, 14:11 Dave Lawrence, ***@***.***> wrote: Hi, thanks for all your hard work maintaining the specs I recently processed a Manta VCF that had alt=<DUP:TANDEM> In the VCFv4.5 spec <https://samtools.github.io/hts-specs/VCFv4.5.pdf> (also 4.2, and possibly earlier) the symbolic alts are defined as: DUP Region of elevated copy number relative to the reference, or a tandem duplication breakpoint DUP:TANDEM Tandem duplication I am wondering are there any cases where <DUP> represents a duplication that is not tandem? If not, is there a a reason for having both? A downside of multiple representations for the same molecular event is tools / users miss that a variant is the same — Reply to this email directly, view it on GitHub <#811>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOBYOCKOG2EOKURFREH4UD2OF6PHAVCNFSM6AAAAABWQA6M5GVHI2DSMVQWIX3LMV43ASLTON2WKOZSHAZTCNZVGI2DENA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[d-cameron]

Note that your manta call is not actually making a claim of a tandem duplication It's claiming to have found a breakpoint consistent with a tandem duplication. Such a breakpoint could be consistent with other interpretation. For example, the duplication-like breakpoint could be part of a large chromothripsis event (hence why 4.4 has EVENT & EVENTTYPE fields). On Thu, 6 Feb 2025, 15:18 Daniel Cameron, ***@***.***> wrote:

…

Yrs. A <DUP> call made by a CNV caller may be a dispersed duplication. For example a dup call at the donor site of a MEI insertion is not a tandem duplicate of the mobile element. Generally speaking, <DEL>/<DUP> calls made by an SV caller are implicitly SVCLAIM=J and those from a CNV caller are all SVCLAIM=D. SVCLAIM was added in 4.4 to remove this ambiguity. On Wed, 5 Feb 2025, 14:11 Dave Lawrence, ***@***.***> wrote: > Hi, thanks for all your hard work maintaining the specs > > I recently processed a Manta VCF that had alt=<DUP:TANDEM> > > In the VCFv4.5 spec <https://samtools.github.io/hts-specs/VCFv4.5.pdf> > (also 4.2, and possibly earlier) the symbolic alts are defined as: > > DUP Region of elevated copy number relative to the reference, or a tandem duplication breakpoint > DUP:TANDEM Tandem duplication > > I am wondering are there any cases where <DUP> represents a duplication > that is not tandem? > > If not, is there a a reason for having both? A downside of multiple > representations for the same molecular event is tools / users miss that a > variant is the same > > — > Reply to this email directly, view it on GitHub > <#811>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABOBYOCKOG2EOKURFREH4UD2OF6PHAVCNFSM6AAAAABWQA6M5GVHI2DSMVQWIX3LMV43ASLTON2WKOZSHAZTCNZVGI2DENA> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[davmlaw]

Thanks. I didn't know about SVCLAIM (though I haven't seen VCF 4.4+ in the wild)

I want to represent VCF variants from many different callers in 1 and only 1 way (database constraint to ensure uniqueness)

It looks like: <DUP> SVCLAIM=J and <DUP:TANDEM> SVCLAIM=J describe the same thing?

So it would be right to normalize the first into the second (being more explicit?)

[davmlaw]

Actually, thinking about it more, I'm always going to have <= 4.3 VCF records, so there is ambiguity in those <DUP>s. There might be in any SVCLAIM call too (as it's all just best guesses all the way down to the base call)

So if I want to group together records that may be the same, I'd be better off "downcasting" <DUP:TANDEM> to <DUP> to link with plain <DUP>s as they could be the same event between samples, level but keeping the callers claims (eg SVCLAIM or <DUP:TANDEM> etc) for that sample call

[davmlaw]

Imagine you wanted to merge 3 vcf files

A: <DUP>
B: <DUP> SVCLAIM=J
C: <DUP:TANDEM> SVCLAIM=J

I think they should be merged, but you can't do that without losing information as you'd have to throw away SVCLAIM

It seems that SVCLAIM should be a per-sample FORMAT field?

[d-cameron]

It seems that SVCLAIM should be a per-sample FORMAT field?

It's an INFO field as it's defining the meaning of the ALT field.

I think they should be merged, but you can't do that without losing information as you'd have to throw away SVCLAIM

If you're merging pre-4.4 records with 4.4 records then the merging code need to resolve the ambiguity of the <DUP> claim. Generally speaking, that requires knowing the providence of the VCF (i.e. did it come from an SV caller or a CNV caller?).

The use case of being able to support both ambiguous and unambiguous <DEL>/<DUP> records within a single VCF file is not sufficiently compelling so as to justify a change to the definition of the SVCLAIM field.

I want to represent VCF variants from many different callers in 1 and only 1 way (database constraint to ensure uniqueness)

This is going to be more difficult than you envisage. Take the following haploid haplotype an example:

REF: ACGTTTACG
ALT: ACGTTTTTTACG

This 3bp tandem duplication haplotype can be represent in VCF by many variants including the following:

chr 1 full_chr_sequence ACGTTTACG ACGTTTTTTACG

chr 4 vrs_normalised TTT TTTTTT

chr 3 left_aligned G GTTT

chr 4 tr_start T  TTTT

chr 5 centre_aligned T TTTT

chr 6 right_aligned T TTTT

chr 6 right_aligned_bases_prepended A TTTA

chr 3 symbolic_dup G <DUP> END=6

chr 3 symbolic_dup_tandem G <DUP:TANDEM> END=6

chr 3 symbolic_dup_subtype G <DUP:anything:you:want> END=6

chr 3 symbolic_ins_pos3 G <INS> SVLEN=3

chr 4 symbolic_ins_pos4 T <INS> SVLEN=3

chr 5 symbolic_ins_pos5 T <INS> SVLEN=3

chr 6 symbolic_ins_pos6 T <INS> SVLEN=3

chr 4 breakend_dup_notation_record_A T ]chr:6]T MATEID=breakend_dup_notation_record_B
chr 6 breakend_dup_notation_record_B T T[chr:4[ MATEID=breakend_dup_notation_record_A

chr 3 breakend_ins_A_pos3 G GTTT[chr:4[ MATEID=breakend_ins_B_pos3
chr 4 breakend_ins_B_pos3 T ]chr:3]TTTT MATEID=breakend_ins_A_pos3 

chr 3 breakend_delins_A G GTTTTTT[chr:7[ MATEID=breakend_delins_B 
chr 7 breakend_delins_B A ]chr:3]TTTTTTA MATEID=breakend_delins_A 

chr 3 cnv G <CNV> END=6;CN=2

chr 3 cnv_tr G <CNV:TR> SVLEN=3 GT:RU:RUS:CN 1:6:T:2


chr 3 decomposed_into_smaller_insertions_A A AT
chr 4 decomposed_into_smaller_insertions_B T TT
chr 6 decomposed_into_smaller_insertions_C T TT