ontology-designlisted

# 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 │ └─ Jus