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
1---2name: ontology-design3description: Design formal knowledge models — classes, properties, relationships, hierarchies, and semantic graphs — for knowledge representation and reasoning. Use when the user asks to build an ontology, design a knowledge graph, model entity relationships formally, define class hierarchies, create a taxonomy for semantic reasoning, or structure data for RDF/OWL. NOT for CMS content types, editorial workflows, or publishing structures (use content-modelling). NOT for naming conventions or terminology standards across docs (use consistency-standards).4---56# Ontology Design78Model 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.910## When to Use1112- Building a knowledge graph that requires formal class hierarchies13- Designing semantic models where relationships carry meaning (not just foreign keys)14- Creating taxonomies that enable automated reasoning or inference15- Modeling domains where "is-a" and "has-a" distinctions matter16- Structuring data for RDF/OWL or semantic web technologies17- Designing type systems where inheritance and composition have semantic weight1819## When NOT to Use2021- CMS content types, editorial workflows, or publishing structures (use content-modelling)22- Naming conventions or terminology standards across docs (use consistency-standards)23- Database schema design for CRUD applications (use database schema tools)24- API data models (use API design or TypeScript/Python type definitions)25- Simple key-value or document storage (no ontology needed)2627## Decision Tree2829```30What are you modeling?31│32├─ Entities with "is-a" relationships (inheritance)?33│ ├─ Need automated reasoning over the hierarchy? → Yes, ontology34│ └─ Just need type categories in code? → No, use enum/interface in code35│36├─ Relationships between entities with semantic meaning?37│ ├─ Need to infer new relationships? → Yes, ontology with reasoning38│ └─ Just need to join tables? → No, use database schema39│40├─ Taxonomy with formal classification?41│ ├─ Multiple inheritance or overlapping categories? → Yes, ontology42│ └─ Simple flat categories? → No, use tags or enums43│44├─ Need RDF/OWL/SPARQL?45│ └─ Yes → Ontology design (this skill)46│47└─ Not sure if ontology or schema48 ├─ Does "Dog is-a Animal" enable reasoning beyond code type checks? → Ontology49 └─ Just storing data with relationships? → Database schema50```5152## Core Components5354| Component | Purpose | Example |55|-----------|---------|---------|56| Class | Category of things | `Person`, `Product` |57| Property | Attribute of class | `name`, `price` |58| Relationship | Connection between classes | `owns`, `partOf` |59| Instance | Specific entity | `John`, `iPhone15` |60| Axiom | Rule that constrains interpretation | `Person ⊓ hasChild ≥ 1 → Parent` |6162## Relationship Types6364| Type | Notation | Example | Inverse |65|------|----------|---------|---------|66| Is-a (inheritance) | `subClassOf` | Dog is-a Animal | — |67| Has-a (composition) | `hasPart` | Car has-a Engine | `partOf` |68| Uses (association) | `uses` | Person uses Tool | `usedBy` |69| Instance-of | `type` | Fido instance-of Dog | — |70| Causes (causation) | `causes` | Smoking causes Disease | `causedBy` |7172Always define inverse relationships where they exist. Missing inverses break traversal and reasoning.7374## Taxonomy Levels7576```77Kingdom78 └── Phylum79 └── Class80 └── Order81 └── Family82 └── Genus83 └── Species84```8586Rule: taxonomies deeper than 7 levels become unmaintainable. If you need more, consider faceted classification instead.8788## Design Template8990```markdown91## Class: [Name]9293**Description**: [purpose]94**Parent**: [superclass]9596### Properties97| Name | Type | Required | Description |98|------|------|----------|-------------|99| id | string | yes | Unique identifier |100| name | string | yes | Display name |101102### Relationships103| Relation | Target | Cardinality | Inverse |104|----------|--------|-------------|---------|105| belongsTo | Category | many-to-one | contains |106| contains | Item | one-to-many | belongsTo |107```108109## Design Principles110111- **MECE**: Mutually exclusive, collectively exhaustive112- **Single inheritance preferred**: Avoid diamond problem; use composition for shared behavior113- **Normalize**: Reduce redundancy; each fact stated once114- **Domain-driven**: Match real-world concepts, not implementation artifacts115- **Define inverses**: Every bidirectional relationship needs both directions116- **Constrain cardinality**: State minimum and maximum explicitly (1..*, 0..1, etc.)117- **Separate taxonomy from ontology**: Taxonomy classifies; ontology relates118119## Anti-Patterns120121| Anti-Pattern | Problem | Solution |122|---|---|---|123| God class (too many responsibilities) | Class becomes a catch-all; reasoning produces false inferences | Split into focused classes; use composition over inheritance |124| Orphan classes (no relationships) | Class exists in isolation; no reasoning possible | Connect via at least one relationship or place in hierarchy |125| Circular dependencies | A depends on B depends on A; reasoning loops | Break cycle by extracting shared concept into a third class |126| Over-abstraction | Generic classes like `Thing` or `Entity` add no semantic value | Only abstract when subclasses share meaningful properties |127| Missing inverses | Traversal works in one direction only; queries fail | Define inverse for every bidirectional relationship |128| Diamond inheritance | Class inherits from two parents that share an ancestor | Prefer single inheritance + composition; use mixins/traits if needed |129| 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" |130| Modeling implementation, not domain | Classes mirror database tables or API endpoints | Model the domain concepts; map to implementation separately |131| Ignoring temporal aspects | "Person lives-at Address" with no time range | Add valid-from/valid-to for facts that change over time |132133## Related Skills134135- **content-modelling** — CMS content types, editorial workflows, publishing structures136- **consistency-standards** — Naming conventions and terminology standards137- **memory-systems** — Knowledge graph storage and retrieval for agents
viktorbezdek