Companion to NCATSTranslator/Babel#1077 and NCATSTranslator/NodeNormalization#412, which ask the same of those two repositories.
babel-explorer is a debugging tool for Babel cliques. It does not use NameRes today, but two open PRs add NameRes-backed frontends — a lookup tool (#23) and an autocomplete playground (#24) — so it is about to. Writing the agent documentation for that repository turned up questions about NameRes that the README does not answer.
This is a smaller ask than the other two: mostly about provenance, so a consumer can tell which Babel release a given answer reflects.
What we could not find
1. How NameRes relates to Babel and NodeNorm. The README says results are normalized through Node Normalization and "conflated using both GeneProtein and DrugChemical conflation", linking to Babel's conflation documentation — but not whether the NameRes index is built from Babel output, built from NodeNorm, or built independently and normalized afterwards. That difference determines whether a NameRes answer can be stale relative to a NodeNorm answer, which is exactly what a tool showing both side by side needs to know.
2. Whether there is a version or status endpoint. NodeNorm exposes babel_version via /status, and babel-explorer uses it to refuse to mix a NodeNorm built from one Babel release with Parquet files from another. If NameRes has an equivalent, it is not documented; if it does not have one, that is worth knowing too, because a UI showing NameRes and NodeNorm results together has no way to warn that they disagree about the world.
3. Whether conflation is fixed or per-query. The README states results are conflated both ways. Is that a property of the index, or a request parameter a caller can vary? A lookup tool would want to expose the choice if there is one.
Documents in babel-explorer worth reading
Answering point 1 alone would be enough to make the other two easy to reason about.
Companion to NCATSTranslator/Babel#1077 and NCATSTranslator/NodeNormalization#412, which ask the same of those two repositories.
babel-explorer is a debugging tool for Babel cliques. It does not use NameRes today, but two open PRs add NameRes-backed frontends — a lookup tool (#23) and an autocomplete playground (#24) — so it is about to. Writing the agent documentation for that repository turned up questions about NameRes that the README does not answer.
This is a smaller ask than the other two: mostly about provenance, so a consumer can tell which Babel release a given answer reflects.
What we could not find
1. How NameRes relates to Babel and NodeNorm. The README says results are normalized through Node Normalization and "conflated using both GeneProtein and DrugChemical conflation", linking to Babel's conflation documentation — but not whether the NameRes index is built from Babel output, built from NodeNorm, or built independently and normalized afterwards. That difference determines whether a NameRes answer can be stale relative to a NodeNorm answer, which is exactly what a tool showing both side by side needs to know.
2. Whether there is a version or status endpoint. NodeNorm exposes
babel_versionvia/status, and babel-explorer uses it to refuse to mix a NodeNorm built from one Babel release with Parquet files from another. If NameRes has an equivalent, it is not documented; if it does not have one, that is worth knowing too, because a UI showing NameRes and NodeNorm results together has no way to warn that they disagree about the world.3. Whether conflation is fixed or per-query. The README states results are conflated both ways. Is that a property of the index, or a request parameter a caller can vary? A lookup tool would want to expose the choice if there is one.
Documents in babel-explorer worth reading
AGENTS.md→ "Domain context" (in PR #31) — how we currently describe the three services to a coding agent, with what we could not verify marked as such. NameRes gets one line there, precisely because we could not establish the relationship in point 1.core/nodenorm.pyandcli.py→check_babel_versions()— the version-skew check we would want an equivalent of for NameRes, if the concept applies.Answering point 1 alone would be enough to make the other two easy to reason about.