Add support for mito m. in translate_from

[larrybabb]

Added missing support for m. mitochondrial translation from hgvs, beacon, gnomad and spdi formats. Also added mapping of NR_ refseq accessions to n. nomenclature.

[larrybabb]

meant to make this a draft PR. I'll try again.

[korikuzma]

@larrybabb I got you

[korikuzma]

@ahwagner IIRC you had said you had comments that were not submitted. Did you want to review?

[ahwagner]

A few minor comments included, but my greatest concern is how circular sequences are handled; SequenceLocation requires start <= end, but this is based on sequence linearity assumptions. Should we update the VRS model to allow end < start for circular sequences? If not, how do we plan to handle variants that span the 0 coordinate?

[ahwagner]

Do we not want to support X{MRP}_ accession prefixes?

[larrybabb]

Yes, we should. I just hit these use cases in clinvar. there's not many. and the vrs-python seqrepo does have the XM_... accessions available.

[ahwagner]

What are NW accessions? I found one associated with a linear Zebrafish reference sequence, but have a hard time finding documentation on what this prefix means and how it should be interpreted.

[korikuzma]

https://hgvs-nomenclature.org/stable/background/refseq/?h=nw#recommended-reference-sequences-types-are

genomic contigs or scaffolds - NT_010718.17, NW_003315950.2

[larrybabb]

there are 182 hgvs expressions in clinvar that have NW_ associated expressions. Here are a couple if it helps to discern what they are...
https://www.ncbi.nlm.nih.gov/clinvar/variation/146167
(patch scaffolding?)

[ahwagner]

@larrybabb should we also add "NT"?

[ehclark]

My own $0.02 on the circular sequence question. And I'm really just considering human mitochondrial variants here.

Supporting circular reference sequences and allowing locations that span the zero point seems like a solution in search of a problem. My reasons for thinking this:

• ClinVar does not list any variants close to the zero point
• The gnomAD 3.1 variants close to the zero point are all substitutions or not problematic (meaning normalization does not expand them over the zero point)
• The other formats and tools that will be upstream of VRS computation (HGVS, VCF) all treat the mitochondrial chromosome as a linear sequence or do not support variants that span the zero point

For example, I ran this test in Variant Validator:

Unable to validate the submitted variant NC_012920.1:m.16568_3del against the GRCh38 assembly. The following warnings were returned:

The variant positions are valid but we cannot normalize variants spanning the origin of circular reference sequences

And from a human biology standpoint I would think that in/dels that disrupt the zero point and replication would be highly unlikely to be compatible with life?

[larrybabb]

@ehclark I agree completely with your points. I also think we should state this clearly as a policy decision and address it in the future if/when the need is presented by the community and the priority is high enough.

[ahwagner]

Respectfully, I disagree about this not being a problem. Spanning the mitochondrial origin is something that resources like gnomAD do struggle with. For example, from the gnomAD mitchondrial origin calling documentation:

Circular genome: The mtDNA non-coding “control region” spans the artificial break in the circular genome (coordinates chrM:16024-16569 and chrM:1-576), which can make it challenging to call variants in this region. Therefore to call control region variants, we extracted all chrM reads and realigned them to a mitochondrial reference that was shifted by 8,000 bases, called variants on this shifted alignment, and then converted coordinates back to their original positions.

I also want to disentangle the concern I raised (how do we represent these variants) from the concerns raised by @ehclark (how do you normalize these variants). Whether or not we want to add support for normalization over the origin, the fact is that HGVS expressions (such as the submitted NC_012920.1:m.16568_3del in the above example) can represent a variant spanning the origin, and VRS cannot. So, to be clear, I think we minimally need to allow people to represent sequence regions that span the origin when we consider adding support for mitochondrial variants. @larrybabb and @ehclark, I just want to check; are you disagreeing that is needed and that we should move forward without supporting such representations?

[ehclark]

@ahwagner The main point I am trying to make is that variants spanning the origin point don't actually seem to exist in the real world (at least based on current data) and therefore expending engineering effort and increasing complexity to support them is not worthwhile.

That said, I think your point about separating the various concerns here makes sense. To build on your points, it seems there are three basic elements:

• The VRS model representation of circular sequence locations that span the origin point
• The normalization of alleles across the origin point
• The conversion between VRS and other representations (HGVS, gnomAD, etc) where the origin point is crossed

Most of the engineering complexity is wrapped up in the normalization element. I interpret your comment to mean you think that VRS model representation is a must-have because it is necessary to allow the model to accurately represent circular sequence locations. And it seems that supporting the representation would not be complicated.

I would also note that as of right now, vrs-python will happily create VRS objects/ids for mitochondrial variants converting from gnomAD format, which is what the VCF annotator uses, and assuming a linear sequence. So if the VRS model changes to support sequence locations with start > end, it would be a breaking change. So getting this resolved would be high on my priority list.

[larrybabb]

@ahwagner would you mind reviewing this asap. I reverted the secondary concern I found regarding the lack of support of c. hgvs notation so that we could get this m. support PR completed.

[larrybabb]

fixes bug #360