DOID xrefs that conflate a syndrome with its lesion fuse cliques, and overuse filtering cannot catch them

[gaurav]

remove_overused_xrefs catches an xref target claimed by two or more subjects, which is the shape an ICD family code has and what #1032 is about widening it to cover. It cannot catch the other shape: a single DOID term asserting an xref to an identifier that belongs to a different disease. Claimed once, that looks exactly like a correct 1:1 mapping, and no counting rule tells them apart — so this is a separate workstream from #1032, not a subset of it.

Found while tracing the clique restructuring in #980. Every one of the 29 edges that hold two distinct diseases together in the disease build's over-merged cliques is asserted by the DOID concord — none by MONDO, UMLS, HP, EFO or Manual — and they split by shape:

shape	over-merges	catchable by overuse filtering?
an overused target (2+ DOID subjects)	4	yes — #1032
a single cross-disease xref	7	no

Full per-edge record: docs/sources/DOID/cross-disease-xrefs.csv, regenerated by uv run python docs/sources/DOID/scripts/find_cross_disease_xrefs.py docs/sources/GARD/on-addition/clique-diff-regrouped.csv.

The clearest cases

A syndrome asserted equal to the lesion it produces, or to a neighbouring condition:

DOID term	xrefs	which is
DOID:3852 "Peutz-Jeghers syndrome"	NCIT:C4733 "Peutz-Jeghers Polyp", UMLS:C0456487	the syndrome equated with its polyp
DOID:4624 "Ollier disease"	NCIT:C3213, UMLS:C0024454 "Maffucci Syndrome"	two distinct conditions
DOID:10041 "dysplastic nevus syndrome"	MESH:D004416	pulls FAMMM syndrome into cutaneous melanoma
DOID:0050787 "juvenile polyposis syndrome"	MESH:C537702, OMIM:174900	pulls JPS into chromosome 10q23 deletion syndrome

Read the CSV as "edges that cross a split", not "edges that are wrong"

Worth stating before anyone works from it, because it is the easy mistake to make with this data. The script reports every concord row connecting the two halves of an over-merged clique. Sometimes the crossing row is itself the error, as above. Sometimes it is correct, and something else put the clique together wrongly.

DOID:8712 "neurofibromatosis" → MESH:D017253 "Neurofibromatoses" is the case in point: that xref is right. The bug is that MESH:D017253 is in the neurofibroma clique at all. Deleting the crossing edge there would be wrong; what is needed is to find why the MeSH term is misplaced. So each row needs a judgement about which endpoint is in the wrong clique, and the CSV is the worklist rather than the answer.

What to decide

1. Per row: upstream or local? A syndrome/lesion conflation is a defect in DOID and belongs in a DiseaseOntology issue — the same route as DiseaseOntology#1620, the GARD:0418 typo this repo already reported. A input_data/ bad-xrefs entry fixes Babel's output now but drifts if DOID corrects it later, so the two are complementary rather than alternatives: report upstream, and add the bad-xref entry with a link to the upstream issue so it can be removed when fixed (the pattern Remove the DOID GARD:0418 bad-xref entry once DiseaseOntology#1620 is fixed upstream #1047 already uses).

2. Whether these are worth suppressing at all. Each of these over-merges currently ships. Add the NCATS GARD rare-disease registry, joined to existing cliques by MONDO's and DOID's mappings and by label match #980 happens to break several of them apart — but only incidentally, by giving both sides a MONDO identifier so DISEASE_UNIQUE_PREFIXES refuses the union, and the splits it produces are partial (after the neurofibroma split, MeSH, NCIT and UMLS "Neurofibromatoses" all stay in the neurofibroma clique). The underlying xrefs are untouched and would re-fuse if MONDO stopped mapping the two diseases to different GARD terms, so this is not fixed by Add the NCATS GARD rare-disease registry, joined to existing cliques by MONDO's and DOID's mappings and by label match #980 in any durable sense.

3. Whether the detector is worth keeping. The script needs a list of clique pairs to examine, which it currently takes from a babel-clique-diff CSV. A version that finds over-merged cliques on its own — a clique whose members' labels or ids disagree strongly, or one holding two MONDO terms' worth of concepts — would turn this from a one-off into something runnable per release. That is more work than this issue needs, and worth splitting out if the per-row triage proves valuable.

Related: #1032 (overused targets, the other shape), #1041 (unique_prefixes refuses merges silently, which is why these present as they do), #1047 (the report-upstream-and-link pattern), and #980 where the trace lives, in docs/sources/GARD/clique-diff.md.