yes this is a good point, everything should be framed relative to existing tools and techniques

Thanks for the question. I did try to find any tool out there doing metadata curation before building this one. I knew about nf-core/fetchngs but didn't know about the others, so just did quick research and looked again to make sure I answer it right (just correct me if I am mistaken). So fetchngs, pysradb, and ffq pull metadata and raw data that's already recorded in SRA/ENA/GEO's own structured database, and fetchngs in particular is built to feed straight into other nf-core pipelines. None of them go beyond the database record itself by looking for the published papers associated with the samples (or papers cited by the samples) to cross-check whether the metadata is correct. Sometimes authors mistype their metadata or only submit minimal metadata to the database, while the richer and more accurate metadata is in the publication, supplementary materials, etc. So, if I were a user, I would use the tools you recommended to get the list of accessions, and if I wanted richer, recovered, or cross-checked metadata (or simply cared about metadata quality), I would then input those accessions into my tool and get the Excel output. Of course, the tool is still early and buggy, so I'm actively developing it and really need feedback to improve it (and contributors to the GitHub are always welcome too!).

That is really helpful feedback! Thanks and I’ll definitely fix the docs and try the example case you just suggested. I’ll circle back to this comment (or add a new one) once it's updated.

I just updated the documents especially the README.md to make it easier to understand and try the tool. Let me know if you have any questions or problems. Thanks!

Thanks for the questions. Yeah, it's more layered than I made it sound (I'll definitely update the docs so it's easier to understand and can answer questions like these).

For tracing accession back, it first checks NCBI's own record for a structured publication link (not a search). If that's empty, it falls back to a Europe PMC search for the literal accession string, then a raw NCBI cross-reference lookup.

Separately, there's also an always-on search step that runs regardless of whether the above already found something. It searches Google (via the Serper API) the accession first, then PubMed, then Europe PMC again, and finally a direct URL if the user provides a specific link to search. Bare BioSample accessions with no parent BioProject skip the structured database check entirely and use this search process only.

So the real gap is that every fallback, in both places, searches for the literal accession string as text. A paper that never restated the accession in its own body (which was common before journals required it) won't be found by any of them. Yeah, that's still not solved yet.

I'm thinking about pulling in cross-references from other linked databases and relying more on citing-paper searches instead of just the original deposit paper. I'll open an issue on GitHub for this (or if anyone wants to contribute, feel free to open an issue or submit a PR!).

The problem with the tool output is that it is very long and harder to read than before. The output is also full of needless information and the word NCBI is there so many times it interferes with understanding.

Moreover, the output is neither humanly readable text nor real computational data.

It is not clear who the audience is. A human or a machine?

•  organism: Organism name is Listeria monocytogenes.
• collection_date: NCBI BioSample attribute collection_date is '2012-12'.
• geo_loc_name: NCBI BioSample attribute geo_loc_name is 'USA:NY'.
• host: NCBI BioSample attribute host is 'Homo sapiens'.
• project_name: NCBI BioSample attribute project_name is 'GenomeTrakr; LFFM-FY5'.
• sequenced_by: NCBI BioSample attribute sequenced_by is 'New York State Department of Health'.
• purpose_of_sampling: NCBI BioSample attribute purpose_of_sampling is 'baseline surveillance/monitoring'.
• library_strategy: NCBI experiment attribute library_strategy is 'WGS'.
• library_source: NCBI experiment attribute library_source is 'GENOMIC'.
• library_selection: NCBI experiment attribute library_selection is 'other'.
• instrument_model: NCBI experiment attribute instrument_model is 'PromethION'.
• collected_by: NCBI BioSample attribute collected_by is 'New York State Department of Health'.
...

Instead of this free-flowing semi-structured format,

I can format that output also with AI for a well defined audience, either a human or directly into JSON;

This sample is a Listeria monocytogenes strain (PNUSAL010798) collected from a human host in New York, USA, in December 2012 as part of baseline surveillance and monitoring. The sample was collected and sequenced by the New York State Department of Health under the GenomeTrakr/LFFM-FY5 project. Whole-genome sequencing (WGS) was performed using a PromethION instrument with genomic DNA. DNA was extracted using the Qiagen DNeasy 96 PowerSoil Pro QIAcube HT Kit. The sample is registered under NCBI BioSample accession SAMN20283122, SRA accession SRS9522164, and BioProject accession PRJNA514286.

In parallel to that here is the same data as JSON

{
  "organism": "Listeria monocytogenes",
  "strain": "PNUSAL010798",
  "collection_date": "2012-12",
  "geo_loc_name": "USA:NY",
  "host": "Homo sapiens",
  "ifsac_category": "clinical/research| human",
  "purpose_of_sampling": "baseline surveillance/monitoring",
  "collected_by": "New York State Department of Health",
  "project_name": "GenomeTrakr; LFFM-FY5",
  "sequenced_by": "New York State Department of Health",
  "library_strategy": "WGS",
  "library_source": "GENOMIC",
  "library_selection": "other",
  "instrument_model": "PromethION",
  "dna_extraction_kit": "Qiagen DNeasy 96 PowerSoil Pro QIAcube HT Kit",
  "biosample_accession": "SAMN20283122",
  "sra_accession": "SRS9522164",
  "bioproject_accession": "PRJNA514286"
}