GA4GH refget API

Minutes and Actions 2023,2024,2025,2026

These are the minutes for the refget API meetings, a subgroup of the GA4GH Large Scale Genomics Work Stream. For further information, please visit the GA4GH Work Stream page.

Let’s make the world slightly more interoperable and end the chr1 vs 1 debacle of bioinformatics!

Roadmap - 2024

1) Submitting sequence collections to PRC and steering committee approval Q2 or Q3 delivery

2) Increasing adoption of sequence collections & refget including integration into 3rd party toolkits e.g. BED, CRAM

3) Pangenomes and linking up with HPP for DP support to do this

4) Alignment with VRS 2.0 - Done

Roadmap - 2025

1) Submitting sequence collections to PRC and steering committee approval Q2 or Q3 delivery -    Done

2) Increasing adoption of sequence collections & refget including integration into 3rd party toolkits

• BED, CRAM
• Refgenie
• OmniPy (Sveinung)
• RDA Genomic Annotations
• Ensembl and ENA services

3) Pangenomes and linking up with HPP for DP support to do this.Pangenome User stories

4) Alignment with VRS 2.0 Done

Priorities for 2026

• 1. pangenomes (spec development work)
• 2. practical applications

• store/distribution (solve challenge with distribution)
• EVA validator? (improve current tool that will validate whether variant is using a reference genome we recognize)

•  3. integrations into other standards (file formats)
• 4. deployment of services (ensembl, EVA, refgenie)

Product maintainers. Responsibilities:

• Maintains LSG product(s)
• Implements and documents approved updates to products
• May maintain inward- and outward-facing web sites, repositories, etc
• Manages products through the post-development release process
• Person could be from a central GA4GH resource medium/long term
• Short-term person would have to come from our local workstream resource

Meeting Protocols

Agendas, Minutes and Action

YYYY-MM-DD: Template

2025-02-19:

2025-02-05:

2025-01-22: PSC report / Interop

2025-01-08: PSC

2024-12-11: Github issues

2024-11-20: Issue 84,86

2024-10-30: Cancelled (Due to unavailability of the leads)

2024-10-16: Retrievability

2024-10-02: Sorted Name length

2024-09-04: PR81 & NIH grant

2024-08-21: PR 81 and NIH Grant

2024-08-07: Functions proposed

2024-07-24: Refget discussion - Cancelled (Due to unavailability of the leads)

2024-07-10: Refget discussion

2024-06-26:

2024-06-12: Refget discussion

2024-05-29: Refget discussion

2024-05-15: Refget discussion

2024-04-17: Refget discussion

2024-04-03: Refget discussion

2024-03-20: Refget discussion

2024-03-06: Refget discussion- Seq col spec

2024-02-21: Refget discussion - PR55 &64

2024-02-07: Refget discussion - TASC 41

2024-01-10: Refget discussion -

2023-12-13: Refget discussion

2023-11-29: Refget discussion

2023-11-15: Refget discussion

2023-11-01: Refget discussion

2023-10-18: Refget discussion

2023-10-10: Reverse Lookup discussion - Cancelled

2023-10-04: Refget discussion

2023-09-12: Reverse Lookup discussion - CANCELLED

2023-09-06: Refget discussion

2023-08-23: Refget discussion

2023-07-26: Refget discussion

2023-07-18: Reverse Lookup discussion

2023-07-12: Refget discussion

2023-06-28: Refget discussion

2023-06-20: Reverse Lookup discussion

2023-06-14: Refget discussion

2023-05-31: Refget discussion

2023-05-23: Reverse Lookup discussion

2023-05-17: Refget discussion

2023-05-03: Refget discussion

2023-04-25: Reverse Lookup discussion

2023-04-19: Cancelled (due to Connect meeting)

2023-04-05: Connect prep and ADR

2023-03-28: Reverse Lookup discussion – CANCELLED

2023-03-22: Refget discussion

2023-03-08: Refget discussion

2023-02-28: Reverse Lookup discussion

2023-02-22:Refget discussion

2023-02-08: Refget discussion

2023-01-31: Reverse Lookup discussion

2023-01-25: Refget discussion

2023-01-11: Refget discussion

2023-01-03: Reverse Lookup discussion - CANCELLED

2023-MM-DD: Template

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards of Professional Conduct.
• Meetings may be recorded for note-taking purposes. Recordings will be deleted within three months of the meeting taking place.
• Dates should be specified in the international format yyyy-mm-dd
• 2022 Previous minutes available here
• 2021 Previous minutes available here
• 2020 Previous minutes available here
• 2019 Previous minutes available here
• 2018 Previous minutes available here   

• https://w3id.org/ga4gh/minutes/refget should point to latest minutes

Agendas, Minutes and Action

YYYY-MM-DD: Template

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: , , , , , , ,

2028-10-28:

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: , , , , , , ,

2026-10-14:

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: ,Reggan Thomas , Jouni Siren, , , , ,

Apologies : Nathan Sheffield

Meeting recording:

Meeting minutes:

2026-09-30: Template

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: , , , , , , ,

2026-09-16: Pangenome Graph Model

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: ,Jouni Siren , Reggan Thomas, , , , ,

Meeting recording: https://us02web.zoom.us/rec/share/NzldJC_HaTOAp7TanHhs9erwHC2AlHE9g_prLgbGZmwbhx_sAWyW5iFc4Z-WYeJ3.jwfvT__ELfP-SpGE

Meeting minutes:

KEY_TAKEAWAYS_OVERVIEW

• Graph Identifier Scope: Define identifiers at chromosome/sequence level due to 300,000+ nodes per graph; node-level IDs impractical.
• Canonicalization Challenges: Node order and naming affect graph identity, coordinate consistency vital; reordering risks breakage.
• Graph Isomorphism Idea: Proposed to detect structural equivalence despite node name changes; complex, needs more use case clarity.
• Use Case Focus: Fine-grained subgraph IDs unlikely; prioritize capturing subgraph provenance metadata and paths linked to node IDs.
• External Collaboration: Limited early engagement with COST EU network; potential security expert contact could add provenance dimensions.
• Meeting Ops: Kept on agenda with flexible responses to minor attendance and technical issues; next meeting in two weeks.

Notes

Pangenome Graph Model Development

The team is refining the identifier model for pangenome graphs, focusing on practical structures and challenges related to graph components and their identifiers.

• Consensus on Graph Identifier Scope and Structure centered on defining graph identifiers at the chromosome or sequence level rather than individual nodes due to scale and complexity of nodes (over 300,000 nodes per graph) making node-level digestion impractical (16:41)

• Nodes and edges are too numerous and small for meaningful independent identification, unlike sequences in collections.
• The model aims to represent graphs as arrays of chromosome-level subgraphs (“SEQ graphs”) with embedded node sequences.
• Nathan shifted from referencing external sequences to embedding node sequences within the graph structure, aligning with Yoni’s approach for accuracy and practicality.
• This approach supports meaningful subgraph relationships at the chromosome scale but accepts that finer subgraph subset identification is likely impossible.

• Challenges in Canonicalization and Identifier Consistency revolve around ordering and naming of nodes affecting graph identity and coordinate systems (41:30)

• Node identifiers (IDs) and their order impact the canonical form and thus the graph digest.
• Maintaining coordinate systems is crucial because paths and alignments rely on consistent node IDs.
• The team debated sorting nodes by integer IDs or sequences, noting the necessity for deterministic ordering despite no inherent graph node order.
• Renaming nodes or reordering can break coordinate mapping, complicating identification.

• Exploration of Graph Isomorphism as a Potential Solution for handling different node naming schemes while recognizing structural equivalence (01:02:49)

• Nathan proposed using graph isomorphism algorithms to define an ancillary digest that recognizes graphs as identical despite different node names.
• This approach would consider all permutations and produce a canonical minimal form but is computationally complex.
• The isomorphism digest would supplement primary identifiers to address naming variability.
• The group acknowledged the complexity and need for further use case definition before adopting this.

• Clarification on Use Cases and Practical Needs for graph identifiers and subgraph relationships (26:33)

• The team discussed the importance of knowing use cases to guide model complexity, expressing skepticism about utility for fine-grained subgraph identifiers.
• Use cases like isolating single chromosomes or subsets for analysis were considered, but the presence of cross-chromosome edges complicates this.
• They agreed that standards should allow capturing subgraph provenance metadata even if inherent subgraph identification is impossible.
• Paths remain important entities tied to node IDs, and their handling will be a future focus.

Collaborations and External Engagements

The team is engaging selectively with external groups to explore potential collaboration and funding opportunities related to pangenome graph standards.

• Limited Engagement with European COST Action Network focused on setting up expert networks rather than immediate funding or projects (09:07)

• Tim reported the COST action is in early stages, mainly open to EU participants, with no current grant plans.
• Tim will attend a call on Friday to gather more details and share relevant information with the team.
• The group considered forwarding this information to local pangenome researchers rather than direct involvement.

Operational Coordination and Meeting Management

The team maintained operational discipline in agenda setting, action reviews, and scheduling despite minor attendance and communication challenges.

Technical Insights on Graph Data Structures and Standards

The discussion revealed nuanced understanding of data model elements critical for pangenome graph standardization.

• Data Model Components Defined and Debated included sequences, node IDs, edges, and paths (36:27)

• The pangenome graph is conceptualized as an array of chromosome-level graphs with paths representing haplotypes or genomes.
• Paths are sequences of node IDs, requiring consistent identifiers within the graph.
• There was debate whether node IDs should be integers, strings, or omitted, balancing simplicity against coordinate needs.

• Metadata and Ancillary Attributes for Provenance are essential to link derived graphs and subgraphs (20:21)

• The team emphasized representing “derived from” relationships as non-inherent metadata rather than embedded identifiers.
• This approach allows capturing provenance and subgraph lineage without enforcing impossible strict subgraph identification.
• It aligns with practices in existing software like UNIS, preserving important relationships for downstream use.

• File Format Considerations and Interchange Requirements influence identifier design (58:05)

• GFA files typically use integer node IDs, but these can be changed, affecting mapping.
• Paths belong to graphs and cannot logically exist independently; their identifiers depend on graph node IDs.
• Understanding how paths are used in practice is important before finalizing graph identifiers.

Strategic Reflection and Next Steps

The team is balancing ambition with pragmatism, focusing on realistic models while keeping open questions on the table.

• Acknowledgment of Model Limitations and Open Questions around subgraph identification and canonicalization (18:36)

• The impossibility of fine-grained subgraph subset identifiers was accepted based on biological and computational realities.
• They plan to keep capturing important relationships via metadata rather than forcing strict standards.
• The complexity of graph isomorphism points to potential future work but is not urgent.

• Need for Clear Use Cases to Guide Complexity was repeatedly stressed (26:33)

• Without concrete user needs, developing overly complex identifier schemes may not be justified.
• The team agreed to continue evaluating models with real-world applications in mind.
• Future discussions will likely include paths and their role in the identifier ecosystem.

• Commitment to Continue Discussion and Model Refinement with a view to finalize standards incrementally (01:04:36)

• Participants agreed to think through the issues further and reconvene in two weeks.
• The meeting surfaced critical challenges and potential solutions, setting a foundation for progress.
• Emphasis was placed on decision discipline—choosing a consistent approach and sticking to it.

2026-09-02: Pangenome Structure Diagram

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: Jouni Siren, Jinny Park

Meeting recording: https://us02web.zoom.us/rec/share/dlXzxFQzWCuh_u9qCic7SgZNHrxQ86pvptAMzMxwgxmnBToxyu1amQh6y7Hnd9Vz.62KOAROWgl5Y-fe2?startTime=1788361185000

Meeting minutes:

Summary

The group discussed how to structure identifiers (digests) for pangenomes, extending the Refget Sequence Collections approach. Consensus formed around separating sequences from the graph, but the group leaned against splitting nodes and edges into separate digests, since edges are defined in terms of nodes and have no independent meaning. Paths may warrant their own digest. Tim proposed a more promising direction: grouping nodes and edges into biologically meaningful subgraphs (e.g. per chromosome) rather than by technical component. To be picked up in two weeks.

Updates

• FAWS meetings: Nathan has attended two; Refget wasn't discussed at the most recent. The earlier one raised possible connections to other GA4GH standards (e.g. DRS) and MCP work by Venkat. Everyone is welcome to join these meetings.
• TES/WES: Agreed these sit at a higher abstraction layer (launching workflows and tasks). The Refget connection belongs at the workflow definition level — Nextflow, Snakemake, Galaxy — which is where RefGenie lives. The new RefGenie is built on Refget Sequence Collections and Refget Store. Galaxy already implements TES/WES and uses RO-Crate for provenance, which could carry Refget fields.
• HPRC annual meeting (next week, St. Louis): Nathan presenting a talk and poster, plus an unconference topic on pangenome identifiability. Jouni will attend but isn't presenting. They'll report back in two weeks.
• Funding: No active US grants mentioning "pangenome" on Grants.gov; the Informatics Tools for the Pangenome U01 (2024–25) has expired. NIH situation uncertain. In the EU, a COST-style networking group for pangenomes is being set up — small funding, but could seed larger grants later. Tim to forward the link and email.

Main discussion: structuring pangenome digests

Proposed hierarchy

Nathan shared a draft diagram breaking the object down as:

• Pangenome + graph (top level)

• Sequences (haplotypes / FASTA files)
• Graph → nodes, edges, paths

The underlying idea: Refget isn't just a sequence database, it's a recipe — content → canonical form → digest → identifier. The question is whether the same recipe applies here, and where the meaningful divisions are.

Points of agreement

• Splitting sequences from the graph is the critical division. The same sequence set can produce different graphs via different algorithms or parameters, so these clearly deserve separate identifiers.
• Sub-components should be useful on their own (Tim's criterion) — i.e. likely to appear in more than one graph, so they can support statements like "this piece appears in three pangenomes."
• Extra fields on nodes or edges are non-inherent attributes, up to implementers, and shouldn't affect identifiers.

Nodes vs. edges

Sveinung initially argued for splitting them: nodes and edges have different cardinality, so attribute tables attach naturally to one or the other.

The counterargument, which Nathan raised and Sveinung ended up accepting: edges reference nodes by index, so an edge list has no meaning independent of its node list. If nodes change, identical edge digests would be misleading. Making edges truly independent would require encoding each edge as two sequence digests plus direction — not practical at scale.

Jouni confirmed that in his work, nodes and edges are technical artifacts that don't exist independently of the graph, and his implementation digests them together. Paths are not included in his identifier.

Leaning toward: combining nodes and edges into a single digest.

Paths

Nathan argued paths deserve a separate digest — nodes and edges have a life independent of paths, and paths can be added or removed while the graph stays fixed. Tim's earlier Python prototype gave each path its own digest, on the assumption that a path corresponds to a haplotype that could recur across graphs. Jouni noted that in his graphs, paths are the primary objects — nodes and edges only exist if a path uses them.

Terminology clarified

• Transient — whether the server stores the component; determined by server/spec.
• Pass-through — metadata carried through all levels, never digested, never inherent (e.g. a graph name). Nodes and edges wouldn't qualify, since they must be digested somewhere.

Compute concern

Tim raised memory issues: nodes may be spread across a file, so all must be accumulated before digesting. Nathan noted digest algorithms are streaming, so this only matters if ordering is a problem — and that problem is identical whether or not nodes and edges are digested separately. Parked for now.

Closing idea: biologically meaningful subgraphs

Tim argued the more interesting split is orthogonal to nodes-vs-edges: slice the graph into subsets of nodes plus edges that correspond to something real. Jouni described three subgraph types currently in use — personalized subgraphs (roughly half the graph or more), per-chromosome components, and small local extractions (1–10 kb). In the latter two, nodes are selected first and edges follow.

Options discussed for capturing this:

1. Define chromosome-level (or per-sample) node+edge groupings with their own identifiers in the top-level graph. Downside: this commits to a grouping before knowing what analysis will be run.
2. Define an ancillary standard of recommended non-inherent attributes (e.g. "is subset of") that record subset relationships without affecting identifiers.
3. Structure graphs so they map back to individual sequence collections in the pangenome haplotype collection — i.e. graphs organised by sequence. The existing comparison function would then work as-is, and its outputs could be reattached as non-inherent attributes.

Tim considers this direction more promising than the technical nodes/edges separation because it's potentially biologically relevant. Nathan agreed.

Actions

• Tim — forward the EU networking group email and link; write up the closing subgraph idea to resume next meeting.
• Nathan & Jouni — report back on HPRC after next week.
• All — next meeting in two weeks, picking up from the subgraph/sequence-collection idea

2026-08-19: Layers of Pangenome

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes:

2026-08-05:

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes: The meeting has been moved from 3 pm BST to 4 PM BST

2026-07-22: Pangenome Graph Identifier

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: , , , , , , ,

 Meeting recording:

Shareable link: https://us02web.zoom.us/rec/share/xC5r75SUeVuNgLW29lsbTRUj2pDWWHz5BO7XbNTOQFFMafRs2-s1tOdA13cC4Jgs.CwVjNc3yULy67L1y

meeting minutes:

KEY_TAKEAWAYS_OVERVIEW

• Pangenome Graph Coordinates: Node IDs, orientations, and offsets form graph coordinates; naming inconsistencies cause major user confusion.
• RefGet Standards: Uses cryptographic digests for precise sequence IDs, solving reproducibility issues with reference versions like GRCh38.
• Graph Relationships: Parent-child graph mappings maintain coordinate consistency; graphs linked to pangenome content via distinct identifiers.
• Graph Format Stability: Strict GFA format rules and SHA256 hashing ensure consistent graph IDs; multiple platform line endings pose risks.
• Meeting Scheduling: Meetings shifted one hour later (8am California time) to better suit global participants, trial and reassessment planned.
• Pangenome Presentation: Removed rare variants improve mapping; deterministic IDs for sequences crucial, RefGet seen as key foundation for standards.

Notes

Pangenome Graph Coordinate Systems

This section clarifies the challenges and approaches to defining coordinate systems in pangenome graphs to ensure compatibility and accuracy.

• Graph coordinate compatibility and naming issues were identified as major problems causing confusion for users aligning reads to pangenome graphs (16:42)

• Graphs use node IDs, node orientations, and sequence offsets as coordinates, similar to chromosome and position in traditional genome coordinates
• Correct naming conventions are critical to avoid error messages when using distance or minimizer indexes
• Multiple graphs distributed often lack proper names, hindering consistent referencing

• Technical artifacts and graph variations explained including maximal nodes and node length chopping for performance and encoding reasons (20:08)

• Different graphs can represent the same underlying alignments but may vary by node length or included haplotypes
• Node IDs are preserved across these graphs, enabling coordinate mappings between subgraphs and supergraphs
• Rare variants are removed in frequency filtered graphs to improve read mapping accuracy by reducing false positives from misleading rare variants

• Personalized graphs and subgraphs maintain coordinate consistency by using subgraphs that share node IDs with supergraphs (23:44)

• Personalized graphs sample haplotypes based on coverage to create linear references from graph paths
• Using a default graph as a universal coordinate reference allows combining data aligned to various filtered or personalized versions

• Graph construction and coordinate ordering optimized for performance using canonical node orders and orientations (31:00)

• Node IDs are assigned to keep adjacent nodes numerically close, improving memory locality and query efficiency
• Edges are stored with canonical orientations to reduce redundancy and optimize traversal
• Integer-based node IDs are preferred over strings for efficient sorting and indexing

RefGet Standards and Identifiers

This section outlines the use of RefGet standards for deterministic, content-derived identifiers to improve reproducibility and compatibility in genomic references.

• RefGet uses cryptographic digests to identify sequences and collections enabling precise reference identification beyond ambiguous names like “GRCh38” (51:23)

• Differences between Ensembl, UCSC, and NCBI GRCh38 versions cause incompatibility and hurt reproducibility
• Content-derived hashes allow anyone to verify exact reference versions without a central authority
• The approach is already used in CRAM, VCF, and VRS file formats for reliable sequence referencing

• Sequence collections extend this to sets of sequences with recursive canonicalization for consistent JSON-based identifiers (54:26)

• Collections include sequence names, lengths, and digests, enabling structured queries on components
• This supports compatibility checks on names, orders, and content independently
• Enables use cases like confirming coordinate system compatibility even when sequences differ

• Comparison functions provide granular compatibility info beyond Boolean answers to support diverse user needs (56:59)

• Users can assess sequence content similarity, name and order consistency, and alignment suitability
• Outputs JSON describing overlaps and differences for informed decision-making on data integration

• RefGet Store fills the missing storage layer by providing a content-addressable sequence repository using these identifiers (57:52)

• Complements identity and comparison standards by hosting the sequence bytes themselves
• Facilitates retrieval and reuse of exact reference data with verified identity

Pangenome Identifiers and Graph Relationships

This section discusses early-stage work defining identifiers for pangenomes and the relationship between sequence collections, alignments, and graphs.

• Pangenomes viewed as collections of genomes with recursive digesting to extend RefGet identifiers naturally (58:39)

• Current focus is on identifying content (the set of genomes) separately from the graph structures
• Graphs are linked to the pangenome content identifier but may have their own distinct identifiers
• This separation helps clarify which component is referenced and improves traceability

• Discussion on layering identifiers for sequences, alignments, and graphs reflects the complexity of pangenome representations (01:02:55)

• Given sequences can produce multiple plausible alignments, and each alignment can produce multiple graphs
• Suggested approach is to have deterministic identifiers for raw sequence sets first
• Graphs and alignments may be combined or separated as a secondary identifier depending on use cases

• Need for parent-child graph relationships and coordinate system compatibility to track subgraphs and derivative versions (33:04)

• Child graphs store references to parent supergraphs for coordinate translation and error messaging
• Current implementation supports bi-directional coordinate translation between graphs with different node structures
• This relationship is crucial for supporting user questions about graph compatibility and alignment validity

• Challenges around post hoc compatibility and unknown wild data highlight the limits of current approaches (44:09)

• Difficulty in recalculating compatibility of subgraphs with parents without explicit metadata
• Desire for summary representations or metadata deposits to allow mapping of unknown graphs to known references
• RefGet’s sequence collections provide a model for this, but graph metadata standards are still evolving

Graph Format and Hashing Stability

This section covers technical considerations around graph serialization formats, hashing, and stability for consistent identifiers.

• Use of GFA format with strict whitespace and line ending rules to ensure consistent graph file hashing (38:40)

• Files must use single tabs between fields and have no empty lines to maintain digest stability
• Differences in platform line endings (Mac/Linux/Windows) can cause different file digests
• Control over the entire toolchain is necessary to guarantee identical graph hashes

• Node names use integer IDs for efficiency, with fallback to string sorting (31:00)

• The canonical order and orientation of nodes and edges enables performance optimizations
• Hashes are computed from canonical GFA output serialized in a consistent manner

• Current hashing approach is based on canonical GFA output hashed with SHA256 (33:04)

• Lowercase hex representations are used as graph identifiers
• This maintains compatibility and reproducibility within controlled pipelines

• Concerns about future ecosystem fragmentation and format divergence raised (44:09)

• Real-world use may lead to multiple unofficial format variants and metadata conventions
• Need for tools to assess compatibility of arbitrary graphs from external sources without guaranteed metadata
• Desire for stable, community-agreed metadata standards to enable broader interoperability

Meeting Scheduling and Coordination

This section summarizes coordination efforts to improve meeting attendance and scheduling across time zones.

• Discussion on adjusting meeting times to accommodate global participants (06:57)

• Reagan was unavailable due to conflicts; consideration to use a doodle poll for best time
• Participants located in Finland, UK, California, and Norway require balancing early and late times

• Consensus to move meetings one hour later to 5am California time to better align with European schedules (01:08:23)

• This time balances early starts for California with manageable late evenings in Europe
• Tim will contact Reagan to update the meeting invite accordingly

• Flexibility expressed by participants with recognition of personal scheduling challenges (01:09:30)

• Some prefer even later times to avoid rush hours
• Agreement to trial the new time for a few sessions and reassess as needed

• Next meeting confirmed for Wednesday with new time and some participants noting potential absence on Monday (01:11:50)

• Coordination to ensure key presenters like Jouni can attend at the new time
• Meeting frequency and timing remain under review for optimal participation

Presentation and Feedback on Pangenome Work

This section covers Jouni’s presentation on pangenome graph challenges and the initial introduction of RefGet standards.

• Jouni presented a detailed explanation of pangenome graphs, their coordinate systems, and technical challenges (15:00)

• Highlighted issues with graph naming, node ID consistency, and coordinate translation
• Explained the rationale behind removing rare variants for better read mapping accuracy
• Described different graph types: full, frequency filtered, personalized, and their coordinate relationships

• Tim and Svenu provided feedback emphasizing the importance of separating sequence sets from alignments and graphs (01:00:03)

• A deterministic identifier for raw sequence data is critical for reproducibility
• Alignment and graph layers may be combined or treated distinctly depending on use cases
• Parent-child graph relationships and coordinate system consistency are key focus areas

• Jouni introduced draft slides explaining RefGet standards and the need for deterministic genome references (48:30)

• Illustrated how different versions of GRCh38 impact reproducibility and data integration
• Showed how RefGet uses content-derived identifiers and comparison functions to improve compatibility
• Demonstrated the recursive hashing and JSON canonicalization approach for sequence collections

• Group agreed on the strategic value of RefGet standards and the need to extend them for pangenomes(01:01:55)

• Recognized this as a foundation for future GA4GH standard approval and community adoption
• Emphasized the importance of use case-driven development to address real-world needs
• Planned follow-up discussions and further refinements to the approach and tooling

Action items

Reggan Thomas

• Organize and send out a doodle poll to find a new meeting time convenient for all participants, especially accommodating Pacific time (15:00)
• Change the recurring meeting time based on consensus to start meetings

Sveinung

• Create and submit issues for broken and outdated links in the refget service documentation and API (13:17)

Nathan

• Update the refget service web page to include relevant links (13:17)

Jouni

• Prepare and deliver presentation on Pangenomes, and share slides with participants (16:42)

All participants

• Review Jouni’s GitHub repository on Pangenomes before the next meeting (15:00)

Tim

• Confirm participation in July 27 meeting and follow up on meeting time adjustments (13:17)

2026-07-08: Pangenome Identifier

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:  https://us02web.zoom.us/rec/share/p-A92LpCbJrXELMOtyLNs6EbcPzl-WMuU2hBZhJEEKi9DkBk3lFVz0OELI4LHzow.CrP3kbhIlmzrHfkG

Meeting minutes:

The meeting focused on discussing pangenome graph identifiers and coordinating between different workstreams. Timothée introduced Jouni's pangenome graph identifier tool and explained his own approach to pangenome graph identifiers, noting similarities in their methods. Jouni described how his tool creates identifiers based on node labels and identifiers, with subgraphs being declared as subsets of supergraphs, while Timothée's approach uses node sequences and topology hashing. The group discussed potential integration opportunities between their work and explored how to maintain relationships between different graph representations. Nathan suggested combining their efforts to develop a robust GA4GH standard for pangenome identifiers. The team agreed to have Jouni present his tool in more detail at the next meeting in two weeks, and Timothée offered to help add Jouni to GA4GH meetings and adjust meeting times to be more convenient for Pacific time zones.

Action items:

1. Nathan: Prepare a 5-10 slide introduction to RefGet (sequences, sequence collections, pangenomes) for the July 27th FAWS meeting.

2. Timothee: Contact Reagan to confirm the July 27th FAWS meeting and inform him of any further needs. - Confirmed. This is now in the API schedule spreadsheet.

3. Sveinung: Create and submit issues for the broken/outdated links in the RefGet service documentation and API.

4. Nathan: Update the RefGet service webpage to link the API to the OpenAPI documentation page (/docs) instead of the base URL.

5. Nathan: Review the pull request and work related to integrating RefGet with Galaxy, as shared by Sveinung.

6. Timothee: Add Jouni to the GA4GH meeting invite and coordinate with Reagan for an introductory email.

7. Jouni: Prepare a presentation on his pangenome graph identifier work for the next meeting in two weeks.

8. Nathan: Send the sequence collections paper to Jouni for his review.

9. All: Review Jouni's GitHub repository before the next meeting.

10. Timothee: Organize a doodle poll to find a new meeting time convenient for Pacific Time, if necessary.

Pangenome Team Updates Meeting

The team held a meeting to discuss updates and introduce Jouni, a researcher focused on pangenome algorithms and software development. Participants introduced themselves, sharing their backgrounds in sequence collections and pangenome work. The group reviewed the agenda, which included updates from RefGet and discussion of a pangenome graph identifier, though the transcript ended before these topics were fully covered.

The team held a meeting to discuss updates and introduce Jouni, a researcher focused on pangenome algorithms and software development. Participants introduced themselves, sharing their backgrounds in sequence collections and pangenome work. The group reviewed the agenda, which included updates from RefGet and discussion of a pangenome graph identifier, though the transcript ended before these topics were fully covered.

RefGet Standards Presentation Planning

Nathan and Timothee discussed the upcoming Federated Analysis Workstream meeting scheduled for July 27th, where they plan to present RefGet standards to the group. They agreed to prepare a 10-slide presentation covering RefGet sequences, sequence collections, pangenomes, and areas of integration with other workstreams. Nathan committed to creating the presentation slides and sharing them with the team before the meeting.

Meeting Schedule and Updates

The team discussed potentially reducing their meeting frequency from every two weeks to once a month, with Nathan suggesting they could alternate with other meetings. They agreed to maintain current meeting schedules for now and reassess in the fall, particularly given the summer timing and their active work on pangenome projects. Timothee confirmed they would inform Reagan about the 27th meeting, and Nathan announced that their paper had been accepted for publication, with only minor administrative steps remaining. Sveinung noted some documentation links needed updating in the RevKit service.

RefGet Service Updates Discussion

Nathan discussed recent updates to the RefGet service webpage, including improvements to make it more approachable for browsing reference genomes. Sveinung identified issues with API links on the Explore page, which currently lead to blank pages or require additional input. Nathan agreed to update the links to direct users to more user-friendly documentation pages. Sveinung also shared updates from the Galaxy Conference in France, where there was significant interest in the RefGet sequence collection standard and RefGet store, leading to a joint project aimed at comparing reference genomes across different Galaxy instances.

Refget Store Integration Collaboration

Sveinung discussed a potential collaboration with Brent Matthias regarding the RevCat store and Galaxy integration, mentioning that he had added RevGet store capabilities to comparison scripts but faced challenges with the RevKit store front-end's local file system support. Nathan suggested creating an object server as a solution and offered to review Sveinung's posted PR. Sveinung also shared information about European initiatives for harmonizing reference genomes, noting a possibility for connecting with CERN's project. Nathan provided an update on his work with the Verse team, mentioning that a new Rust version of the computation backend was released and successfully integrated with Verse identifiers, with Kyle submitting a PR for pagination updates.

RefGet Store Implementation Discussion

Nathan and Timothee discussed the implementation of RefGet store, which now supports looking up sequence identifiers through the RefGet sequences protocol, replacing the previous seek repo system. Sveinung mentioned that the Galaxy team is setting up RefGet store as a basis for integrating references directly into Galaxy, with plans to share reference genomes across galaxies. Timothee introduced the pangenome graph identifier project, explaining that it aims to create identifiers based on the content of entities, similar to how sequence identifiers work. He invited Jouni to share his approach for building the pangenome graph identifier to compare their methods.

Graph Identifier Approaches Discussion

Timothee and Jouni discussed differences in their approaches to graph identifiers, particularly regarding node identifiers versus node sequences. Jouni explained that in their system, node identifiers are integers while node sequences serve as labels, and they use the same integer identifiers across file formats like VG and GFA. Nathan suggested adopting a hierarchical approach similar to RefGet sequence collections, where separate identifiers could distinguish between different graph representations while maintaining relationships between similar graphs. Timothee shared his current identifier system which includes a topology component based on nodes and edges, and expressed interest in exploring how node identifiers could be used to compare different graph representations.

Technical Graph System Integration Discussion

Jouni explained how their system creates technical graphs by starting with a basic graph and creating subgraphs for specific purposes like dropping rare variants or sampling local haplotypes. The subgraphs maintain consistent node names with the supergraph, allowing coordinate comparisons between different samples aligned to different subgraphs. Timothee and Nathan discussed how this approach could be integrated with GA4GH standards, with Nathan suggesting potential collaboration to develop a more robust pangenome identifier system.

Pangenome Archiving and Identification Challenges

The group discussed challenges around archiving and identifying pangenomes, including technical aspects of maintaining relationships between subgraphs and supergraphs. They explored analogies to sequence collections and level 2 identifiers, discussing how intermediate layers could help preserve connections without needing the raw graphs. The conversation concluded with a lighthearted note about getting Jouni to attend future meetings to continue these discussions.

Meeting Time and Presentation Planning

The team discussed changing meeting times to accommodate Jouni's location in California, agreeing to move the meeting 2-3 hours later. They planned for Jouni to give a formal presentation about his work in the next meeting in two weeks, and for the team to share their 10-slide RevGet introduction presentation. Timothee agreed to contact Reagan to add Jouni to the GA4GH invite, and Sveinung requested that the next meeting be recorded if he cannot attend.

2026-06-11: Cancelled due to the unavailability of the leads

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting minutes:

Meeting recording:

2026-05-27: Prefix updates

Chair: Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Apologies: Sveinung Gundersen

Meeting recording:

Meeting minutes:

2026-05-13: File formats Sequence collections

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: , , , , , , ,

Apologies: Reggan

Meeting recording:

Meeting minutes:

From James: During today’s discussion in the file formats meeting, sequence collections came up in the context of interoperability with SAM/BAM, CRAM, and BCF.

One of the observations was that additional implementation experience and broader community engagement would likely help progress the discussion further. In particular, there was interest in seeing some practical or exploratory implementations demonstrating how sequence collections integrate with existing file format standards, as this would provide more concrete material for future connect / plenary discussions. I have copied James to add more context as needed.

2026-04-29: Connect discussion

Chair: Nathan Sheffield / Tim Cezard / Sveinung Gundersen

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording: https://us02web.zoom.us/rec/share/ZwPNBXBNpGBr0DfVJVohm5v0mE4lxD1jWdFhhwsiO5Wd5AoOYqXzclneoa2p785d.GSE15EcCfX0okC_S

Meeting minutes:

2026-04-01: Prefix Issue

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: Sveinung Gundersen,Reggan Thomas

Apologies: Tim Cezard

Meeting recording: https://us02web.zoom.us/rec/share/ZwPNBXBNpGBr0DfVJVohm5v0mE4lxD1jWdFhhwsiO5Wd5AoOYqXzclneoa2p785d.GSE15EcCfX0okC_S

Chat:

TC - https://github.com/ga4gh/refget/issues/53#issuecomment-3055991136

NS - https://academic.oup.com/bioinformaticsadvances/article/2/1/vbac030/6576014?guestAccessKey=

NS - http://virginia.zoom.us/my/databio

Meeting minutes:

NS - do we include prefixes at all?

NS - One is, should the API understand them when given them from an external source? And the second question is, should the API include them in responses.

The comparison function provides digests.

Should those digests be prefixed?

Or the Level 1 endpoint, when you give it a top-level digest, it returns level 1 digest. Should those level 1 digests be prefixed?

AY: The important part of the identifier is the segment used for typing (i.e., the portion after the GA4GH namespace and before the dot).

Within the GA4GH namespace, prefixes (e.g., allele, sequence/SQ) are used to clearly indicate what the identifier refers to.

Prefixes matter most when identifiers (digests) leave their original context and may lose type information—e.g., when shared externally or resolved via APIs/global services.

If the context already preserves typing (e.g., within a structured object like a sequence collection), the prefix is less critical.

For globally shared and resolvable entities (like sequences/SQ), consistent prefixing is important to ensure interoperability, semantics, and cross-standard use.

NS : Within the API context, identifiers (digests) are already implicitly typed by their structure and endpoint, so prefixes are unnecessary.

Responses (e.g., JSON) rely on contextual clarity (e.g., sequences, lengths) rather than embedding type information in the digest itself.

Prefixes (e.g., SQ, SCL) are therefore out of scope for this specification and should not be enforced here.

The responsibility for disambiguating digest types should sit at a resolver level, not within the API or spec.

If a global resolver service (e.g., from GA4GH) is introduced, that would be the appropriate place to define and interpret prefixes.

In the current design, since the API uses specific endpoints with expected digest types, type management remains external to the standard.

SG: The complexity increases at Level 1, where structure and typing may be less rigid or more flexible.

While the current approach relies on context (e.g., API fields like sequences) instead of prefixes, there may be cases where this is not sufficient.

A potential compromise is to treat attributes (e.g., sequences) as a lightweight or implicit prefix, providing some level of typing without enforcing a strict global standard.

This approach allows for flexibility (“wildcard” scenarios) where full standardisation is not yet defined.

In essence, attribute-based naming can act as a soft prefix, offering clarity while avoiding the need for formally defined, global prefixes at this stage.

SG: There is a need to clearly state that prefix definition and type identification are outside the scope of this specification.

The current specification should focus on its core method and context (e.g., API-level behaviour), rather than defining global identifier semantics.

However, there is recognition that prefixing is still important and should exist somewhere in the broader ecosystem.

Ideally, prefix standards should be defined at a higher or cross-cutting level (e.g., task group, GA4GH-wide guidance, or resolver layer).

This creates a dependency: the group may need external guidance or a separate standard to define what prefixes mean and how they should be used.

Action implied: someone (e.g., another group or governing body) needs to take responsibility for defining and standardising prefixes.

There is disagreement on whether prefixing/type definition should be part of the standard.

The view expressed here is that type interpretation should be determined by the user or implementation context, not enforced by the specification.

Including such rules in the standard would mix separate concerns (e.g., identifier generation vs. how identifiers are used/interpreted).

An analogy is made to things like checksums (e.g., MD5):

• The standard defines how they are generated, not all the possible ways they might be used.

Therefore, prefix usage should not be mandated within the core specification.

A more appropriate approach would be to provide non-normative guidance or recommendations:

• how prefixes could be used when identifiers leave their original context
• Encouraging interoperability across tools, without enforcing it

Overall: keep the standard minimal and focused, while offering optional best practices alongside it.

AY: There are no strict constraints within the task/group on introducing additional namespaces or prefixes as new use cases emerge.

This means the system can evolve incrementally, adding prefixes when they are deemed useful and appropriate.

In the VRS standard, multiple prefixes exist (e.g., VA for Variant Allele), though it’s unclear whether all are actively used in practice.

Despite having a single top-level namespace, there is still internal differentiation via prefixes tied to the information model.

Overall, this reflects a flexible, extensible approach:

• Start minimal
• Introduce new prefixes/namespaces only when justified by real use cases

NS: The current specification does not define prefixes, and that is considered appropriate.

There are external standards/mechanisms that already define namespacing for checksums (e.g., prefixes like md5:), separating identifier generation from interpretation.

This reinforces the idea that prefixing and namespacing should remain external concerns, handled outside the core spec.

However, this creates a usability challenge:

• Users may expect consistency or meaning from namespaces/prefixes
• Especially when identifiers are used across systems or contexts

The tension is between:

• Keeping the spec clean and minimal, and
• Ensuring clarity and usability for users interacting with identifiers

Implication: even if external, there may need to be clear guidance or alignment so users understand how namespaces relate to identifier types.

SG : https://github.com/ga4gh/TASC/issues/16

https://github.com/ga4gh/TASC/tree/main/namespace-resolver

NS: https://github.com/ga4gh/TASC/blob/main/namespace-resolver/identifier-prefixes.yaml

SG : https://github.com/fairtracks/fga-wg/blob/add-external-standard-annotations/src/schema/genome_assembly.yaml

• The main discussion centers on whether prefixes should be included at all in the specification. Key points:

1. Scope of Prefix Inclusion:

• If prefixes are included, questions arise:

1. Should they include the GA4GH namespace?
2. Should they include a two-character type prefix?
3. Which prefixes would actually be used?

2. API Handling of Prefixes:

• Two separate considerations:

1. Input: Should the API recognize and interpret prefixed digests coming from external sources?
2. Output: Should the API return digests with prefixes in its responses?

• Examples discussed:

• Comparison function: Provides digests — should these be prefixed?
• Level 1 endpoint: Returns top-level digests — should these include prefixes?

• Overall, the discussion frames the prefix question as twofold: recognition by the API versus inclusion in API outputs, with decisions pending on scope and consistency.

NS : https://w3id.org/ga4gh/schema/vrs/2.0.1/json/Adjacency

https://w3id.org/ga4gh/README.md

2026-03-18: Pangenome

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording: https://us02web.zoom.us/rec/share/Ch5VEq1lii5gAaXTnvfcxltRHLnLQlzWU4DqVDOcolex9mBVlA379kxiDVc9nXCp.CfSyELpkJM4F2Z4e

Meeting minutes:

https://github.com/databio/gtars

https://github.com/databio/gtars/tree/master/gtars-refget

https://github.com/refgenie/refget

2026-03-04: RefgetStore & Pangenome

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes:

2026-02-18:

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes:

2026-02-04:

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes:

Refget store discussion

2026-01-21:

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Apologies : Sveinung Gundersen

Meeting recording:

Meeting minutes:

2026-01-07: Roadmap 2026

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: ,Reggan Thomas , , , , , ,

Apologies : Sveinung Gundersen

Meeting recording:

Meeting minutes:

prepare priorities for 2026

2025-12-10: Endpoints

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: Sveinung Gundersen, Jinny Park

Meeting recording:

https://us02web.zoom.us/rec/share/RGNWM0RDQBYqNaQWDgN11oJhwJT6SZCBxpSr-zKH5xNBnxyto3C8rg6kGdN2--b6.r3u7JMmaGnj_DikR?startTime=1765378788000

Chat messages:

Nathan

https://docs.bedbase.org/gtars/refget-store-format/

https://docs.bedbase.org/gtars/python/refgetstore/

Sveinung

https://genome.crg.es/annotrieve/

Meeting minutes:

Review of Previous Actions & Context

• WGS QC Standard Inquiry:

• Justin previously inquired about specifying how the reference genome is used in QC workflows. They were looking for a way to retrieve GRCh38 (base only) directly.
• Timothee clarified that Refget provides definitions but not necessarily a direct download of a FASTA file in the way Justin envisioned, though Refgenie is closer to that need.

• Ensembl Sequence Collections:

• Timothee reported no firm plans at Ensembl to implement sequence collections in the coming year.
• While the code seems done, it has not been a high enough priority to move into production.

FASTA DRS Endpoint

• Nathan reported on his work regarding serving sequences from a "collections" perspective rather than a "sequence" perspective to address server load issues.
• Nathan finished implementing a FASTA endpoint that mounts a DRS API compatible interface.This provides access URLs to get a FASTA file representing a sequence collection.
• Serves as a mechanism for getting sequence data in the context of a collection, distinct from the Refget sequences service which handles individual sequences.
• Nathan plans to switch Refgenie to use this as its source of FASTA. He also implemented FAI tracking in the metadata.

Refget Store

• Discussion moved to a more advanced data structure Nathan developed called the "Refget Store."
• Structure: A file-based structure containing a "collection-less sequence store" (keeping all sequences) and a "collection store" (mapping names to sequences).

• Allows retrieving subsequences from the context of a collection without duplicating sequences.
• Encodes sequences using alphabet-specific bit-packing for compression.
• Can be hosted on an HTTP service (e.g., S3); a local client can dynamically cache only the necessary sequences.

• Nathan views this as how the sequences standard "should have worked," utilizing whole sequence file pulls and local substringing rather than remote substringing.

Implementation & Use Cases Discussion

• The group debated the merits of the simple FASTA endpoint versus the more complex Refget Store.
• Data Duplication vs. Dynamic Construction:

• Timothee raised the issue of multiple naming conventions requiring duplicated storage if static FASTA files are used.
• The Refget Store solves this by separating sequence data from naming conventions, allowing dynamic FASTA construction without data duplication.

• Sveinung noted this would be excellent for Galaxy, allowing them to distribute the structure and use a small tool to extract exact files needed for jobs.
• Timothee noted that large organizations have inertia and existing infrastructure that makes adopting new storage methods difficult, though he sees the value in the efficiency.
• The FASTA DRS endpoint is useful for simple users.
• The Refget Store is a powerful tool for power users and enables the creation of FASTA files on the fly.
• Nathan suggests the Refget Store might supersede the need for a standalone FASTA endpoint because a client can easily generate the FASTA from the store.

Other Business

• Sveinung introduced Emilio Righi, who developed a tool for downloading GFF files.The tool calculates statistics and compares species, which aligns well with sequence collections.
• Jinny will leave a note for Reggan to add Emilio to these meetings
• Next meeting will be in January (Dec 24 meeting cancelled)

Actions

• Nathan will prepare demos of the Refget Store and deploy it on a demo instance to show how it works and analyze disk usage.

2025-11-26: Integrate Refget

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , Justin Jeyakani (PRECISE Singapore), Reggan Thomas (GA4GH), , , , ,

Excused: Sveinung

Meeting recording: https://us02web.zoom.us/rec/share/xsorLnaWLiSoQtShFq5c-FjwlR-PidwJY9OZZxdbf4a0dUdf3xM0U1rcDcbjMAB-.kp12HbGxPxNwlKrc

Chat messages:

TC - https://ui.refgenie.org/genomes

TC - https://refgenie.org/refget/notebooks/digests/

Meeting minutes:

Justin from Singapore, part of the WGS QC standard development team, discussed the integration of ref-seq API for querying genome builds instead of linking directly to specific repositories like the 1000 Genome Project. Tim Cezard explained the ref-seq API, which includes ref-seq sequences and ref-seq sequence collections, and how it can uniquely identify sequences using MD5 or GH4 digest algorithms. Justin's team currently validates MD5 sums but is considering using ref-seq collections for better standardization. They also discussed the potential use of ref-seq collections in pangenome identifiers and the need for more community engagement and user stories to refine the standards.

Discussion on Refget API Integration

• Justin inquires about using the Refget API to query genome builds instead of linking directly to specific genomic repositories.    

• Tim Cezard explains the two parts of Refget: Refget sequences and Refget sequence collections.    

• Refget sequences identify single sequences using MD5 sums, while Refget sequence collections identify groups of sequences using a two-step construction of final identifiers.

• Tim Cezard provides details on the different digest algorithms used and the features of Refget sequence collections.   

Implementation and Use Cases

• Justin asks about the practical implementation of using Refget sequence collections in their workflow.    

• Tim Cezard explains that different tools will have different implementations and that Refget sequence collections can be used to define specific genomes.    

• Justin mentions the need for specific naming conventions for targeted regions and the compatibility with Refget sequence collections.    

• Tim Cezard discusses the use of Refget sequence collections in tools like Ref Genie for managing genome assets and indexes.   

Technical Support and Next Steps

• Justin seeks technical support for integrating Refget sequence collections into their workflow.    

• Tim Cezard suggests checking with Nathan for downloading whole genome builds and mentions the use of Ref Genie for managing genome assets.  

• Justin plans to explore the feasibility of using Refget sequence collections and validate the MD5 sums.    

• Tim Cezard and Justin discuss the potential benefits of using Refgett sequence collections and the need for further exploration and validation.  

Meeting Conclusion and Future Plans

• Reggan mentions the next meeting scheduled for December 10 and the possibility of canceling the December 24 meeting.  

• Justin plans to join the next meeting and possibly communicate with Nathan for more detailed information.  

• Tim Cezard and Reggan discuss the focus on pangenome identifiers for 2026 and the need for more community involvement and user stories.  

• The meeting concludes with plans to send an email about the upcoming discussion topics and to wait for further input from Nathan.

Action Items

• Follow up with Nathan to understand how to retrieve the GRCh38 FASTA file using the ref-Genie tool.
• Explore the feasibility of using the refget sequence collection standard in the participant's workflows and pipelines.
• Provide an update on the discussion and any progress in the next meeting scheduled for December 10th.

2025-11-11: eva-seqcol & Github review

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: Nathan, , , , , , ,

Meeting recording: https://us02web.zoom.us/rec/share/N540Eect4RR-veuKM_Wt0YHy8HesencO2kIgDZjs5TDZy1L9d6ws3f3lqGz7wV77.2d6zmEPuPjfV41D7

Meeting minutes:

2025-10-15: Github review

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: Nathan, Tim (briefly), , , , , , ,

Meeting recording:

Meeting minutes:

- Meeting ended after brief discussion due to lack of attendees.

2025-10-01: Refget Pangenomes

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes: https://us02web.zoom.us/rec/share/NalagK2cJW0R2PW64gMCJ29C7yTRc2vSet9L_fn1_xih4duR4dFZDeSyvyyOmriA.Nfjg5wX8CLu76_Le

2025-09-16: Pan-genome identifiers

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes:

TC - https://github.com/samtools/hts-specs/issues/824

2025-09-03: Prefix for Sequence Collection

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes;

2025-08-20: Meeting Free Week

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes

2025-07-09: Pangenome user stories

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes:

2025-06-25: Sequence collection integration in VCF

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording: https://us02web.zoom.us/rec/share/pH_AmG1PaoGrn4aABclEEFEvaw1xgp0tN1SswKrtgZSjsA6ZBof-Ydc_FfaKOROo.NQmTbynXWTwc858H

Meeting minutes:

Action items from the file formats meeting attended by Refget team:

TC : https://github.com/samtools/hts-specs/issues/824

Meeting summary:

The meeting discussed the introduction of sequence collection in VCF headers, proposing a structured identifier format. Andy highlighted the need to resolve sequence collection identifiers using the GA4GH namespace. The team debated the inclusion of graph identifiers in Pan genome representations, with differing opinions on whether to include them at level one or level zero. They also reviewed the upcoming Connect session, noting the deadline for proposal submissions on July 3rd and the importance of cross-stream collaboration with GA4GH, and Elixir. The meeting concluded with a reminder of the next few meetings and the need for further discussions on identifiers and namespaces.

Discussion on PR for Sequence Collection in VCF Header

•  The main topic is a PR on SG spec to introduce sequence collection in VCF header.

  •  Andy is asked about the type of task for the sequence production entity and the ongoing discussion on task.  

• The need to add a summary on the issue and the developing dependency in sequence collections is discussed.

In-Person Test Meeting and TASC Management

• An in-person test meeting is scheduled for July 16th and 17th, with the main working days being the 16th and 17th.  

• The discussion includes the need to figure out the two letters for the tasc and the importance of attending the meeting.  

• The conversation shifts to the level one identifiers and the potential addition of structured identifiers in the PR.  

• The need for a different type to distinguish level one from level zero is discussed.

Resolution and Namespace for Sequence Collections

 • The conversation delves into the resolution of level one identifiers and the potential use of the C prefix.

  • The discussion includes the importance of having a resolver for the GA4GH namespace and the utility of resolvable identifiers.

  • The need for a structured format in VCF files is highlighted, with options for unstructured and structured formats.  

• The importance of having a resolver for sequence collections and the potential issues with unique identifiers is discussed.

Integration of Sequence Collections in VCF and Other Formats

• The discussion includes the integration of sequence collections in VCF and the challenges with other formats like SAM, BAM, and CRAM.

  • The need to add sequence collection identifiers to VCF first due to its flexibility is emphasized.  

• The pros and cons of sequence collection changes are briefly mentioned, with a focus on pushing for VCF integration.

  • The importance of having a resolver for sequence collections and the potential issues with unique identifiers is reiterated.

Pan Genome Identifiers and Graph Representation

  • The discussion shifts to the identifying elements of Pangenome and the importance of the source of data.

  • The potential inclusion of graph representation as an identifying element is debated.

  • The need for a standardized way to include graph identifiers in Pan genome representations is discussed.  

• The conversation includes the importance of having identifiers for the source and the graph to ensure compatibility and differentiation.

Connect Session and Proposal Submission

• The Connect session is discussed, with a deadline for submission on July 3rd.

• The platform for collecting proposals is introduced, and the advantages of seeing other work streams' proposals are highlighted.  

• The discussion includes the potential for proposing something on Pan genome and the importance of collaboration with other work streams.  

• The need for a meeting to find synergies between different work streams and the importance of active participation in the Connect session is emphasized.

Final Remarks and Next Steps

 • The meeting concludes with a reminder of the next couple of meetings due to summer holidays.  

• The importance of continuing the discussion on identifiers and namespaces in the next meeting is mentioned.  

• The meeting ends with a note on the importance of finding synergies and collaborating with other work streams.

2025-06-11: Seqcol identifiers

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording:

Meeting minutes:

Enumerated list of why it makes sense to include seqcol identifiers in SAM/BAM/CRAM/VCF headers:

• Provenance benefits of using collections instead of sequences:

• Sequences may not represent the entire genome, but only the ones relevant to the content of the file; this means the sequences alone couldn't be used to reproduce the file, but the original genome could.
• Names may be excluded from the sequences, but will be built-in for collections

• File size benefits:

• It's more compact than including sequence headers. This can be substantial for transcriptomes, not-fully-assembled genomes, or any collection with thousands of sequences.
• It reduces duplication across files. Generally, in a set of files, each will have the same sequence set. If using sequences, this information is duplicated across all files. With collections, you eliminate that duplication.

• Compatibility: It makes it easier to check if two bam files are compatible. It enables compatibility check across file types, through the refget seqcol comparison function. For example between bam and cram or bam and vcf.
• Annotation offloading: It makes annotating the sequence collection independent from the files; annotations happen at a federated provider level. (for example, seqnames, or topologies, or whatever, are no longer duplicated in every bam file)
• Conceptual alignment. It aligns better with the way we actually conceptualize data analysis; a bam file really is a downstream asset of some analysis referencing a genome -- not an independent set of sequences that can change with each file. these genomes are re-used frequently as such, not as independent collections of sequences.
• Fetch efficiency: Can be helpful for CRAM by reducing the fetch burden; fetch once for an entire collection instead of once per sequence.
• Promotes use of digested reference genome identifiers. If in use in BAM, will increase uptake in other areas, which will improve reproducibility.

• Also increases interpretability of the bam file; That thing I have in my bam header, I can paste it into the seqcol server and learn a lot about it.

2025-05-28: Update on refget implementation

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording: https://us02web.zoom.us/rec/share/wdYfGbv4IIbtr8q93ajbTJKdv29ikQNljcUf7UBnE1A5kUi6Xkz1G4o2VWQldVau.nOfK-p7glWP4H2TR

Meeting minutes:

The meeting discussed John Marshall's minor improvements to the sequences specification, which were deemed minor and did not require a version bump. Nathan Sheffield proposed merging the changes. The agenda included reviewing previous actions, pan genome user stories, and a local ref get implementation update. Nathan presented a Rust-based local sequence cache system optimized for memory and disk usage. The team debated the inclusion of sequence collection identifiers and names in pan genome identifiers, emphasizing the need for reproducibility and downstream compatibility. They also discussed scheduling a meeting with Rob to discuss file formats and the potential use of a DRS endpoint for sequence collections

Review of Minor Improvements to Specification

•    Nathan Sheffield mentions Andy wrote the spec and should review the changes. 

•    Tim Cezard recalls Andy was busy and might need more time to review. 

•    Nathan Sheffield asks Andy to confirm if the changes are fine for merging. 

•    Andy confirms he will check the changes and decide on merging. 

Meeting Agenda and Action Items

•    Nathan Sheffield outlines the meeting agenda: previous actions, pan genome, user stories, and a local ref get implementation update. 

•    Nathan Sheffield reviews action items from the last meeting, including Reagan reaching out to Rob. 

•    The group discusses scheduling a meeting with Rob and the file formats meeting on June 17th. 

Discussion on File Formats Meeting and Action Items

•    Nathan Sheffield suggests hijacking the file formats meeting to discuss ref get file formats. 

•    Reggan agrees to check with James Bondfield about hijacking the meeting. 

•    Nathan Sheffield lists other action items, including opening an issue on the ref get spec and discussing a Durst-based system for accessing reference sequences with Rob. 

•    Tim Cezard and Nathan Sheffield discuss the separation of sequence collection inclusion in file formats and the CRAM registry issue. 

Local Ref Get Implementation Update

•    Nathan Sheffield provides an update on a local ref get implementation in Rust. 

•    The implementation allows ingesting a FASTA file, loading sequences into memory, and writing to disk. 

•    Nathan Sheffield explains the benefits of the implementation, including fast local lookups and reduced memory and disk usage. 

•    The group discusses the potential use of the implementation for CRAM and other sequence lookups. 

Pan Genome User Stories and Discussion

•    Tim Cezard presents user stories for resolving a pan genome and calculating a pan genome identifier. 

•    Nathan Sheffield explains his implementation of pan genomes in the ref get package. 

•    The group discusses the inclusion of sequence collection identifiers and sequence identifiers in pan genome calculations. 

•    Nathan Sheffield emphasizes the importance of including names in the identifiers for reproducibility and downstream compatibility. 

Graph Construction and Identifier Discussion

•    The group discusses the construction of graphs for pan genomes and the impact of different naming conventions. 

•    Nathan Sheffield argues for keeping the pan genome and graph as separate entities. 

•    Tim Cezard suggests considering the graph as part of the pan genome identifier. 

•    The group agrees to continue the discussion in the next meeting, focusing on the relationship between pan genomes and graphs. 

2025-04-30: CRAM / refget discussion

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: ,James Bonfield ,Sveinung Gundersen ,Reggan Thomas , , , ,

Meeting recording:

https://us02web.zoom.us/rec/share/LeOYkMxVUWkA13fuhQ3HQLpbkXbF5aYqL0UlPRZiROUmbD6sbtQ0ZV1vpAsGO5XT.l9b8AXMhQiWsgQr5

Meeting minutes:

The meeting discussed the challenges and potential solutions for managing sequence collections and file formats, particularly CRAM. James highlighted the need for local caching to alleviate the load on EBI's reference registry. Nathan Sheffield proposed adding a DRS endpoint to sequence collections to provide gzipped FASTA files, reducing API requests. Tim Cezard emphasized the importance of sequence collection headers for data provenance. The team agreed to discuss these proposals with Rob and to update the CRAM spec to support sequence collections. They also planned to address pan-genome discussions in future meetings.

Action items:

• Reach out to Rob to discuss adding support for sequence collections in HTS-lib.
• Open an issue on the ref-get spec to discuss adding support for sequence collections in the headers
• Discuss the idea of a DRS-based system for accessing reference sequences with Rob.

Caching and Sequence Collections

James explains the caching layer at Sanger, which acts as a permanent squid proxy.

Nathan Sheffield and James discuss the efficiency of caching and the potential benefits of sequence collections.

James suggests that users should have local caches to solve the issue of the EBI reference registry.

Nathan Sheffield proposes adding a drs endpoint to sequence collections to provide gzipped FASTA files, reducing the load on the server.

Discussion on File Compression and Sequence Downloads

Tim Cezard questions how sequences are compressed in practice.

James explains that sequences are not always downloaded compressed and that local caches are common.

Nathan Sheffield suggests that the EBI ref get sequences are never served compressed, which is part of the problem.

Challenges with EBI Refget Server               

Tim Cezard and James discuss the limitations of the EBI refget server and the need for a copy in SV.

James mentions that most of the ref get bandwidth is from one American University, indicating a management problem.

Nathan Sheffield and James discuss the need for user education and proper configuration to avoid denial of service at EBI.

James suggests removing the fallback to EBI to encourage users to specify their reference paths.

Proposed Solutions and Next Steps

Nathan Sheffield presents an alternative perspective, suggesting a CDN-first approach for sequence data.

James agrees that caching is the solution but notes that users are often lazy in implementing it.

Nathan Sheffield proposes adding sequence collection information to CRAM headers to prioritize caching.

Tim Cezard and James discuss the potential benefits and challenges of implementing sequence collections in CRAM headers.

Sequence Collection and Data Provenance

Tim Cezard suggests adding sequence collection information to CRAM headers for data provenance.

James expresses support for data provenance but notes the challenges of implementing it.

Nathan Sheffield proposes embedding sequence collection information in BAM files to avoid reliance on external services.

James and Nathan Sheffield discuss the potential benefits and drawbacks of different approaches to sequence collection integration.

Digital Object Reference System (DOR) and File Access

 Nathan Sheffield proposes using DOR to provide file-based access to sequences, enabling a CDN-like approach.

   Tim Cezard and James discuss the need to define this approach in the spec and get implementation support.

    Nathan Sheffield suggests discussing this with Rob to get his input on the feasibility and benefits of the proposed approach.

 Tim Cezard and James agree on the importance of defining the approach and getting community support.

Next Steps and Action Items:

                     Nathan Sheffield summarizes the next steps, including discussing with Rob and defining the sequence collection spec.

 Tim Cezard suggests opening an issue on the HDS spec to track the discussion and ensure it doesn't get forgotten.

         James agrees to report back to Rob and discuss the proposed approach in the next release of HDS lib.

         Nathan Sheffield and Tim Cezard discuss the importance of addressing the issues with EBI ref get server and improving data provenance in CRAM files.

2025-04-16: Connect key aways and Issue 88

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: ,Sveinung Gundersen ,Reggan Thomas , , , , ,

Meeting recording: https://us02web.zoom.us/rec/play/KL71joOs63TKsJ99ZBvJWTwQnSVPndpWkUqJHYzzBHt3udJUaN1Rav5944PWP-gIQpCCI3C5iRxWrNyI.yVFV-ZVoIphTtIec?accessLevel=meeting&canPlayFromShare=true&from=share_recording_detail&continueMode=true&componentName=rec-play&originRequestUrl=https%3A%2F%2Fus02web.zoom.us%2Frec%2Fshare%2Fva-plyIvsQz8iKJBZ9S3TPS3M5E401tprRjKEb1uITUiT7LiAiiaNnV5QgVwD4Fc.nSzrPCuir50o8izP

Meeting minutes

Review of Previous Actions and Connect Takeaways

                     Nathan Sheffield reviews previous actions, including slides, paper review, and digest computations.

                     Tim Cezard mentions an issue with name length pairs resolved by Tim and Sven.

                     Nathan Sheffield and Tim Cezard discuss the paper, with Tim planning to write an implementation description and use case.

                     Nathan Sheffield emphasizes the importance of comparing discoverability and compatibility in the paper.

                     Key takeaways from Connect include the introduction of the sequence collection standard and the need for broader infrastructure support.

Discussion on Sequence Collection and Pan Genome Integration

                     Tim Cezard plans to ingest large numbers of genomes and push the resulting Docker image to Docker Hub.

                     Nathan Sheffield suggests using Docker Compose for multiple services, but Tim prefers loading data outside the Docker file.

                     Nathan Sheffield and Tim Cezard discuss the efficiency of using compressed data for sequence collections.

                     Nathan Sheffield proposes a Docker endpoint for downloading FASTA files, which Sveinung Gundersen supports as a solution for Galaxy infrastructure.

                     Andy Yates explains the challenges with ENA's current infrastructure and the need to move away from Oracle.

Ref Get Sequences and CRAM Format Challenges

                     Nathan Sheffield proposes using sequence collections for CRAM files to improve efficiency.

                     Andy Yates and Tim Cezard discuss the mutability of genomes and the need for versioning in sequence collections.

                     Nathan Sheffield suggests a Docker endpoint for downloading FASTA files to reduce the load on the ref get sequences service.

                     Andy Yates emphasizes the importance of pre-populating caches to avoid race conditions and DDoS spikes.

                     Nathan Sheffield and Andy Yates discuss the need for better communication between tool developers and service providers.

Implementation and Scaling of Sequence Collections

                     Sveinung Gundersen suggests using Omni Pi for scaling up sequence collections on Kubernetes.

                     Nathan Sheffield explains the process of creating pedantic objects from FASTA files for database insertion.

                     Andy Yates and Nathan Sheffield discuss the potential for ensemble to adopt the current implementation for ref get sequence collections.

                     Nathan Sheffield offers to help with documentation and implementation of sequence collections.

                     The team agrees to explore the use of sequence collections for CRAM files and improve discoverability through APIs.

Next Steps and Meeting Schedule

                     Nathan Sheffield raises issue 88, which involves finding collections that contain specific sequences.

                     The team discusses the potential for adding this functionality to the API or keeping it as an optional feature.

                     Reggan notes that the next meeting is scheduled for April 30, but they decide to cancel the May 14 meeting.

                     The team plans to organize a meeting with CRAM people to discuss the proposed changes and improvements.

                     The meeting concludes with a plan to continue working on the discussed topics and schedule future meetings.

2025-03-19: Schema

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”:Sveinung , , , , , , ,

Meeting recording:

https://us02web.zoom.us/rec/share/oeHKQ2ZI9NWIim-2OmvwilWAOvRigCRbBw4sKwzMXtLrjN4h0rr3--wZieqpH0Hm.OvMP-uEf7TSEu_EZ

Meeting minutes:

Summary

The team discussed the finalization of the sequence collection schema, agreeing to include attributes like sorted name-length pairs. They proposed versioning the schema semantically and hosting it in a dedicated GitHub repository. Nathan demonstrated a comparison interpretation tool, suggesting it could be extended to an API. They reviewed previous actions, including updates to the paper and a press release with a new date of March 27. The team also planned for the Connect session, with Nathan and Andy preparing slides on the approved standard and future directions. They emphasized the need for clear documentation and organization in the GitHub repository.

Discussion on Algorithm and Implementation Details

                     Tim Cezard and Nathan Sheffield discuss the simplicity of the algorithm and the use of a library instead of the RFC.

                     Nathan Sheffield admits he didn't thoroughly check his implementation, while Tim Cezard mentions they didn't verify theirs either.

                     Nathan Sheffield plans to show a new tool he's working on for comparison interpretation.

Review of Previous Actions and Paper Updates

                     Nathan Sheffield reviews the agenda, including previous actions, updates on the schema, and Connect slides preparation.

                     Tim Cezard mentions he reviewed the paper and suggests a detailed description of each implementation in the supplementary.

                     Nathan Sheffield agrees and suggests having a use cases section and an implementation section in the paper.

                     Discussion on the clarity of the use cases and implementation sections, with suggestions for concrete examples and real analyses.

Timeline and Paper Readiness

                     Nathan Sheffield inquires about the timeline for completing the paper, with Tim Cezard suggesting summer as a more realistic target.

                     Tim Cezard shares an example of a supplementary from the red cat paper to illustrate what they could include.

                     Nathan Sheffield and Tim Cezard discuss the readiness of the paper and the need for a timeline.

                     Reggan updates on the comms team's progress and the new date for the press release.

Comparison Interpretation Tool Demonstration

                     Nathan Sheffield demonstrates a comparison interpretation tool he's developing, explaining its functionality and potential uses.

                     Discussion on the complexity of interpretation and the need for different modules based on the problem being addressed.

                     Tim Cezard and Speaker 5 provide feedback on the tool, suggesting additional modules and the potential for an API.

                     Nathan Sheffield considers making the tool an API and adding different boxes for coordinate system compatibility, sequence comparison, and subset analysis.

Connect Slides Preparation and Finalizing the Schema

                     Nathan Sheffield reviews the Connect agenda and the need for slides on the approved standard and implementations.

                     Discussion on the final schema, including whether it should be included in the spec or as an example, and where the final schema should live.

                     Nathan Sheffield proposes using the schema registry for long-term storage and hosting the schema in the GitHub repo for short-term use.

                     Tim Cezard and Speaker 5 discuss the organization of the GitHub repository and the need for clear links to the specifications.

Schema Versioning and Organizational Structure

                     Nathan Sheffield explains the concept of semantic versioning for the schema and proposes setting up the schema for this approach.

                     Discussion on the need for an input schema and an output schema, with Tim Cezard suggesting a minimal schema first and adding attributes later.

                     Speaker 5 proposes splitting the schema into a vocabulary and a minimal schema, with references to the full properties file.

                     Nathan Sheffield agrees to implement the proposed changes and update the example in the spec to point to the final schema.

Final Remarks and Next Steps

                     Nathan Sheffield summarizes the action items, including creating a JSON file for the schema, updating the example in the spec, and organizing the GitHub repository.

                     Reggan confirms the completion of the slide deck by the 26th of March.

                     Nathan Sheffield reminds everyone of the Connect session and the need for slides on the roadmap and ensemble use case.

                     The meeting concludes with a reminder to complete the slides and prepare for the Connect session.

2025-03-05: Compliance test and service info

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: ,Reggan Thomas ,Sveinung Gundersen , , , , ,

Meeting recording: https://us02web.zoom.us/rec/share/nFG_7ShsQf-7tmJYA-dpmN-X2k9BWlzDbktGMVmPI19mWC1XCu2CzLIkyPR2HYY-.8mCfrgev77WjR1RT

Meeting minutes:

Nathan Sheffield:        https://refgenie.org/refget/notebooks/seqcol-client/

Nathan Sheffield:        https://refgenie.org/refget/compliance/

Nathan Sheffield:        https://github.com/refgenie/refget

Nathan Sheffield:        https://github.com/refgenie/refget/blob/master/tests/test_digests.py

Nathan Sheffield:        https://github.com/refgenie/refget/blob/master/tests/test_refget.py

Nathan Sheffield:        https://github.com/refgenie/refget/tree/master/test_fasta

        https://docs.google.com/document/d/1JF6Q3NCifbdPwJLToI0cm0oFWPZwmY4e/edit?rtpof=true&sd=true&tab=t.0

Summary:

The team discussed the agenda, focusing on previous actions, compliance testing, and the draft press release. Nathan proposed finalizing the manuscript's focus on the spec and adding use cases. Tim and Sveinung debated the manuscript's technical versus use-case content. Nathan emphasized the need for compliance tests, requesting Tim and Sveinung to compute digests for demo FASTA files. Tim mentioned the service's operational status and the need to update the spec to reflect new artifact naming conventions. The team also planned presentations for the Connect event, including a 15-minute overview by Nathan and five-minute updates on implementations.

Actions:

Compute top-level digests for all demo FASTA files and compare them to ensure consistency.

Update the ref-get package to version 2.01, deprecating the use of "ref-get" and transitioning to "ref-get-sequence".

Reach out to the Pan Genome session chairs to see if they would like a 5-minute update on the ref-get work during their session

Finalize the schema URL for the spec and discuss it at the next meeting.

Discussion on Manuscript Content and Structure

Nathan explains the current manuscript's purpose as a brief advertisement of the spec, focusing on the big picture and how the spec fits into the world.

Sveinung Gundersen and Tim Cezard discuss the need for more technical background and analysis in the manuscript.

Nathan suggests two papers: one on the spec itself and another on the analysis of common reference genomes using the tool.

The team debates whether to include use cases in the spec paper or leave them for a follow-up paper.

Implementation and Documentation of the Spec

Nathan discusses his work on the Python package for the ref get spec, including tutorials and user-friendly documentation.

Sveinung Gundersen suggests including examples and use cases in the documentation to make it more understandable and engaging.

Tim Cezard proposes adding use cases to the paper to illustrate the spec's potential applications

Nathan agrees to include use cases in the paper and suggests focusing on the spec and use cases in the initial paper.

Compliance Testing and Implementation Updates

Nathan raises concerns about the status of his implementation and the need for confidence in compliance tests.

Tim Cezard mentions the need to implement the last two endpoints of the spec and suggests restarting the server to ensure the correct digest computation.

Tim Cezard proposes adding use cases to the paper to illustrate the spec's potential applications.

Nathan proposes creating a bank of demo FASTA files with their official digests for compliance testing.

The team discusses the need for multiple implementations of the digest computation to ensure accuracy

Service Info Artifacts and Naming Conventions

Tim Cezard discusses the naming conventions for artifacts, suggesting singular naming and the use of hyphens

Nathan and Sveinung agree on the use of hyphens for URL-friendliness.

The team discusses the need to coordinate with existing services that use the old naming conventions.

Tim proposes updating the spec to reflect the new naming conventions and possibly deprecating the old names.

Connect Preparation and Presentation Details

Nathan outlines the Connect event agenda, including his 15-minute presentation on the approved standard and five-minute presentations on implementations.

Tim Cezard raises the issue of coordinating with the human pangenome consortium for their session.

Reagan suggests using the comms form or emailing the session chairs to coordinate with the pangenome group.

Nathan proposes giving a five-minute overview of the spec at the pangenome session if invited

Finalizing Schema and Specification Details

The team discusses the need to finalize the schema URL and ensure it is correctly defined in the spec

Tim Cezard suggests defining the schema as text in the spec to avoid confusion about whether the example is part of the spec.

Nathan mentions the upcoming session on the schema registry at the Connect event

The team agrees to finalize the schema and its URL in the next meeting

2025-02-19: Connect proposal

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: ,Vasu (Sanger)  ,Sveinung Gundersen  , Sasha (GA4GH) ,Reggan (GA4GH) , , ,

Meeting recording : https://us02web.zoom.us/rec/share/wXOFRwNKL7OpHnp1DTogBWPqrAt3qlJH4wr-ncwumzPORxFAS5_Z5sxg7L907uew.o11YJNX55OaZqndN

Meeting minutes:

Previous action items

1. Comms team to announce approval, get anything needed from us

•  RT - The comms team met with Tim on February 13 and gathered the required information for the press release.
• Next step: Jaclyn (Comms) will draft the press release document..

2. Update refget landing page to reference the 2 refget standards

https://www.ga4gh.org/product/refget/ 

• RT - This is part of the communications request. An overarching page will be created, with links to subsequent pages for additional products.
• Publishing Press release
• Creating product webpage
• Promoting across our channels

3. Reach out to Rob, Shakuntula, and other contributors to see if they want to coordinate institutional press releases.

• RT - I sent the email on February 7 and received a response from Alex, who suggested highlighting the alignment with VRS 2.0 and vice versa.
• Other request received are:
• - elaine.harrison@elixir-europe.org
• Ingeborg.Winge@uib.no
• Share this with GA4GH Comms team

GIF:

Open call - GIF-Project-Open-Call-advert.pptx

I’d like to share an exciting opportunity with you all—The GA4GH Implementation Forum (GIF) has opened a new call for GIF Projects!

GIF Projects are community-led initiatives aimed at advancing genomic data interoperability by implementing GA4GH products. These projects focus on practical solutions to improve data discoverability, sharing, accessibility, and integration across the genomics ecosystem.

Projects with strong potential will have the chance to present at the 2025 April Connect meeting, providing a platform to showcase their work, gain visibility, and engage with the broader community.

If you have an idea, we encourage you to propose a GIF Project! You can find more details and guidelines at https://www.ga4gh.org/open_call/propose-a-gif-project/

NS - https://ga4gh.github.io/refget/

NS - https://github.com/ga4gh/refget/pull/91 

NS - https://github.com/ga4gh/refget/issues/79

Summary:

The meeting focused on finalizing the sequence collection standard for press release, with key tasks including reviewing previous actions, updating the splash page, and preparing for the Connect session on April 2. The team discussed the inclusion of the accession attribute in the schema, deciding to leave it out for now due to inconsistencies. They also planned to decommission the HDS spec version and redirect to the new web page. Future directions include integrating with tools like BED and CRAM, and developing services for pan genomes. The team also considered promoting the standard through webinars and technical blog posts, with a draft publication needing feedback.

2025-02-05: Decommission hts-spec version and edit spec

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

meeting recording: https://us02web.zoom.us/rec/play/hx8Q-_R9YJviLXkgQK9tD6xzI46PYZ_CRtb6BJ4IOd3n3j6v0r05mrypdgTk4mjmIQk0DiJfMEwkr93C.ty8nQUv1tzQm9_bj?accessLevel=meeting&canPlayFromShare=true&from=share_recording_detail&continueMode=true&componentName=rec-play&originRequestUrl=https%3A%2F%2Fus02web.zoom.us%2Frec%2Fshare%2Fi5QYwGEqHx0Qk6iHM_iHYzvSQlJXjsvXVrjoCWXsUiUTrnYEsKki_VoKXnnfP64I.0dK3ESUY1C0vn-kY

Meeting minutes:

Summary:

The team discussed the approval of the ref get sequences standard by the steering committee and the next steps for communications, including a tentative timeline of 10-15 days for the announcement. Reagan will work with the comms team to finalize content. Andy was tasked with decommissioning the old ref get documentation and updating links. The team also planned to polish the specification and event page before the announcement. They decided to transition the meetings to focus on pan genomes starting March 19, with the final sequence collections meeting on March 5. The Connect proposal is scheduled for April 4, and the team will coordinate press releases with various institutions.

Next Steps for Communications and Confirmation

• Reggan discusses the timeline for communications, including filling up a comms form and waiting 10 to 15 days for the comms team to act.
• The need for content for the comms team is highlighted, and Reagan plans to talk to the comms team to determine the type of content needed.

• The importance of reviewing the content before the next meeting in two weeks is emphasized.

• The discussion includes the need for a final review of the specification and the event page.

Web Page and Specification Updates

• The need to update the web page and the specification is discussed, including the landing page and the use cases section.

• The current state of the web page is reviewed, and the need to finalize the transfer of information between the old and new sites is mentioned.

• Andy is assigned the task of decommissioning the old HTS spec version of the ref get sequences documentation and redirecting to the new web page.

• The discussion includes the need to update the specification to version 1.0 and make it official.

Open Issues and Task Assignments

• The current open issues on the HGS specs repo are reviewed, with a focus on those tagged with "ref get."

• Andy is assigned to review and possibly close or transfer old issues to the new repo.

•  The need for a final read-through of the specification by all participants before the comms announcement is emphasized.

• The importance of coordinating with the comms team and other institutions for joint communications is discussed.

Coordination with Other Institutions and Timelines

• The need to coordinate with other institutions like EBI, UVA, and Alex here for joint communications is highlighted.

• The importance of aligning timelines for announcements and ensuring all institutions are on the same page is discussed.

• The need to reach out to other contributors to ref get and coordinate institutional press releases is mentioned.

• The discussion includes the need to update the landing page on the GA4 GH site to reflect the new standard.

Pan Genome and Sequence Collection Meetings

• The discussion shifts to the future focus of the meetings, with a focus on pan genomes and sequence collections.

• The idea of splitting the meetings into separate pan genome and sequence collection meetings is considered.

• The need to balance the focus of the meetings to ensure both topics are addressed effectively is discussed.

• The decision is made to continue the current meeting format and transition to pan genome meetings in the next few weeks.

Connect Proposal and Upcoming Events

•  The Connect proposal is discussed, with a rough gate scheduled for April 4.

• The need to finalize the proposal and prepare for the Connect meeting is emphasized.

• The importance of having services available for the Connect meeting is discussed, with a focus on demonstrating current services and plans for future services.

• The need to coordinate with other institutions and projects for the Connect meeting is highlighted.

Engaging with Other Projects and Communities

• The need to engage with other projects like HBP, Qatar Genome Project, and non-human pan genomes is discussed.

•  The importance of ensuring the standard is applicable to a wide range of genomes and projects is emphasized.

• The discussion includes the need to reach out to potential collaborators and ensure they are aware of the standard and its development.

• The importance of aligning the standard with the needs of different communities and projects is highlighted.

Final Preparations and Action Items

• The need to finalize the web page, specification, and other materials before the comms announcement is emphasized.

• The importance of coordinating with the comms team and other institutions for joint communications is reiterated.

• The discussion includes the need to update the landing page on the GA4GH site and ensure all materials are ready for the Connect meeting.

2025-01-22: PSC report / Interop

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

meeting recording:

meeting minutes:

2025-01-08: PSC

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Meeting recording: https://us02web.zoom.us/rec/share/S7RKrbZsbNX3wXii6xnTZ1SvLv26tqt2NdB7riv0i1IHb8wh82Ne5T8vGG3cp8kQ.5bz71W-XOxdcwD0N

meeting minutes:

The meeting focused on finalizing the presentation for the January 13th review of the ref get sequence collections standard. Key points included confirming the presentation time (9:15 AM BST) and location, and ensuring the slides are ready. The team discussed the need to demonstrate interoperability and provide a timeline for updates. They highlighted potential adopters like Ensembl, ENA, and NCBI, and emphasized the importance of aligning with the VRS standard. Future directions include ref get pan genomes and collaborating with HPRC. The team also discussed the need to update the product approval submission form and ensure all links are current.

Action items:

Contact Tim to get an update on the timeline for his implementation to be up-to-date with the latest changes.

Demonstrate interoperability between Nathan's implementation and a client.

Finalize the test suite and be able to show it working on Nathan's service.

Add highlights of 2-3 key PRC comments and how the project responded to them in the presentation slides

Add the contributor list to the main ref-get documentation.

Check if the presentation time can be extended from 10-15 minutes to 15-20 minutes.

Agenda and Presentation Preparation

Nathan Sheffield outlines the agenda, focusing on confirming and finalizing slides for the January 13th presentation and completing the product approval submission form.

Andy Yates discusses the expansion of points flagged by Reagan, including potential adopters and problem statements.

Nathan Sheffield and Andy Yates debate the interoperability of implementations and the need for a test suite to demonstrate compatibility.

They discuss the challenges of demonstrating interoperability due to recent changes and the need for a timeline for achieving compatibility.

Interoperability and Compatibility Concerns

Nathan Sheffield and Andy Yates discuss the interoperability of different implementations and the need for a test suite to demonstrate compatibility.

They consider the possibility of demonstrating interoperability with a remote service and a local client.

Nathan Sheffield proposes contacting Tim to get a timeline for updating the implementation to the latest changes.

Andy Yates suggests stating a link to the test suite and providing dates of the last test runs to demonstrate compatibility.

Potential Adopters and Use Cases

Andy Yates lists potential adopters, including Ensembl, ENA, NCBI, and other NSDC repositories.

Andy Yates explains Ensembl's new infrastructure and the potential for providing sequence collections through a central metadata database.

They discuss the potential for Ensembl and other projects to provide public services for sequence collections.

They discuss the challenges of mutable genome assemblies and the need for a versioning system to handle changes.

2024-12-11: Github issues

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: , , , , , , ,

Apologies : Sveinung

Meeting recording: https://us02web.zoom.us/rec/share/bnUhwsDzsE-rGnjsbqJx_vcCqcFPYwaijq1N3Ft8ckLoLKLFDDHCueUX5bgAn8_Y.oiGoy1kM3NI3IZ0I

Meeting minutes:

• We submitted a connect session proposal for the April Connect at the Broad.

2024-11-20: Issue 84,86

Chair: Andy Yates / Nathan Sheffield / Tim Cezard

Attendees “Name (Affiliation)”: ,Sveinung Gundersen , Vasu ,Reggan Thomas , , , ,