Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support transcript variants with specification of underlying genomic reference #642

Open
reece opened this issue Sep 30, 2022 · 4 comments
Labels
keep alive exempt issue from staleness checks

Comments

@reece
Copy link
Member

reece commented Sep 30, 2022

In https://groups.google.com/g/hgvs-discuss/c/7I1jP5m7bvk/m/wjUzIk0zAwAJ, Matt Ducar wrote:


I get the following printout:
NC_000017.10:g.7578369A>C

NM_000546.5:c.559+2T>G

That isn't the output I expected based on the HGVS documentation at:
https://varnomen.hgvs.org/bg-material/numbering/

Which states: "a coding DNA reference sequence does not contain intron or 5’ and 3’ gene flanking sequences and can therefore not be used as a reference to describe variants in these regions see Reference Sequences."

The expected annotation would instead be:
NC_000017.10(NM_000546.5):c.559+2T>G

Neither parsing nor generating this syntax is currently supported by hgvs. (This part of the guidelines was added long after the parser and data model were in place.)

The goal of this issue is to implement full support, i.e.:

  • parsing variants like "NC_000017.10(NM_000546.5):c.559+2T>G" so that the genomic access is stored (probably in the SequenceVariant)
  • When a genomic variant is projected to a transcript, the genomic accession is added to the resulting transcript record
  • When a transcript variant is stringified, the genomic reference is included if present
  • Consider a config option to require that intronic variants specify a genomic reference. i.e., strictly reject parsing or generating variants like "NM_000546.5:c.559+2T>G"
Copy link

github-actions bot commented Dec 8, 2023

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the stale Issue is stale and subject to automatic closing label Dec 8, 2023
Copy link

This issue was closed because it has been stalled for 7 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Dec 16, 2023
@reece reece reopened this Feb 19, 2024
@reece reece added resurrected and removed stale Issue is stale and subject to automatic closing labels Feb 19, 2024
@reece
Copy link
Member Author

reece commented Feb 19, 2024

This issue was closed by stalebot. It has been reopened to give more time for community review. See biocommons coding guidelines for stale issue and pull request policies. This resurrection is expected to be a one-time event.

Copy link

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the stale Issue is stale and subject to automatic closing label May 20, 2024
@jsstevenson jsstevenson added keep alive exempt issue from staleness checks and removed stale Issue is stale and subject to automatic closing resurrected labels May 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
keep alive exempt issue from staleness checks
Projects
None yet
Development

No branches or pull requests

2 participants