openvax / openvax/varcode

Support externally generated variant annotations

Open
#258 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
87
Forks
28
Avg merge
3h 27m
Merged PRs (30d)
27

Description

Background

Varcode currently computes all variant effects internally via predict_variant_effects(), which walks PyEnsembl transcripts and predicts coding consequences from first principles. This works well for point variants where the genomic-to-protein mapping is deterministic, but breaks down for structural variants and complex events where:

  • The effect on the protein product may not be inferrable from the genomic rearrangement alone
  • External tools (e.g., Exacto, long-read RNA assemblers) have already determined the transcript structure and translated the resulting protein
  • Annotation requires RNA-level evidence that varcode doesn't have access to

Scope

Allow varcode to accept pre-computed annotations from external tools, rather than requiring all effects to be internally predicted.

Design considerations
  1. Annotation source tracking: effects should record how they were determined — internally predicted vs. externally provided, and from which tool/pipeline.
  2. Coexistence with prediction: for the same variant, a user might want both the internally predicted effect(s) and the externally provided one(s) (e.g., to compare DNA-only predictions against RNA-observed outcomes).
  3. Structured import API: provide a way to attach an EffectCollection (or individual effects) to a variant from external data, with validation that the effect is compatible with the variant type.
  4. Confidence/evidence metadata: external annotations may come with supporting evidence (read counts, transcript models, confidence scores) that should be preservable.
  5. Sets of effects, not single annotations: a single variant (especially an SV) can produce multiple distinct protein products via alternative splicing. External annotations should be importable as a set of observed or possible effects for one variant, not forced into a single "the effect" slot. This is especially important when importing Exacto results, where one DNA variant may link to multiple transcript models, each with its own primary structure.
Relevant context
  • Exacto produces annotated variant calls with gene/transcript/exon annotations (position_1_annotation, position_2_annotation columns) and per-amino-acid primary structure tables that trace each residue back to its source variant. Critically, Exacto's integration table maps one dna_variant_call_id to potentially many transcript_model_id entries, reflecting the multiple spliced isoforms a single DNA event can produce.
  • This is a prerequisite for meaningfully importing Exacto structural variant results, since varcode cannot internally predict the effect of most SVs.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with predict_variant_effects() and the existing EffectCollection concepts, then review the Exacto fields position_1_annotation, position_2_annotation, and its transcript_model_id mappings. Done means externally supplied sets of effects can be attached to a variant, retain source and evidence metadata, coexist with predictions, and validate compatibility with the variant type.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend-api-design, bioinformatics
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.