Stop merging deprecated terms into the released OWL; keep the archive repo-side only

[turbomam]

METPO should keep its record of obsolete terms in the repo but stop shipping it in the released OWL, so obsolete terms no longer appear in OLS and other downstream browsers.

This reverses the decision in #378 Decide whether deprecated entities should be in the released OWL, closed 2026-06-08, which resolved to include them.

Current state. src/templates/deprecated.tsv holds 1217 data rows and is the declared source of truth for burned IDs. INCLUDE_OBSOLETE (default true) merges it into the build. The current build emits 1216 owl:deprecated classes; OLS4 reports 1455 terms for version 2026-06-12, so most of what OLS shows is obsolete.

Proposed change. Flip the INCLUDE_OBSOLETE default to false. Keep deprecated.tsv committed and hand-maintained, unchanged. Regenerate and commit the affected artifacts in the same PR.

Archive format. deprecated.tsv already satisfies "a TSV that ROBOT can convert to OWL", so no new committed artifact is strictly needed. Recommendation is to keep the TSV as the only committed form and generate the OWL on demand, because a committed generated OWL is a second copy that drifts. If a consumable OWL is wanted, attach metpo-obsolete.owl to tagged releases with its own ontology IRI (https://w3id.org/metpo/metpo-obsolete.owl, not the main one) rather than committing it.

Cost to weigh before merging. kg-microbe reads metpo.owl from main. Once obsolete terms leave the release, kg-microbe and other consumers can no longer detect that a referenced ID is obsolete. That was the argument that carried #378, and it does not go away. Decide deliberately whether the cleaner OLS presence is worth it.

Do not couple this to deprecation cleanup. #521 Deprecation metadata review found that 643 of 1217 obsolete terms are cross-era duplicates with mechanically assigned reasons. For OLS presentation that is a defect; for an ID-burn archive it is not, because every burned ID belongs on the record including duplicates. Fix presentation there, not here.

Check before merging. make audit-ids and reports/id-allocation-audit.md must still see the full burned-ID set from the TSV once the merge step is off.

[realmarcin]

Some measured consumer-side cost for this, from kg-microbe, which downloads metpo.owl and metpo.json and reads the JSON directly in its MetaTraits transform.

The released JSON is now 75% obsolete terms

snapshot	size	METPO terms	deprecated	active
our cached copy, fetched 2026-07-27	275 KB	403	0	403
main today (2026-08-31)	1,044 KB	1,619	1,216	403

Same 403 active terms in both. The file is 3.8× larger and every added byte is an obsolete term. metpo.owl agrees: 1,619 declared entities (1,454 classes, 132 object properties, 33 datatype properties), of which 1,216 are deprecated.

Two overlapping obsolete ID series, which is a hazard for anyone normalising CURIEs

Among the deprecated terms there are 274 six-digit local ids (METPO:000001 … ) alongside the seven-digit series. They are not the same terms, and they are not consistently duplicates:

METPO:000001   obsolete Temperature        METPO:0000001  obsolete Temperature        (same label)
METPO:000010   obsolete Cell Width         METPO:0000010  obsolete Cell Width         (same label)
METPO:000100   obsolete Exospores          METPO:0000100  obsolete Myxospores         (different!)
METPO:000274   obsolete Colony Morphology  METPO:0000274  obsolete Physical Property  (different!)

Every one of the 274 has a seven-digit counterpart that also exists, so a consumer that zero-pads local ids to a fixed width — a normal thing to do — silently merges two distinct historical terms, and at low numbers the identical labels make the merge look correct.

The saving grace is that all 274 are deprecated and no active term is involved, which is exactly why this belongs here rather than as its own issue: shipping the archive repo-side only makes the whole class of problem unreachable for consumers. If deprecated terms stay in the released OWL, this one probably wants fixing on its own.

What it does not break

For completeness, since it would have been the strongest argument and it did not hold up: I expected the deprecated bulk to leak into our MetaTraits binned-range loader, which selects on "optimum" in label plus range_min/range_max and does not filter deprecated. Replaying it against both snapshots gives 15 binned classes either way (7 temperature, 4 pH, 4 NaCl), 0 deprecated — the obsolete terms carry no range_min/range_max, so they fall out. No live breakage on our side today.