Skip to content

Proposed metrics changes to support discontiguous long reads technologies - #152

Open
d-cameron wants to merge 89 commits into
ga4gh:mainfrom
d-cameron:feature/develop-definition-v2
Open

d-cameron wants to merge 89 commits into
ga4gh:mainfrom
d-cameron:feature/develop-definition-v2

Conversation

@d-cameron

Copy link
Copy Markdown

The proposed changes leave the following still unresolved:

  • yield_bp_q30 and yield_bp_read_q10_q20_q30 redundantly define the BQ30 yield
    • Proposed resolution: refactor yield_bp_read_q10_q20_q30 into yield_bp_q10 and yield_bp_q20
  • read_length_percentiles_p25_p50_p75 and median_read_length both define the median read length
  • Proposed resolutions: Either
    • Define: median_read_length, read_length_p25, read_length_p75
    • Define: read_length_percentiles_p25, read_length_percentiles_p50, read_length_percentiles_p75
  • small_indel_count is very similar to count_deletions and count_insertions.
    • Proposed resolution: no change - keep all three.

justinjj24 and others added 30 commits February 24, 2026 10:03
…rinciples

Discontiguous long read principles (docs/discontiguous-long-reads.md) merged to `feature/develop-definition-v2` to further consolidate into a single vendor-neutral baseline that harmonizes the common definitions.
Add draft long-read QC metric definitions replicate of PR 132
justinjj24 and others added 26 commits September 15, 2026 14:54
@justinjj24

Copy link
Copy Markdown
Collaborator

yield_bp_q30 vs. yield_bp_read_q10_q20_q30:
These are distinct metrics, not redundant. yield_bp_q30 measures per-base quality BQ 30 or greater, whereas yield_bp_read_q10_q20_q30 measures cumulative yield from reads meeting a read-level mean quality threshold (e.g., ONT qs tag / PacBio rq tag). Not refactor this into base-level metrics?

Median read length vs. P50:
Agreed they are identical. Happy to adopt the proposed split (median_read_length, read_length_p25, read_length_p75) or standardize under read_length_percentiles_*.

Indels count:
Agree that small_indel_count is not part of the proposed metrics, so we can drop it and retain count_insertions and count_deletions.

@balaONT

balaONT commented Sep 22, 2026

Copy link
Copy Markdown

yield_bp_q30 vs. yield_bp_read_q10_q20_q30

I agree with Justin that these are distinct metrics.

yield_bp_q30

This metric represents the cumulative number of bases with a base quality score ≥ Q30. It is typically used for short-read sequencing, where base-level quality filtering is an established and commonly used practice.

yield_bp_read_q10_q20_q30

This metric is calculated at the read level. It represents the cumulative number of bases from all reads whose mean read Q score meets a specified threshold (e.g., Q10, Q20 or Q30).

Importantly:

The Q score threshold is applied to the mean quality score of each read, rather than to individual bases.
Once a read meets the threshold, all bases from that read are included in the yield calculation.
Therefore, a read that passes the threshold can still contain individual bases with Q scores below that threshold.
Read-level Q-score filtering is an established and commonly used approach for contiguous long-read sequencing, and therefore represents a distinct QC metric from base-level Q30 yield.

In this sense, yield_bp_read_q10_q20_q30 serves a similar QC purpose to yield_bp_q30, but the quality threshold is applied at the read level rather than the base level.

So, I would retain both metrics: they describe high-quality yield using two different quality-filtering approaches that reflect established practices for their respective sequencing technologies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants