Schema clean-up: chemdcat-ap inheritance, quality audit, catalyst/reaction classification, real-world example datasets

[HendrikBorgelt]

closes #109
closes #59
closes #34
closes #111
closes #53
closes #110
closes #112

Summary

Schema clean-up and quality pass across CoreMeta4Cat: proper LinkML inheritance from chemdcat-ap (CatalyticReaction is_a: ChemicalReaction, ChemicalReactor is_a: Reactor), a full modelling/mapping audit (mismatched ontology mappings, is_a relation-typing sweep across 295 slots, multivalued anti-patterns), catalysis-specific reactor slots, three fully worked real-world example datasets validated as test data, and expanded documentation (inheritance, catalysis-dataset model, working-with-data guide, contributing/getting-started fixes).

This also touches the same area as PR #118 (catalyst/reaction classification) — see "On the catalyst_type / has_catalyst_type conflict" below before reviewing the reaction_ap changes.

On the catalyst_type / has_catalyst_type conflict

This branch and the already-merged #118 independently redesigned catalyst/reaction classification while diverging from the same base. This PR keeps this branch's design — catalyst_type (CatalysisResearchFieldEnum) + catalyst_form (CatalystFormEnum) as two slots, and rdf_type (DCAT-AP-PLUS Pattern 3) for reaction type — instead of #118's has_catalyst_type: CatalystType / has_reaction_type: ReactionType class hierarchies. Reasoning:

• CatalystType conflates two independent axes. Its subclasses HeterogeneousCatalyst/HomogeneousCatalyst/BioCatalyst/ElectroCatalyst/PhotoCatalyst (catalytic regime) sit as siblings of ThinFilmCatalyst/BulkCatalyst/PowerderedCatalyst/DepositedSampleCatalyst/SupportedCatalsyt (physical form) in one flat hierarchy. These aren't mutually exclusive — a catalyst is routinely both "heterogeneous" and "supported" at once. The five form-related subclasses use VOC4CAT ids identical to this branch's CatalystFormEnum permissible values (0000019/0007015/0000017/0000038/0007034), confirming both sides are describing the same underlying vocabulary, just merged into one axis on Added new classes & slots in coremeta4cat_reaction_ap.yaml #118's side. The practical effect shows up in Added new classes & slots in coremeta4cat_reaction_ap.yaml #118's own test data: has_catalyst_type: [{value: "heterogeneous, supported metal oxide"}] — free text stuffed into a generic value field, which defeats the purpose of having ten typed subclasses.
• has_reaction_type duplicates an existing mechanism. CatalyticReaction.rdf_type already carries reaction-type classification via Pattern 3 (the same convention used by Synthesis, Characterization, Simulation, and CatalysisDataset throughout this schema) and is already recommended. Added new classes & slots in coremeta4cat_reaction_ap.yaml #118's ReactionType class_uri (VOC4CAT:0007010) is the same URI already documented as the example value for rdf_type here — same concept, two competing mechanisms for asserting it.

Not claiming #118 was wrong to attempt — it was explicitly a stopgap while this work was in progress. Happy to walk through the reactor-slot and ReactorPerformanceMeasures/Conversion/SpaceTimeYield/Selectivity additions from #118 separately; those don't conflict with this design and may be worth keeping.

On #116 / #117 (cardinality of catalyst_type / reaction type)

Deliberately left catalyst_type and reaction rdf_type as recommended rather than required, per #117's request. In research contexts, classification can be genuinely disputed (a researcher may argue a catalyst is type A, not type B) or the catalyst may not fit any current CatalysisResearchFieldEnum value yet — forcing a mandatory value would push contributors into a premature or contested classification rather than leaving the field open until vocabulary/consensus catches up. Rationale is also recorded as schema comments next to both slots in coremeta4cat_reaction_ap.yaml. Open to discussion in a follow-up issue if a different tradeoff is preferred — flagging #116 as the place to continue that.

Other issues addressed in this PR

• Term Feedback: precursor_quantity #109, Term Feedback: precipitating_concentration #59, Term Feedback: precipitating_concentration #34 — CURIE/term fixes (precursor_quantity, new precipitating_concentration slot)
• CatCore to CoreMeta4Cat #111, Issues in "getting started" #53 — "CatCore" → "CoreMeta4Cat" renamed throughout getting-started docs; sheet-name table brought in line with the workbook's actual current sheets
• Request for some changes wrt to usage of the term "Voc4Cat term" to bit general #110 — generalized "Voc4Cat term" wording to "CURIE" (schema mixes VOC4CAT with CHMO/QUDT/OBI/SIO/NCIT/AFE terms, so "Voc4Cat term" was already inaccurate)
• Additional description in the Contributing section #112 — getting-started.md now documents the workbook's colour coding/columns (with real screenshots) and the inbox PR workflow in detail, including the automated check's actual validation messages and how to resolve each

Already resolved by earlier work on this branch, no action taken: #112's original ask (contributing.md inbox description) was already covered before this PR; #53's Excel-tab-naming complaint no longer applies (sheets are Synthesis/Characterization/Reaction/Simulation/CoreMeta4Cat now, not the old split names). #42 will be answered directly on the issue (not a schema change). #69 (broken download link) and #115 (docs home-page PR) are unrelated to this branch's scope.

Test plan

• just test (schema generation, pytest, linkml-run-examples against tests/data) — all green
• 3 real-world example CatalysisDataset records validate end-to-end
• just gen-doc regenerated cleanly, no orphaned references
• Reviewer sanity-check on the catalyst_type/reaction_type reasoning above