What we call the sequence graph generally corresponding to a contig (but in graph space). We ended up ther because we implement a graph with ports: edges connect to nodes through ports, the segment from one port to another port we call a block.
I generally don't like it as a user facing element, it's too far removed from the biology domain. We started testing out "graph" by itself, but that doesn't really solve the issue. Contig doesn't work either because we also support protein/RNA. IMO "Sequence" is much better for the user (but overloaded* for devs).
Block groups are addressed through 3 facets:
- Collection: top level organizational unit, very flexible, I like it but don't love that the default collection is called "default" (not a hill to die on). If we were to pick "/" or "root" we can lean into collections as directories more though (nesting being purely a UI thing, encoded in the name with '/').
- Name: ~biological identity, what's on the fasta header, ... Not unique nor unambiguous: "chromosome I" from different organisms or data sources, but I don't think that should be a dealbreaker. The fact that this is used as a primary way to automatically apply vcf files, add annotations etc. is addressed in issue 85
- Sample:
- From the perspective of observed changes and VCF files: a named set of changes relative to a reference. That reference used to be the "blockgroup with sample NULL", but that forces use of a common reference and prevents some operations where that's not the case.
- From the perspective of LIMS: a reference to a physical vial/tube/plate in the lab
- From the perspective of design of synthetic sequences:
- 'update' operations other than VCF (fasta, gfa, library, sequence, gaf) don't actually mutate their input, they produce new samples that the user defines by name. ("gen apply vcf" sounds more appropriate than "gen update vcf" IMHO)
- structural operations like derive-subgraph, derive-chunks, make-stitch also generate new samples.
- the way I think about virtual samples is that if you consider the pangenome for "chromosome I" as being derived from one reference, then "samples" are basically any subgraph you can take from the broader graph, as long as they represent at least a full traversal from beginning to end. Linear paths aren't sufficient there: you want to model uncertainty, diploids, ...
- "sequence" is used internally in the DB to store "long strings" uniquely by their content hash, so you have block < node < sequence
What we call the sequence graph generally corresponding to a contig (but in graph space). We ended up ther because we implement a graph with ports: edges connect to nodes through ports, the segment from one port to another port we call a block.
I generally don't like it as a user facing element, it's too far removed from the biology domain. We started testing out "graph" by itself, but that doesn't really solve the issue. Contig doesn't work either because we also support protein/RNA. IMO "Sequence" is much better for the user (but overloaded* for devs).
Block groups are addressed through 3 facets: