Ontology Design Patterns
Module Summary
Learn naming conventions, inheritance hierarchies, and design patterns for building clean, composable Ontologies.
Naming Conventions
Use business-friendly names for Object Types and Properties — "Flight" not "tbl_flights", "Departure Airport" not "dep_apt_cd". Users who interact through Workshop and search should never need to know your internal naming schemes.
Establish a naming guide early: singular nouns for Object Types (Flight, Employee), verb phrases for Actions (Reassign Flight, Approve Expense).
Composition and Reuse
Design for composability:
- Create shared Object Types that multiple teams reference (e.g., a central "Employee" Object Type used by HR, Finance, and Operations).
- Use interface patterns — if multiple Object Types share properties (name, description, status), consider whether they should link to a shared reference object.
- Avoid duplication: one Object Type per real-world concept.
Handling Change Over Time
Business models evolve. Plan for change:
- Additive changes (new properties, new Object Types) are safe and backward-compatible.
- Breaking changes (renaming a primary key, changing cardinality) require migration plans.
- Use versioned backing datasets so you can roll back Ontology changes if something goes wrong.
- Document your Ontology decisions in a central wiki so future maintainers understand the rationale.
Key Takeaways
- Use business-friendly names — the Ontology is for humans, not machines.
- Design for composability: shared Object Types, no duplication.
- Prefer additive changes; plan carefully for breaking changes.
- Document your Ontology design decisions for future maintainers.