Ontology engineering that ships

Model classes and relations with enough rigor to power retrieval, validation and integration.

Why it matters

Over-modeled ontologies stall delivery; under-modeled ontologies create integration chaos. The practical target is minimal formalism with maximal interoperability.

Pragmatic ontology engineering targets minimal formalism, maximal interoperability: model classes and relations with just enough rigor to power retrieval, validation and integration — and no more. Over-modeled ontologies stall delivery; under-modeled ones create integration chaos.

{
  "version": "1.2.0",
  "classes": {"Learner": {"parents": ["Person"]}, "Course": {"parents": ["LearningAsset"]}},
  "relations": {"enrolledIn": {"domain": "Learner", "range": "Course", "cardinality": "many_to_many"}},
  "constraints": {"Learner.email": "required", "Assessment.score": "0..100"},
  "mappings": {"sql_table": "public.learners", "json_path": "$.learner"}
}

Domain/range constraints are what make an ontology enforce quality, not just describe it. enrolledIn with domain Learner and range Course lets your graph-build step reject Course-enrolledIn-Learner automatically — the same validation that protects GraphRAG construction quality (Level 2).

Version it like an API contract. Classes and relations are consumed by extraction, retrieval and downstream integrations; changing one without a version + deprecation path breaks them silently. A version field plus deprecation blocks ('relation X replaced by Y') is what keeps integrations from drifting.

Mappings tie the ontology to reality — which SQL table or JSON path each class comes from. An ontology with no mappings is a philosophy diagram; with mappings it's an executable integration contract.

Pragmatic ontology engineering is designing power-socket standards. You don't need to model the philosophy of electricity — you need enough shared shape (voltage, pin layout, versioned standard) that any appliance from any vendor plugs in. Too little standard and nothing connects; too much and you've shipped nothing.

• Random relation names per project. Symptom: integration chaos. Fix: a shared, versioned vocabulary.
• No domain/range. Symptom: nonsensical edges accepted. Fix: constraints that reject bad triples.
• Unversioned ontology. Symptom: silent breakage. Fix: version + deprecation blocks.
• No mappings. Symptom: pretty diagram, no execution. Fix: bind classes to SQL/JSON sources.