galaxyproject / galaxyproject/brc-analytics
Pangenome: populate pangenomes.yml from workflow output and build pangenomes.json
- Dominant language
- TypeScript
- Stars
- 7
- Forks
- 11
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 16
Description
Parent epic: #1322
Populate the pangenome instance and produce an app-consumable export:
- **Populate `catalog/source/pangenomes.yml`** (the `plasmodium-vivax-v1` entry) from the **Galaxy workflow output** (#1339) — version, create date, anchor, member assemblies, and the BRC Data Store output-file links.
- **Build `catalog/output/pangenomes.json`** consumable by the app, following the existing entity build/export pattern (as for `assemblies.json` / `organisms.json`).
- **Retrievable by species taxonomy ID** — the organism page for a taxon (e.g. 5855) can fetch that species' pangenome(s).
- **Validations, like other entity types** (in `validate_catalog.py`): schema validation plus the cross-catalog check below.
## Member schema (v0)
`member_assemblies` is a **map keyed by assembly accession** — the accession is the UCSC hub `genome=` arg used for the #1337 browser links. Each member's value:
- `strain` — *optional* display name (e.g. `PvP01`). Not every member will have one.
- `is_anchor` — *optional*, defaults to `false`. Exactly **one** member must set `is_anchor: true` (the reference the alignments are anchored on); the build fails if zero or more than one member is flagged.
- `catalog_accession` — *optional*; only needed when the hub accession differs from the in-catalog accession. Defaults to the map key. Sal-I is the one v0 case: the hub carries the **GCA** (`GCA_000002415.2`) but the catalog holds the **GCF** (`GCF_000002415.2`), so its member sets `catalog_accession: GCF_000002415.2`.
### Cross-catalog validation
Every member's **catalog accession** (its `catalog_accession`, or the map key when absent) must exist in the BRC assemblies catalog — **exact accession match, no GCA↔GCF aliasing**. The Sal-I GCA→GCF exception is an explicit per-member field, not a derived/fuzzy mapping. Validation fails if any member's catalog accession isn't present.
### Example
```yaml
# catalog/source/pangenomes.yml
- id: plasmodium-vivax-v1
species_taxonomy_id: 5855
version: "2026-05"
member_assemblies:
GCA_900093555.2: # PvP01
strain: PvP01
is_anchor: true
GCA_000002415.2: # Sal-I
strain: Sal-I
catalog_accession: GCF_000002415.2 # hub uses the GCA; catalog holds the GCF
GCA_914969965.1:
strain: PvW1
GCA_949152365.1:
strain: PAM
GCA_003402215.1:
strain: PvSY56
GCA_900093545.1:
strain: PvT01
GCA_900093535.1:
strain: PvC01
GCA_040114635.1:
strain: MHC087
```
## Acceptance criteria
- `pangenomes.yml` populated for `plasmodium-vivax-v1` from the workflow output.
- `member_assemblies` keyed by accession; `strain` optional; `is_anchor` optional (default `false`) with exactly one anchor enforced.
- `catalog/output/pangenomes.json` produced, consumable by the app, retrievable by `species_taxonomy_id`.
- Cross-catalog validation: every member's catalog accession exists in the BRC catalog (exact match, no aliasing); build fails otherwise. Standard entity validations applied.
Depends on #1340 (schema) and #1339 (workflow output). Permanent hub URL to hardcode tracked in #1420; link recipe in #1337.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.