Ontology, Taxonomy, Data Model, Context Graph — Friends
Summary
Milan Mosny maps the knowledge representation family: Ontology (the meaning layer — what things are, their relationships and constraints), Taxonomy (hierarchical classification — “is-a” structure, multiple valid taxonomies per entity), and Knowledge Graph (instantiated data — actual entities connected by relationships according to ontological rules). These bridge semantic web traditions with modern data governance and AI. The critical addition: Context Engineering designs the pipeline that selects relevant subgraphs for specific AI decisions, assembling task-specific context from multiple sources to prevent hallucination.
Why This Was Bookmarked
“some thoughts about how to structure knowledge graphs”
Directly relevant to how we structure the vault and think about 06-reference/2026-04-01-karpathy-llm-knowledge-bases. The ontology/taxonomy/graph distinction helps us think more precisely about what our vault is and what QMD is doing.
Key Ideas
- Ontology: concepts + relationships + business constraints. Formal languages (RDF/OWL) enable machine reasoning
- Taxonomy: hierarchical “is-a” classification. Multiple valid taxonomies for the same entity
- Knowledge Graph: instantiated data. “(Customer: C42) —PLACED—> (Order: O9001)” materializes abstract concepts as queryable facts
- Business Glossary: shared terminology layer ensuring organizational alignment
- Semantic Layer: business-friendly metrics/dimensions mapping to technical infrastructure
- Context Engineering: designs the pipeline selecting relevant subgraphs for specific AI decisions — the bridge between static knowledge and actionable context
- Context Graph: task-specific assembly of customer history, policies, comparable cases from multiple sources
- Automation over manual construction: tools like LinkML can generate outputs across multiple formats simultaneously
Connections
Our vault is essentially an informal knowledge graph with the wikilink structure serving as edges. The ontology layer maps to our frontmatter schema (type, date, source, etc.). The taxonomy maps to our folder structure (00-inbox through 06-reference). QMD provides the context engineering — selecting relevant subgraphs for specific queries.
This connects to 06-reference/concepts/compounding-knowledge — as the graph grows, the context engineering layer becomes more powerful because there are more relevant subgraphs to select from.
The semantic layer concept maps to 06-reference/concepts/analytics-as-craft and 01-projects/data-marketplace/index — data products need a shared semantic layer.
Open Questions
- Should we formalize our vault’s ontology? What concepts and relationships do we need to declare explicitly?
- Can we generate a knowledge graph visualization from our wikilinks?
- How does the context graph concept inform how we build QMD queries?