Ontologies and knowledge graphs from first principles — for engineers who keep hearing the terms next to RAG and LLMs and want to actually understand them. What an ontology is (a formal, machine-readable description of a domain's things and relationships; the ladder from schema to taxonomy to ontology; classes, individuals, properties, axioms; why it gives LLMs a verifiable source of truth), RDF and OWL (all knowledge as triples so a triple set is a graph; URIs as global names; OWL's logic — inverse/transitive properties, cardinality, class expressions — grounded in description logic so a reasoner derives unstated facts and catches contradictions), knowledge graphs (the ontology populated; RDF vs labeled property graphs; why graphs win for connected problems — first-class relationships, flexing schema, meaning in structure), querying with SPARQL (pattern matching not joining; path expressions for arbitrary-depth connection SQL can't express; inference-aware queries over the reasoned graph; Cypher for property graphs), building knowledge graphs and entity resolution (construction is the hard 80%; the ingest-extract-map-resolve-load pipeline; entity resolution as make-or-break — under-merging fragments, over-merging asserts false links; deterministic/fuzzy/ML/graph-context matching; connectivity amplifies errors so provenance matters), GraphRAG (plain vector RAG retrieves disconnected chunks and misses relationships; GraphRAG retrieves a subgraph by traversing the graph so multi-hop answers are walked not guessed — typed, verifiable, citable; when to use it and why hybrid wins), the semantic layer (the enterprise ontology made operational — define entities, relationships, and metrics once so dashboards, analysts, and AI agents inherit the same definitions; why 'revenue' means three things; why AI made it urgent), and operating knowledge graphs in practice (a system you run not a project you finish — governing the ontology as it evolves, keeping the populated graph correct, and the honest build-or-not decision). Grounded in Wikipedia (ontology, taxonomy, RDF, OWL, knowledge graph, graph database, SPARQL, Cypher, record linkage, named-entity recognition, retrieval-augmented generation, Semantic Web, data virtualization, data governance).
"Ontology" sounds like philosophy, and historically it was — the study of what exists. In computing it means something more concrete and more useful: a formal, explicit description of the things in a domain and how they relate, written so a machine can reason about it. As AI systems increasingly need to ground their answers in structured truth rather than guess from text, ontologies and the knowledge graphs built on them have become quietly essential. This series builds both from first principles.
'Ontology' sounds like philosophy; in computing it's a formal, machine-readable description of a domain's things and relationships. The ladder from schema to taxonomy to ontology, the building blocks (classes, individuals, properties, axioms), and why ontologies give LLMs the verifiable source of truth they lack.
Post 1 said an ontology is meaning a machine can compute with. This post is about the notation that makes that real: RDF, the dead-simple data model that represents any fact as a three-part statement, and OWL, the language that adds the logical rules a reasoner can act on. These are the W3C standards underneath most of the semantic-web and knowledge-graph world, and their core ideas are far simpler and more elegant than the acronyms suggest.
RDF represents all knowledge as triples (subject–predicate–object), so a set of triples is automatically a graph. OWL adds logic — inverse/transitive properties, cardinality, class expressions — grounded in description logic, so a reasoner can derive unstated facts and catch contradictions. The standards under the knowledge-graph world.
An ontology is the blueprint; a knowledge graph is the building. A knowledge graph is a network of real-world entities and the relationships between them, structured against an ontology so that both humans and machines can navigate it, query it, and reason over it. They power web search, recommendations, fraud detection, and increasingly the grounding of LLMs — and understanding what makes a graph a "knowledge" graph is understanding why this shape of data keeps winning for connected problems.
A knowledge graph is the ontology populated — entities as nodes, typed relationships as edges, integrated from many sources. RDF vs property graphs, and why graphs win for connected problems: relationships are first-class (traversal, not join cascades), the schema flexes, and meaning lives in structure.
A knowledge graph you can't query is just a diagram. The power of the graph is realized when you can ask it questions — and querying a graph is fundamentally different from querying tables. Instead of joining rows, you describe a pattern of connections and ask the graph to find every place that pattern occurs. This post covers SPARQL, the standard query language for RDF graphs, and the graph-pattern-matching mindset that makes graph queries so expressive for connected questions.
Querying a graph is pattern matching, not joining: you describe a shape of nodes and edges and the engine finds every match. SPARQL (and Cypher for property graphs), path expressions for arbitrary-depth connection that SQL can't express, and inference-aware queries over the reasoned graph.
The hardest part of a knowledge graph isn't querying it or designing the ontology — it's building it from messy, real-world data. Most of your knowledge lives in databases that don't connect, documents that don't parse, and records that refer to the same thing by different names. Construction is the engineering of turning that mess into a clean, connected graph, and its central, unglamorous challenge is entity resolution: deciding when two records are actually the same thing. This post is about the work that makes or breaks a knowledge graph.
The hard part isn't the ontology or the queries — it's construction. The pipeline from heterogeneous sources, and its make-or-break challenge: entity resolution (deciding when two records are the same thing). Under-merging fragments; over-merging asserts false connections; connectivity amplifies every error.
This is the post the whole series was building toward. Retrieval-augmented generation gives an LLM relevant text to ground its answers, but plain RAG retrieves disconnected chunks and misses the relationships between facts. GraphRAG grounds the model in a knowledge graph instead — so it can follow relationships, reason across multiple hops, and answer questions that no single chunk contains. It's where ontologies stop being theory and become the thing that makes an AI system trustworthy on your domain.
The post the series built toward. Plain vector RAG retrieves disconnected chunks and misses relationships; GraphRAG retrieves a subgraph by traversing the knowledge graph, so multi-hop answers come from walked edges, not guessed connections — typed, verifiable, citable. When to use it, and why hybrid often wins.
In a large organization the hardest data problem isn't storage or speed — it's that nobody agrees what "customer," "revenue," or "active user" actually means, and every team computes them differently. A semantic layer is the ontology applied to the enterprise: a shared, governed definition of the business's concepts and relationships that sits above the scattered data and gives everyone — dashboards, analysts, and now AI agents — one consistent meaning to build on. This is where ontologies deliver their most concrete business value.
The enterprise ontology made operational: a governed layer that defines the business's entities, relationships, and metrics once, so dashboards, analysts, and AI agents all inherit the same definitions. Why 'revenue' means three things, and why AI made the semantic layer urgent — an agent is only as correct as its grasp of your terms.
A knowledge graph is not a project you finish; it's a system you run. Ontologies evolve, data drifts, quality decays, and the graph has to stay trustworthy while the business changes around it. This closing post covers the operational reality — governing the ontology, keeping the graph correct over time, and the honest question most teams skip: given the cost, when is a knowledge graph actually the right tool? It ties the series into a decision you can make with clear eyes.
A knowledge graph is a system you run, not a project you finish. Governing the ontology as it evolves, keeping the populated graph correct (freshness, re-resolution, provenance), and the honest question: given the cost, when is a knowledge graph the right tool — and when is a table or plain vector RAG cheaper and enough?
This series is part of a larger body of work by Pratik Dhanave, an Agentic AI Architect writing about production AI systems, distributed systems, and cloud-native engineering. Explore all course series, browse every post, or find topics via the tag index.