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?