ontology-modeling
Ontology Modeling
Concept of the skill
Ontology modeling is the discipline of formalizing the meaning of a domain into classes, properties, and axioms whose semantics is precise enough for automated reasoning, validation, or cross-system interoperability. Drawing from Aristotle's categories, Gruber's information-systems definition ("a specification of a conceptualization"), and Guarino's formal-ontology tradition, it treats meaning as something that can be specified — a commitment to a conceptualization — and the specification as a contract that downstream consumers can compute over. Outputs: class hierarchies, object/data properties with domain/range, cardinality constraints, equivalence and disjointness axioms, identity criteria, controlled vocabularies, validation shapes (SHACL), interop-oriented JSON-LD/RDF projection.
Replaces "informal taxonomy plus prose conventions" with formal axiomatization when ambiguity, interoperability, validation, or reasoning matter. Solves the problem that without formal semantics, two systems claiming to share a vocabulary may disagree on what the vocabulary means — the same class name carrying different membership criteria, the same property carrying different domain or range, the same hierarchy carrying different inheritance semantics. Most teams do not need OWL — they need clear conceptual models and controlled vocabularies. Escalate to ontology when another consumer must compute over the semantics, validate instances against constraints, or align meaning across systems. The ontology must preserve business meaning while stating which inferences are allowed. A vague ontology is worse than no ontology because it gives false confidence to downstream tools that compute over it; the resulting incorrect inferences are harder to diagnose than the absence of any formalism.
Distinct from taxonomy-design, which owns informal classification and facets — human-governed category trees, browse taxonomies, SKOS broader/narrower; this skill owns formal semantics with axioms and reasoning constraints. Distinct from conceptual-modeling, which is stakeholder-readable domain analysis (entities and relationships with humans, before any formalism) — this skill is machine-checkable semantic formalization. Distinct from entity-relationship-modeling, which owns persistence structure and constraints (tables, FKs, indexes) — this skill owns meaning constraints (class/property axioms, validation shapes). Distinct from knowledge-modeling, which chooses the representation paradigm (graph/frames/rules/hybrid) — this skill applies one formal paradigm once chosen. Distinct from semantic-relations, which types individual relation edges — this skill is the formalization layer above. An ontology is to a domain model what an engineering tolerance specification is to a manufactured part — the part might fit at +/-0.5mm informally (taxonomy, conceptual model), but if another factory must mass-produce a counterpart that mates with it, both factories need a tolerance spec that says exactly what 'fits' means in microns. The spec is more expensive to write than the napkin sketch, but it is the artefact that lets two shops produce interlocking parts without ever talking to each other. The wrong mental model is that every domain model should become an ontology — that formalization is universally better. It is not. Ontology modeling is only worth its cost when ambiguity, interoperability, validation, or reasoning matter; most teams need clear conceptual models and controlled vocabularies, not OWL axioms. Adjacent misconceptions: that more formal expressiveness is always better (it is not — Baader et al.'s Description Logic Handbook documents the expressiveness-tractability trade-off rigorously: OWL DL is more expressive than OWL EL, but EL admits polynomial-time reasoning that DL does not; choose the profile that fits the reasoning task); that disjointness claims are safe by default (they are not — disjointness is a durable commitment; "Customer and Organization are disjoint" forbids legitimate cases where one entity is both, and the inference is load-bearing for the consumer's reasoning); that synonyms are duplicate classes (they are not — they should be aliases via owl:sameAs or skos:altLabel, not separate classes with overlapping membership); that the open-world vs closed-world assumption is implicit (it is not — RDF/OWL is open-world by default ["absence of a fact is not evidence of falsehood"]; many consumer applications assume closed-world ["if it's not in the database, it doesn't exist"]; the assumption must be documented or downstream reasoning produces wrong answers); and that the ontology is the system (it is not — the ontology is one artefact; the system also has data, code, and user-facing behaviour, and the ontology only governs the slice where formal semantics genuinely matter).
Coverage
Formalize domain meaning into classes, properties, constraints, and axioms. Covers class hierarchy, object/data properties, domain/range, cardinality constraints, equivalence, disjointness, identity, controlled vocabularies, validation shapes, and interop-oriented JSON-LD/RDF projection. The output may be an actual ontology file or a precise ontology sketch before implementation.
Philosophy of the skill
Ontology modeling is only worth its cost when ambiguity, interoperability, validation, or reasoning matter. Most teams do not need OWL. They need clear conceptual models and controlled vocabularies. Escalate to ontology when another consumer must compute over the semantics, validate instances against constraints, or align meaning across systems.
The ontology must preserve business meaning while stating which inferences are allowed. A vague ontology is worse than no ontology because it gives false confidence to downstream tools.