Interactive guide
Ontologies
for knowledge & AI
Learn ontologies through a concrete IT scenario: internal support bot, incidents like INC-1042, HR policy, API runbooks, and production services — then see how to build one step by step.
Step 03 walks through creation from workshop to published schema. Step 05 is the live knowledge graph.
Part 1 · Step 01
What is an ontology?
A formal schema for a business domain — who and what exists, how they connect, and which fields each concept carries.
Real scenario
Your company deploys an internal chatbot. Employees ask about PTO, API rate limits, and who to page when latency spikes. Without an ontology, every team names things differently and the bot guesses.
Shared vocabulary
Everyone agrees Incident means a production Jira ticket, not a security audit. Employee is not the same as Customer.
Relationships + rules
An Incident can affect a Service. A Runbook documents how to fix that service.
Machine-readable schema
Exported as JSON / OWL so RAG pipelines tag documents, search filters metadata, and LLM tools validate parameters automatically.
Like a database schema for meaning— but focused on concepts across HR, ops, and product, not just one app's tables.
Part 1 · Step 02
Taxonomy vs ontology
Confluence folders organize docs. Ontologies capture facts like "this incident affects that API" — what support engineers actually need.
Support ticket categories (folder tree only)
Categories tell you where a file lives — not that INC-1042 affects Events API or which runbook to open.
Part 2 · Step 03 — interactive
How an ontology is created
Not magic — a repeatable process: scope, workshop with domain experts, class hierarchy, properties, relationships, publish schema, wire to RAG and tools.
Walk through building the Acme Analytics IT ontology — the same domain as our RAG demo (HR policy, API guide, incident runbook).
1. Define scope
Owner: Product + engineering leadDo: Write the questions your AI must answer and which systems are in bounds.
Output: Scope doc: IT support bot — HR policy, API docs, incident runbooks.
Concrete artifact
Q: PTO balance? API rate limit? Who to page for latency?
Ontologies are not discovered in a lab — they are designed in workshops, iterated with domain experts, and published like an API schema your AI stack depends on.
Part 2 · Step 04
Building blocks
Four primitives in every ontology — illustrated with Sarah Chen, INC-1042, and the Events API.
Classes (types)
Shared categories — like types in TypeScript. Every Employee inherits Person fields (name, email) plus HR-specific ones.
You define Employee once; 500 staff records are instances, not 500 new types.
In Acme IT: Person → Employee · Document → Policy, Runbook · Service · Incident
RDF-style triple (real incident)
Subject — predicate — object. Store thousands of these triples → knowledge graph queryable by SQL, SPARQL, or graph APIs.
Part 2 · Step 05 — interactive
Knowledge graph view
The published ontology becomes a graph — click INC-1042 to see affected services, assignees, and linked runbooks.
Scenario: production alert INC-1042 (API latency). Click nodes to see how IT concepts connect across HR, ops, and engineering.
INC-1042 instance
Incident: Events API p95 latency > 500ms for 8 minutes.
- isA → Incident
- affects → Events API
- assignedTo → Sarah Chen
Part 3 · Step 06
Ontology in the AI stack
Metadata filters for RAG, tool schemas for LLMs, and graph traversals for ops — ontology sits between business knowledge and models.
RAG + metadata filters
User asks about PTO → retrieve only chunks tagged Policy, not API docs. Cuts noise and hallucination.
Question: How many PTO days? → filter ontologyClass=Policy → chunk from HR Policy 2024
Where ontology sits in the stack
Ontology is not a replacement for RAG or LLMs — it structures the knowledge they consume and the actions they may take.
Part 3 · Step 07
Formats & checklist
Start with JSON Schema or internal YAML; adopt OWL/RDF when you need formal reasoning or industry standards.
JSON Schema · OpenAPI · custom YAML
When: Fast iteration, tool definitions, product ontologies
Pros: Easy for engineers, version in Git
Cons: Less automated reasoning, informal constraints
Engineering checklist
- Start with a bounded domain — HR + API docs, not the whole company.
- Co-design with domain experts; ontologies fail when engineers invent terms alone.
- Prefer stable class names; instances and properties change more often.
- Link ontology IDs to RAG chunk metadata for hybrid search.
- Document mappings when merging ontologies from acquired products.
Pair with the RAG walkthrough for retrieval pipelines and Introduction to LLMs for the model layer — ontology is the semantic glue between them.