Handle variants unsupported by VV by translating them first

[ifokkema]

VV doesn't support all HGVS variants, e.g. variants with uncertain positions or methylation-related variants. The VV library could handle these by translating them to supported variants before submitting them to VV, and translating the variants back when the reply comes in. This will allow us to still map these variants from genome to transcripts and vice versa. If we keep these translations within the VV library, they can more easily be dropped if VV will include support for these.

• Make a list of unsupported variants.
  • Complex insertions, including ins100_200 and ins[...] (source). This may be hard to translate. Insertions like insA[10] are supported.
  • Methylation-related variants, can be translated to = variants.
  • Variants with uncertain positions, can be split into multiple = variants.
  • "Or" variants, e.g., c.123^124G>C, can be split into multiple variants (currently unsupported by LOVD as well).
  • Repeats, need some more work but can be translated to = variants.
  • pter, cen, qter variants, but maybe mapping those is senseless (see also Add mapping support for variants only partially intergenic openvar/variantValidator#333).
  • More?
• This feature is only meant for when mapping is requested. If no mapping has been requested, don't call VV but just return a fake reply.
• A wrapper function should translate or split the variant and call the regular VV function using the translated value.
• Once the reply comes back, translate the variant back to the original type in VV's reply.

Related:

• The loss of methylation syntax returns unexpected error. openvar/variantValidator#206
• Alignment with LOVD - Complex Variant Handling openvar/variantValidator#328

Possibly related (would need more work, better try to handle this in VV itself):

• Add mapping support for variants only partially intergenic openvar/variantValidator#333

[Peter-J-Freeman]

We have an open project to handle these variants. I recommend a coordinated effort here otherwise you guys will write code that becomes redundant very quickly. This is a priority project so I am committing all available resource to it. Can we please set up a meeting to discuss.

Here is the link to the issue
openvar/variantValidator#328

[ifokkema]

After discussing this in a meeting;

• Methylation-related variants will be handled within VV (Handling loss / gain of Methylation syntax openvar/variantValidator#335).
• Repeat variants will be handled within VV (Handle Expanded Repeat Syntax openvar/variantValidator#336).
  • Note, that VV might return dels/ins/dups in this case, and the repeat syntax as an extra annotation. If this will be the case, we need to handle this in LOVD.