galaxyproject / galaxyproject/brc-analytics

Pangenome: populate pangenomes.yml from workflow output and build pangenomes.json

Open
#1,341 0 comments 0 reactions 2 assignees Claimed by @hunterckx View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.