Ontology design

Ontology Design

Model domain knowledge through classes, properties, and relationships. An ontology is not a database schema — it encodes meaning, not just structure. A well-designed ontology enables reasoning (inferring new facts from existing ones), not just storage.

When to Use

• Building a knowledge graph that requires formal class hierarchies
• Designing semantic models where relationships carry meaning (not just foreign keys)
• Creating taxonomies that enable automated reasoning or inference
• Modeling domains where "is-a" and "has-a" distinctions matter
• Structuring data for RDF/OWL or semantic web technologies
• Designing type systems where inheritance and composition have semantic weight

When NOT to Use

• CMS content types, editorial workflows, or publishing structures (use content-modelling)
• Naming conventions or terminology standards across docs (use consistency-standards)
• Database schema design for CRUD applications (use database schema tools)
• API data models (use API design or TypeScript/Python type definitions)
• Simple key-value or document storage (no ontology needed)

Decision Tree

What are you modeling?
│
├─ Entities with "is-a" relationships (inheritance)?
│  ├─ Need automated reasoning over the hierarchy? → Yes, ontology
│  └─ Just need type categories in code? → No, use enum/interface in code
│
├─ Relationships between entities with semantic meaning?
│  ├─ Need to infer new relationships? → Yes, ontology with reasoning
│  └─ Just need to join tables? → No, use database schema
│
├─ Taxonomy with formal classification?
│  ├─ Multiple inheritance or overlapping categories? → Yes, ontology
│  └─ Simple flat categories? → No, use tags or enums
│
├─ Need RDF/OWL/SPARQL?
│  └─ Yes → Ontology design (this skill)
│
└─ Not sure if ontology or schema
   ├─ Does "Dog is-a Animal" enable reasoning beyond code type checks? → Ontology
   └─ Just storing data with relationships? → Database schema

Core Components

Component	Purpose	Example
Class	Category of things	Person, Product
Property	Attribute of class	name, price
Relationship	Connection between classes	owns, partOf
Instance	Specific entity	John, iPhone15
Axiom	Rule that constrains interpretation	Person ⊓ hasChild ≥ 1 → Parent

Relationship Types

Type	Notation	Example	Inverse
Is-a (inheritance)	subClassOf	Dog is-a Animal	—
Has-a (composition)	hasPart	Car has-a Engine	partOf
Uses (association)	uses	Person uses Tool	usedBy
Instance-of	type	Fido instance-of Dog	—
Causes (causation)	causes	Smoking causes Disease	causedBy

Always define inverse relationships where they exist. Missing inverses break traversal and reasoning.

Taxonomy Levels

Kingdom
  └── Phylum
        └── Class
              └── Order
                    └── Family
                          └── Genus
                                └── Species

Rule: taxonomies deeper than 7 levels become unmaintainable. If you need more, consider faceted classification instead.

Design Template

## Class: [Name]

**Description**: [purpose]
**Parent**: [superclass]

### Properties
| Name | Type | Required | Description |
|------|------|----------|-------------|
| id | string | yes | Unique identifier |
| name | string | yes | Display name |

### Relationships
| Relation | Target | Cardinality | Inverse |
|----------|--------|-------------|---------|
| belongsTo | Category | many-to-one | contains |
| contains | Item | one-to-many | belongsTo |

Design Principles

• MECE: Mutually exclusive, collectively exhaustive
• Single inheritance preferred: Avoid diamond problem; use composition for shared behavior
• Normalize: Reduce redundancy; each fact stated once
• Domain-driven: Match real-world concepts, not implementation artifacts
• Define inverses: Every bidirectional relationship needs both directions
• Constrain cardinality: State minimum and maximum explicitly (1..*, 0..1, etc.)
• Separate taxonomy from ontology: Taxonomy classifies; ontology relates

Anti-Patterns

Anti-Pattern	Problem	Solution
God class (too many responsibilities)	Class becomes a catch-all; reasoning produces false inferences	Split into focused classes; use composition over inheritance
Orphan classes (no relationships)	Class exists in isolation; no reasoning possible	Connect via at least one relationship or place in hierarchy
Circular dependencies	A depends on B depends on A; reasoning loops	Break cycle by extracting shared concept into a third class
Over-abstraction	Generic classes like Thing or Entity add no semantic value	Only abstract when subclasses share meaningful properties
Missing inverses	Traversal works in one direction only; queries fail	Define inverse for every bidirectional relationship
Diamond inheritance	Class inherits from two parents that share an ancestor	Prefer single inheritance + composition; use mixins/traits if needed
Confusing is-a with has-a	"Car is-a Wheel" instead of "Car has-a Wheel"	Is-a = "every X is also a Y"; Has-a = "X contains Y as a part"
Modeling implementation, not domain	Classes mirror database tables or API endpoints	Model the domain concepts; map to implementation separately
Ignoring temporal aspects	"Person lives-at Address" with no time range	Add valid-from/valid-to for facts that change over time

Related Skills

• content-modelling — CMS content types, editorial workflows, publishing structures
• consistency-standards — Naming conventions and terminology standards
• memory-systems — Knowledge graph storage and retrieval for agents