Summary
Consider whether to expand serotype-level training rows (from IEDB) into per-member-allele training examples, instead of dropping them during curation. Today serotype-level allele designations are silently dropped, so any measurement annotated only at serotype resolution is lost.
Current behavior
Serotypes never reach the model — they're dropped in IEDB curation (downloads-generation/data_curated/curate.py), where normalize_allele_name returns UNKNOWN for serotype names and they're logged as "un-parseable alleles". Examples from the actual curation log:
Dropping un-parseable alleles: ELA-A1, HLA-A1, HLA-A11, HLA-A2, HLA-A24, HLA-A26, HLA-A3, HLA-A3/11, HLA-B27, HLA-B44, HLA-B51, HLA-B60, HLA-B7, HLA-B8, HLA-Cw1, HLA-Cw4, RT1-Bl
(HLA-A2, HLA-B7, HLA-B27, … are classic serotype designations.)
The curated training set that mhcflurry actually trains on therefore contains 0 serotypes (verified across 994,948 rows / 323 alleles).
Is it worth doing? (measured)
Probably low priority for data volume. Serotype rows are a small fraction of raw IEDB:
- In a ~5k-row IEDB subset, serotype-class-I rows were ~0.3% of rows (7 names, 16/5005).
- The large curation drops are not serotypes:
72,054 records "insufficiently-specific" is dominated by species/class bucket labels (Saha class I=33,959, H2 class I=6,970), and a separate huge bucket is multi-allele MS genotype strings (HLA-A02:01;HLA-B39:24;…) — a different deconvolution problem.
The exact upstream serotype row count needs the raw IEDB mhc_ligand_full export (not in the downloaded data dir) to measure precisely.
Modeling caveat (the real reason this is hard, not just plumbing)
A serotype label is weak/ambiguous: a peptide measured against serotype A2 could be presented by any of ~47 member A*02 alleles. Expanding one serotype row into N per-allele rows duplicates the (peptide, label) across members, injecting label noise — it's weakly-labeled data, not a clean expansion. Needs a policy decision:
- Duplicate label across all members? Weight down? Restrict to serotypes with few members?
- Dedup against existing per-allele measurements for the same (peptide).
Proposed scope
Investigation/decision first, then (if pursued) a transform in the curation pipeline (curate.py) using mhcgnomes.parse(name, only_class1=True).alleles to expand, with an explicit member cap and a label-duplication/weighting policy. This shares the expand_serotype utility with the prediction-side serotype issue.
Effort
Medium if done well (the label-duplication policy and dedup are the substance; the mechanical expansion is easy). Recommend deferring until the prediction-side serotype expander lands and the raw-IEDB serotype volume is confirmed to justify it.
Related
- Sibling: serotype expansion for prediction (the higher-value, lower-effort half — shares the
expand_serotype utility).
- Sibling: missing pseudosequences for specific non-human alleles (a separate, concrete data-recovery lever).
Summary
Consider whether to expand serotype-level training rows (from IEDB) into per-member-allele training examples, instead of dropping them during curation. Today serotype-level allele designations are silently dropped, so any measurement annotated only at serotype resolution is lost.
Current behavior
Serotypes never reach the model — they're dropped in IEDB curation (
downloads-generation/data_curated/curate.py), wherenormalize_allele_namereturns UNKNOWN for serotype names and they're logged as "un-parseable alleles". Examples from the actual curation log:(
HLA-A2,HLA-B7,HLA-B27, … are classic serotype designations.)The curated training set that mhcflurry actually trains on therefore contains 0 serotypes (verified across 994,948 rows / 323 alleles).
Is it worth doing? (measured)
Probably low priority for data volume. Serotype rows are a small fraction of raw IEDB:
72,054 records "insufficiently-specific"is dominated by species/class bucket labels (Saha class I=33,959,H2 class I=6,970), and a separate huge bucket is multi-allele MS genotype strings (HLA-A02:01;HLA-B39:24;…) — a different deconvolution problem.The exact upstream serotype row count needs the raw IEDB
mhc_ligand_fullexport (not in the downloaded data dir) to measure precisely.Modeling caveat (the real reason this is hard, not just plumbing)
A serotype label is weak/ambiguous: a peptide measured against serotype
A2could be presented by any of ~47 memberA*02alleles. Expanding one serotype row into N per-allele rows duplicates the (peptide, label) across members, injecting label noise — it's weakly-labeled data, not a clean expansion. Needs a policy decision:Proposed scope
Investigation/decision first, then (if pursued) a transform in the curation pipeline (
curate.py) usingmhcgnomes.parse(name, only_class1=True).allelesto expand, with an explicit member cap and a label-duplication/weighting policy. This shares theexpand_serotypeutility with the prediction-side serotype issue.Effort
Medium if done well (the label-duplication policy and dedup are the substance; the mechanical expansion is easy). Recommend deferring until the prediction-side serotype expander lands and the raw-IEDB serotype volume is confirmed to justify it.
Related
expand_serotypeutility).