Fix vvHGVS RNA parser

[Peter-J-Freeman]

Is your feature request related to a problem? Please describe.
The RNA parser in vvHGVS used the n. numbering. It should use the c. numbering.

Additional context
It should also use lower case.

We would also need to update VV to handle, but this would allow us to offer RNA variant allele syntaxes etc which currently is impossible as we cannot parse correctly.

[leicray]

Is it relevant that variants discovered/confirmed by RNAseq will be reported using r. numbering?

[Peter-J-Freeman]

Is it relevant that variants discovered/confirmed by RNAseq will be reported using r. numbering?

Very much. VV does this correctly, but needs a to manupulate things a lot because vvHGVS applies the wrong numbering and Alphabet for r. It was the Reece's original misunderstanding that r. is equivalent to n. which we now know is incorrect.

For single variants, VV works fine, but for alleles, it cannot do the necessary checks beofee creating individual variants that VV handles. So we cannot suport allele r. Its low priority, butI added this to flag it. It will be a bit of a project to fix!!

[ifokkema]

Is your feature request related to a problem? Please describe. The RNA parser in vvHGVS used the n. numbering. It should use the c. numbering.

Except for non-coding transcripts, of course, but I assume this is about coding transcripts...

Additional context It should also use lower case.

There is actually a whole discussion (here and here) going on about that, but it hasn't been resolved yet due to discussions on what source to trust. Either way, there is no support for using lowercase letters for RNA sequences anymore, so this will soon disappear from the HGVS Nomenclature. The discussion currently focuses on dropping U in favor of T.

[Peter-J-Freeman]

@ifokkema, whereas the anal side of me thinks the IUPAC code is the standard and should be used, dropping the need for lower case would make life much easier for us. It would mean we can simply fix the vvHGVS parser with the c. numbering and not the n. numbering and always use upper case, which would mean that the parser, normalizers and mappers would just work.

I think the workflow would match the current workflow i.e.

• Parse r. description
• Convert to c. description
• Convert back to r. (ensuring shufflinf and translations use a normalizer that omits introns)
• Return data

It would just really simplify things and likely we could lose quite a lot of code and would be able to use the inpuilt vvHGVS machinery correctly as well as being able to support r. alleles. We may well also be able to drop the need to convert from r. to c., depending on what everything look like when the tooling is updated

[ifokkema]

The interesting thing is that IUPAC, apparently, never recommended using lowercase letters. Nobody knows anymore where our requirement to do so for RNA comes from... good to hear it actually makes your life easier when it's dropped!

[Peter-J-Freeman]

the first bit of offencing code is this

def_c_pos = base:b offset:o
-> BaseOffsetPosition(..., datum=CDS_START)

def_n_pos = base:b offset:o
-> BaseOffsetPosition(..., datum=SEQ_START)

def_r_pos = base:b offset:o
-> BaseOffsetPosition(..., datum=SEQ_START)

It is here https://github.com/openvar/vv_hgvs/blob/master/vvhgvs/_data/hgvs.pymeta#L154

def_r_pos = base:b offset:o -> vvhgvs.location.BaseOffsetPosition(b,o,datum=vvhgvs.enums.Datum.SEQ_START)

should be

def_r_pos = base:b offset:o -> vvhgvs.location.BaseOffsetPosition(b,o,datum=vvhgvs.enums.Datum.CDS_START)

Also, in

https://github.com/openvar/vv_hgvs/blob/master/vvhgvs/validator.py#L85

This would need to return an error stating that if type is r., then Introns are not relevant to r. descriptions as opposed to just the warning for c. as shown.

Making these changes may have knock on issues in vv_hgvs, but this is the start of it all

[Peter-J-Freeman]

@John-F-Wagstaff interesred to know what you think. In addition to this, the normalizer for r. descriptions would need to allow boundary crossing.

[Peter-J-Freeman]

The second bug is in normalizer.py.

At the moment it explicitly treats r. as if it were n.:

if var.type in "nr":
if var.posedit.pos.start.offset != 0 or var.posedit.pos.end.offset != 0:
raise HGVSUnsupportedOperationError(
"Normalization of intronic variants is not supported"
)

and later

if var.type == "r" or var.type == "n":

and earlier there is even a comment saying

g, m, n, r sequences all use sequence start as the datum

That's an essential assumption herein

That comment is simply incorrect according to HGVS.

RNA (r.) coordinates use the coding transcript numbering system (equivalent to c. numbering, minus the * notation for 3' UTR), not the n. sequence-start numbering.

So after fixing the parser, this assumption becomes invalid.

I would separate the handling

Instead of

if var.type in "nr":

I'd have

if var.type == "n":
if var.posedit.pos.start.offset != 0 or var.posedit.pos.end.offset != 0:
raise HGVSUnsupportedOperationError(
"Normalization of intronic variants is not supported"
)

elif var.type == "r":
if (
var.posedit.pos.start.offset != 0
or var.posedit.pos.end.offset != 0
):
raise HGVSInvalidVariantError(
"RNA variants cannot contain intronic coordinates"
)

because an r. variant with an intronic offset isn't merely "unsupported"—it's not a valid HGVS description.

Likewise, _get_boundary() currently begins

if var.type == "r" or var.type == "n":

That probably shouldn't exist as a shared branch anymore. r. should probably bypass exon-boundary logic entirely because there are no introns in RNA descriptions. The exon lookup is only meaningful for n. coordinates, where intronic offsets can exist.

[Peter-J-Freeman]

The validator also assumes that r. behaves like n..

The first place is here:

BASE_OFFSET_COORD_TYPES = "cnr"

That means _ref_is_valid() treats all c., n. and r. variants with offsets as intronic variants:

if (var.type in BASE_OFFSET_COORD_TYPES
and var.posedit.pos is not None
and (var.posedit.pos.start.offset != 0
or var.posedit.pos.end.offset != 0)):
return (
ValidationLevel.WARNING,
"Cannot validate sequence of an intronic variant ({})".format(str(var))
)

That logic is correct for:

c. ✔
n. ✔

It is wrong for r..

An RNA variant can never legally have intronic coordinates.

I'd change it to something like:

if (
var.type in ("c", "n")
and var.posedit.pos is not None
and (
var.posedit.pos.start.offset != 0
or var.posedit.pos.end.offset != 0
)
):
return (
ValidationLevel.WARNING,
f"Cannot validate sequence of an intronic variant ({var})"
)

if (
var.type == "r"
and var.posedit.pos is not None
and (
var.posedit.pos.start.offset != 0
or var.posedit.pos.end.offset != 0
)
):
return (
ValidationLevel.ERROR,
f"RNA variants cannot contain intronic coordinates ({var})"
)

or even raise HGVSInvalidVariantError immediately instead of returning an error tuple.

I also think this constant should disappear completely:

BASE_OFFSET_COORD_TYPES = "cnr"

because it encodes an assumption that is no longer true.

[Peter-J-Freeman]

I think the biggest issue will be mapping between g and r. Its pretty much impossible outside of exons. FUN!!!

But if we can get

• parse
• normalize
• validate

to work, we can work on the rest. We only handle r. if we get r. in, and warn that the genomic variant may not be correct, so we keep this logic

[John-F-Wagstaff]

R positions are broken in that they can't use the coding coordinates for non-coding sequences.

As such either they should throw an error if you use them for non-coding RNA, which did not match my last read of the standard on this issue (though I might be wrong as that was a while ago) or they are different than depending on coding status. you would need to work out whether the input was coding capable before making a decision on the Datum, and preserve and use the appropriate start-point. This also means that we can't easily fix it if they get the chosen start point wrong, because if you get an error you don't know whether it was start point or sequence based issues.

[Peter-J-Freeman]

R positions are broken in that they can't use the coding coordinates for non-coding sequences.

I literally just thought that myself

I think I agree. I would do this "As such either they should throw an error if you use them for non-coding RNA"

And state that NR_:r. is not suported. i think we are way more likely to see NM_:r. anyway.

[John-F-Wagstaff]

What does the standard say?

ALL of the RNA examples user r, and appear to use coding r only, see:

https://hgvs-nomenclature.org/stable/recommendations/RNA

which does not help. There are some uses of c etc elsewhere but it almost looks like c and n are deprecated from the website.

Either way we don't want to throw an error on a valid type.

[Peter-J-Freeman]

We likely need an if clause then

something like

if NR:r. :
    def_r_pos = base:b offset:o -> vvhgvs.location.BaseOffsetPosition(b,o,datum=vvhgvs.enums.Datum.SEQ_START)

elif NM_:r. :
    def_r_pos = base:b offset:o -> vvhgvs.location.BaseOffsetPosition(b,o,datum=vvhgvs.enums.Datum.CDS_START)

As always, ENST make this harder.

In terms of normalizer, then they can be the same, as both would not allow introns.

IMHO, NR_:r. and NM_:r. are both valid. There is no reason they should not be, especially now that we know that there are clincally relevant non-coding transctipts.

Never simple is it?

If we have to choose one and not the other thouth, I think we support elif NM_:r. and simply say we cannot support NM_:r. rather than say not valid

[leicray]

My understanding is: r is used when reporting a variant detected by RNAseq or RT-PCRseq. n is used when reporting a variant detected in a non-coding RNA. c is used when reporting a variant detected at genome level and then projected onto a transcript. Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: John-F-Wagstaff ***@***.***> Sent: Thursday, 09 July 2026 20:44:49 To: openvar/variantValidator ***@***.***> Cc: Dalgleish, Raymond (Prof.) ***@***.***>; Comment ***@***.***> Subject: Re: [openvar/variantValidator] Fix vvHGVS RNA parser (Issue #856) ***CAUTION:*** This email was sent from an EXTERNAL source. Think before clicking links or opening attachments. [https://avatars.githubusercontent.com/u/60782288?s=20&v=4]John-F-Wagstaff left a comment (openvar/variantValidator#856)<#856 (comment)> What does the standard say? ALL of the RNA examples user r, and appear to use coding r only, see: https://hgvs-nomenclature.org/stable/recommendations/RNA which does not help. There are some uses of c etc elsewhere but it almost looks like c and n are deprecated from the website. Either way we don't want to throw an error on a valid type. — Reply to this email directly, view it on GitHub<#856?email_source=notifications&email_token=ACO4P2RZG4UD6U7KJA2BZCD5D7Y3DA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJSHA4TANRZHEZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4928906992>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACO4P2XIJERSKKNAU5REJLD5D7Y3DAVCNFSNUABFKJSXA33TNF2G64TZHMYTKNZSGE4TIMZZHNEXG43VMU5TIOBRHA2DQMZSGI42C5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/ACO4P2TTD4NDAAJCLMCDJVL5D7Y3DA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJSHA4TANRZHEZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/ACO4P2VG4OG44PHVVE36TDL5D7Y3DA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJSHA4TANRZHEZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>