Obsolete MONDO:0004914 is the preferred ID and holds all 16 xrefs (incl. OMIM); its replacement MONDO:0017388 gets 3

[andrewsu]

TL;DR

MONDO:0004914 is obsolete (term_replaced_by: MONDO:0017388), yet it is the preferred
identifier of a 16-member clique that holds every legacy xref — OMIM, DOID, UMLS×3, MESH,
MEDDRA×3, NCIT, SNOMEDCT, medgen, ICD10, ICD9. Its replacement, MONDO:0017388, gets a
2-member clique with no OMIM at all.

The identity is therefore split across the obsoletion boundary, and the current term is the
starved side. This is a concrete instance of #913, and it violates #93's stated requirement
(1) — "deprecated terms are never used as the primary identifier of a clique".

Reproduces identically in Prod, Test, and the SRI RENCI instance (details below).

The two cliques

Live node norm output — click to see the JSON:

CURIE	Prod	Test
MONDO:0004914 (obsolete)	prod JSON	test JSON
MONDO:0017388 (current)	prod JSON	test JSON
OMIM:116870	prod JSON	test JSON

	MONDO:0004914 (obsolete)	MONDO:0017388 (current)
node norm preferred ID	MONDO:0004914	MONDO:0017388
clique size	16	2
members	MONDO:0004914, DOID:9892, OMIM:116870, UMLS:C0152098, UMLS:C1861783, UMLS:C4020693, MESH:D000074742, MEDDRA:10007863, MEDDRA:10009838, MEDDRA:10083407, NCIT:C197856, SNOMEDCT:9250002, medgen:349361, ICD10:I77.4, ICD9:447.4, HP:0012327	MONDO:0017388, orphanet:293208

OMIM:116870 normalizes to the obsolete term.

Environment consistency

Environment	MONDO:0004914 clique	MONDO:0017388 clique	OMIM:116870 → preferred
Prod — nodenorm.transltr.io/1.5	16 (incl. OMIM:116870)	2	MONDO:0004914
Test — nodenorm.test.transltr.io/1.5	16 (incl. OMIM:116870)	2	MONDO:0004914
SRI — nodenormalization-sri.renci.org	16 (incl. OMIM:116870)	3 (adds icd11.foundation:1666443751)	MONDO:0004914

The obsolete clique's member set is identical in all three (same sorted-member hash). The only
difference is that the SRI instance has one additional member on the current term, so the deployed
environments are marginally worse on the starved side. Not environment-specific, and not a stale
single deployment.

What MONDO says

MONDO source records — click to view:

Term	OLS browser	OLS API (JSON)
MONDO:0004914 (obsolete)	OLS page	API JSON
MONDO:0017388 (current)	OLS page	API JSON

• MONDO:0004914 → is_obsolete: true, term_replaced_by: MONDO_0017388, label
  "obsolete celiac artery stenosis from compression by median arcuate ligament of diaphragm",
  and no OMIM xref (it moved).
• MONDO:0017388 → "celiac trunk compression syndrome", current, and carries OMIM:116870.

So MONDO merged the terms and moved the xref; the clique did not follow.

Minor note: node norm reports the obsolete clique's label without MONDO's current "obsolete "
prefix. That may be a pre-obsoletion MONDO snapshot, or the preferred label may be sourced from
another clique member (DOID/UMLS) — I haven't determined which. Either way the obsolete MONDO ID
remains the clique's preferred identifier. This is distinct from #1039, which is about obsolete
labels shipping; here the problem is which IDs the clique contains.

Downstream impact — a user-visible query failure

HPO annotates OMIM:116870 with HP:0002027 (Abdominal pain) —
HPO API for OMIM:116870
(also HPO browser). The API response lists
HP:0002027 Abdominal pain, HP:0012327 Celiac artery compression, and HP:0000006. Because that annotation keys on the
OMIM ID, it lands under the obsolete MONDO term. Verified against a live Translator lookup
service (Retriever CI, POST /query, lookup-only):

Query	Result
MONDO:0004914 -has_phenotype-> *	2 edges, including Abdominal pain
MONDO:0017388 -has_phenotype-> *	0 edges
MONDO:0017388 -ANY predicate-> *	7 edges, all subclass_of from ubergraph — nothing biological/clinical
Disease -has_phenotype-> HP:0002027 (any disease)	357 results / 397 edges (mostly infores:hpo-annotations)
ChemicalEntity -treats/in_clinical_trials_for/…-> HP:0002027	619 results / 1633 edges

So the data is ingested correctly and is abundant — it is simply attached to the ID that user-facing
queries do not pin.

This surfaced as NCATSTranslator/Feedback#1358 (link — Translator-internal tracker, not public):
an MVP1 knowledge_type: inferred query for celiac trunk compression syndrome (MONDO:0017388)
returns 92 merged results in Prod but 0 in CI. In CI the ARAs return a clean zero (no errors —
the inferred-mode expansion simply matches nothing), because the phenotype edge that Prod's path
depended on is unreachable from the current MONDO term. Positive controls with the identical query
shape confirm the CI stack is healthy (MONDO:0005148 → 1036 merged, MONDO:0004975 → 1092).

Ontology-based inference does not compensate: OBI rolls descendants up to a pinned term, and does
not inherit an ancestor's annotations — and MONDO:0017388 has no annotated descendants.

Why this is worth its own issue

The general capability gap is tracked in #913 (and #93), but neither records the direction of
harm, which is what makes it high-impact rather than cosmetic:

1. The obsolete term does not merely exist — it retains the whole xref set, so OMIM/UMLS/MESH/
   SNOMED/DOID-keyed KP data lands on the retired ID.
2. It is the clique's preferred ID, contrary to Add support for deprecated/obsolete identifiers #93's requirement (1).
3. The surviving term is left with almost nothing, so queries pinned to the correct, current MONDO
   ID silently return fewer or zero results.

Any MONDO term that has been merged is exposed to the same split, so the blast radius is far larger
than this one disease.

Tangential but visible in the same clique: HP:0012327 ("Celiac artery compression") is a
PhenotypicFeature sitting inside this Disease clique. That looks like a separate defect in the
same family as #658 — flagging it here rather than filing separately, since it may share a cause.

Suggested fix

Exactly the approach already scoped in #913: harvest obsolete OBO IDs from Ubergraph as secondary
identifiers with obsolete ID → replacement ID mappings, so the obsolete ID and its xrefs are
folded into the replacement's clique and the obsolete ID is never chosen as preferred. For OBO
sources like MONDO the mapping is unambiguous (owl:deprecated + IAO:0100001 term_replaced_by), so
this case needs no heuristics.

A useful acceptance check: after the fix,
get_normalized_nodes?curie=OMIM:116870 should return preferred MONDO:0017388, and
MONDO:0017388 -has_phenotype-> * should include HP:0002027.

Related: #913 (generalized obsolete OBO support), #93 (umbrella), #1039 (obsolete labels), #241, #243.

_{Found while investigating NCATSTranslator/Feedback#1358.}

[andrewsu]

Monarch resolves the same source data to the current term — so the correct mapping is unambiguous

A useful cross-check on which assignment is right. Monarch Initiative ingests the same
OMIM-keyed HPOA annotation, and maps it to the current MONDO term — the exact inverse of node norm:

Subject	Monarch disease→phenotype associations	node norm / a Translator lookup tier
MONDO:0017388 (current)	2 — see JSON — HP:0002027 Abdominal pain, HP:0012327 Celiac artery compression, both primary_knowledge_source: infores:omim	0 has_phenotype edges
MONDO:0004914 (obsolete)	0 — see JSON	2 has_phenotype edges, incl. Abdominal pain

Same upstream source (HPO annotations for OMIM:116870),
opposite destination. Monarch follows MONDO's term_replaced_by and lands on MONDO:0017388; node
norm keys OMIM:116870 to the retired MONDO:0004914.

That matters for triage: this is not two defensible conventions differing, it is one mapping that the
rest of the ecosystem already gets right. So the acceptance check in the issue body should be
uncontroversial — OMIM:116870 should normalize to MONDO:0017388.

Observable consequence

The split is not theoretical — it changes results depending on which route data takes to a consumer:

• A path sourced from Monarch receives the edge already keyed to MONDO:0017388, never consults
  node norm for an OMIM→MONDO step, and answers queries pinned to the current term normally.
• A path that ingests the HPO annotation files directly and normalizes the OMIM ID itself lands on
  the obsolete term, so the identical query pinned to MONDO:0017388 finds nothing.

Both behaviours are live in the ecosystem right now for this disease, which is how this surfaced.

_{Counts corroborate across three independent sources: Monarch total=2, the consuming ARA's own
query log ("obtained 2 records" from api-v3.monarchinitiative.org, and 0 records from
mydisease.info), and the 2 edges present on the obsolete term in a lookup tier.}