Description of feature
nf-core/sativa recently added support for deriving reference-sequence taxonomy directly from FASTA headers, as an alternative to a separate taxonomy file, following GTDB's own single-file convention (>id taxonomy;string). I think the same feature would be a good fit for phyloplace's --refseqfile/--taxonomy, which have the same two-file input shape.
Current behaviour here
--taxonomy is already optional (it.taxonomy ? file(it.taxonomy, checkIfExists: true) : []), but when it's omitted, GAPPA_ASSIGN (via fasta_newick_epang_gappa) simply has no taxonomy to assign against, so taxonomy_profile/taxonomy_per_query come out empty -- users lose the taxonomic classification of their placements entirely unless they hand-prepare a separate TSV.- Real reference databases commonly ship as a single file with taxonomy baked into the header (GTDB's own SSU/genome FASTAs, for example) -- today that means splitting it into a bare-header FASTA plus a separate TSV before it can be used with
--refseqfile/--taxonomy.
Proposal
When --taxonomy is not given, derive it from each --refseqfile record's own header instead (content after the id, space-separated), rather than just proceeding with no taxonomy at all:
>ref_seq_1 Bacteria;Proteobacteria;Gammaproteobacteria;Enterobacterales;Enterobacteriaceae;Escherichia;Escherichia coli
A few implementation notes carried over from the sativa version, since they came from real bugs found while building it there:
- If both
--taxonomy and embedded header text are present, the file should win -- with a warning logged, not a silent ignore.
- Headers should be stripped down to a bare id afterwards regardless of which source was used, since some downstream tools keep the whole header line as the sequence/leaf name rather than just the first token.
--refseqfile "any format supported by HMMER tools" (per its current schema description) means this only really applies to the FASTA case -- other formats have no room for embedded text and would keep needing a separate --taxonomy file.- phyloplace's samplesheet (
--input) supports multiple rows/runs, each with its own refseqfile/taxonomy pair, so detection would need to run per row rather than once globally.
Happy to help scope/implement this if it sounds like a good fit.
Description of feature
nf-core/sativa recently added support for deriving reference-sequence taxonomy directly from FASTA headers, as an alternative to a separate taxonomy file, following GTDB's own single-file convention (
>id taxonomy;string). I think the same feature would be a good fit for phyloplace's--refseqfile/--taxonomy, which have the same two-file input shape.Current behaviour here
--taxonomyis already optional (it.taxonomy ? file(it.taxonomy, checkIfExists: true) : []), but when it's omitted,GAPPA_ASSIGN(viafasta_newick_epang_gappa) simply has no taxonomy to assign against, sotaxonomy_profile/taxonomy_per_querycome out empty -- users lose the taxonomic classification of their placements entirely unless they hand-prepare a separate TSV.--refseqfile/--taxonomy.Proposal
When
--taxonomyis not given, derive it from each--refseqfilerecord's own header instead (content after the id, space-separated), rather than just proceeding with no taxonomy at all:A few implementation notes carried over from the sativa version, since they came from real bugs found while building it there:
--taxonomyand embedded header text are present, the file should win -- with a warning logged, not a silent ignore.--refseqfile"any format supported by HMMER tools" (per its current schema description) means this only really applies to the FASTA case -- other formats have no room for embedded text and would keep needing a separate--taxonomyfile.--input) supports multiple rows/runs, each with its ownrefseqfile/taxonomypair, so detection would need to run per row rather than once globally.Happy to help scope/implement this if it sounds like a good fit.