ARG gene symbols are not standardized across tools in hAMRonization summary, making cross-tool comparison difficult

[OriolGEM]

Hi funcscan team,

I am using the ARG workflow in nf-core/funcscan and noticed that the hAMRonization summary keeps tool/database-specific gene_symbol values, which makes it difficult to compare the same ARG across tools.

For example, the same gene may appear as:

erm(X) in AMRFinderPlus / ABRicate
ERMX in DeepARG
ErmX in RGI

Because of this, simple downstream comparisons by gene_symbol treat these as different entries even when they likely refer to the same ARG.

I know that funcscan already uses argNorm to normalize outputs from some tools to ARO terms, but in the current summary this still leaves a practical problem for users who want a directly comparable gene-level field across tools.

Why this matters
For metagenomic or multi-tool benchmarking analyses, users often want to:

compare concordance between tools
collapse redundant calls
summarize ARG abundance at the gene level

This is hard to do robustly when the summary output contains only the raw tool-specific naming conventions.

Current workaround
As a temporary workaround, I created a cleaned field in R:

hamronization_cleaned <- hamronization %>%
dplyr::mutate(
gene_symbol_clean = gene_symbol %>%
stringr::str_to_lower() %>%
stringr::str_replace_all("[^a-z0-9]", "")
)

This helps for simple cases, but it is only a heuristic and may not be the best long-term solution.

Suggested improvement
Would it be possible to add a standardized identifier/label in the ARG summary, for example:

gene_symbol_standardized
and/or an ontology-backed field such as ARO / ARO_name

while still preserving the original raw gene_symbol?

It would also be helpful to document clearly:

which tools are normalized
which tools are not
whether standardized values come from argNorm / ARO mapping or another approach

If this is considered upstream behavior from hAMRonization or argNorm, I would also be happy to open/cross-link an upstream issue.

Thanks!

[jfy133]

Thanks @OriolGEM !

These are very good points that would be great to have these inconsistencies addressed, but as you state at the end, ultimately we do consider this as

upstream behavior from hAMRonization or argNorm,

So we would be very pleased if you could do:

I would also be happy to open/cross-link an upstream issue.

As we prefer not to host too much custom code within the pipeline, as this adds additional maintenance burden to us and we would rather just use something that is well-maintained and battle tested (something not in scope of developing the pipeline itself).

and/or an ontology-backed field such as ARO / ARO_name

This would be interesting to know ifhey exist though, I suspect if this exisited, this would be extremely interesting to have native support within e.g. hARMonisaer

[jfy133]

I will close this issue as a more upstream issue for now, but if there is progess we can reopen it to implement the updated tools

[OriolGEM]

Hi @jfy133,

Thanks again for the clarification — that makes perfect sense.

I’ve now opened an upstream issue in argNorm to explore exposing a standardized gene-level field (e.g. ARO-backed identifier) for hAMRonized outputs:
BigDataBiology/argNorm#109

Depending on their feedback, I may also follow up with hAMRonization.

I’ll keep this thread updated if there’s progress upstream so it can potentially be integrated back into funcscan in the future.

Thanks again!

[jfy133]

Hi @jfy133,

Thanks again for the clarification — that makes perfect sense.

I’ve now opened an upstream issue in argNorm to explore exposing a standardized gene-level field (e.g. ARO-backed identifier) for hAMRonized outputs:
BigDataBiology/argNorm#109

Depending on their feedback, I may also follow up with hAMRonization.

I’ll keep this thread updated if there’s progress upstream so it can potentially be integrated back into funcscan in the future.

Thanks again!

Ok great!

I think actually the hAMRonization project would be the better place to request such functionality, as argNorm is an optional post processing step (at least from the pipelines' point of view), so might be worth requesting in both anyway. But let's see what they say.