Knowledge Graphs: What They Are, Where They Live, and How to Build One

Knowledge graphs quietly power a surprising amount of the tech you touch every day — search results, recommendations, fraud alerts, and increasingly the AI assistants we talk to. Yet the core idea is refreshingly simple. Let’s walk through it end to end: what a knowledge graph is, where you store one, where they’re useful, their trade-offs, and finally a small one you can build yourself in Python. What is a knowledge graph? A knowledge graph is a way of representing information as a network of entities (the things) connected by relationships (how they relate). That’s it. Instead of cramming facts into rows and columns, you store them as connections. The unit of knowledge is a triple — a subject, a relationship, and an object: Catlin → lives in → NewYork Luna → is a → Cat In graph terms, the entities are nodes (the dots) and the relationships are edges (the labeled lines between them). Chain enough triples together and you get a web of meaning that both humans and machines can navigate. The phrase Google used when it popularized the term captures it perfectly: “things, not strings.” A knowledge graph cares about real things and how they connect, not just matching text. A simple example to illustrate it Picture your friend Catlin and everything orbiting her. She lives in NewYork, works at Mercy Hospital, is married to John, and owns a cat named Luna. Her coworker Liam also lives in NewYork and owns a cat named Rex. You don’t naturally store that as a paragraph — you store it as a web of connections. Drawn out, it looks like this: Notice how Catlin, John, and Liam all funnel into Mercy Hospital and New York, while Luna and Rex branch toward the shared concept of Cat. Nothing here is a sentence or a table cell. The information is the shape of the connections — and that shape is exactly what makes graphs powerful for questions about how things relate. Press enter or click to view image in full size Simple Knowledge Graph Illustration Where do we store a knowledge graph? A graph is a concept, but you still need somewhere to keep it. You’ve got a few options depending on scale and seriousness: In memory, for prototyping. For learning or small projects, a library like Python’s networkx holds the whole graph in memory. No setup, no server — perfect for getting started (and what we'll use below). A graph database, for production. When the graph needs to persist, scale, and answer queries fast, you reach for a dedicated graph database. These come in two main flavors: Labeled property graphs. Tools like Neo4j, Amazon Neptune, and ArangoDB store nodes and edges directly, and let each carry properties (Catlin’s node might hold her age, an edge might hold a “since” date). Neo4j’s query language, Cypher, lets you write patterns that look a bit like ASCII art: (catlin)-[:OWNS]->(cat). RDF triplestores. Tools like GraphDB, Apache Jena, and Virtuoso store data strictly as RDF triples and query it with SPARQL, a W3C standard. This is the model behind big public graphs like Wikidata and DBpedia. The rough rule: reach for a property graph when you want flexible, developer-friendly modeling, and for an RDF triplestore when you need standards, interoperability, and formal semantics. Either way, the underlying idea never changes — it’s triples all the way down. Where do we use knowledge graphs? Once you start looking, they’re everywhere: Search engines. That info box that appears when you search a famous person or place is powered by a knowledge graph connecting them to related facts. Recommendations. Streaming services and online stores graph the connections between you, the catalog, and other users to suggest the next thing you’ll like. Social networks. “People you may know” is a graph query about who’s connected to whom. Fraud detection. Banks spot fraud by noticing suspicious clusters of connected accounts, transactions, and devices — a pattern that’s obvious in a graph and hard to see in a table. Healthcare and life sciences. Connecting genes, drugs, diseases, and symptoms helps researchers surface non-obvious links. AI assistants. Knowledge graphs increasingly ground large language models, giving them a structured, verifiable set of facts so answers are more accurate and traceable. The common thread: any time the relationships between things matter as much as the things themselves, a graph fits. Pros and cons Knowledge graphs are powerful, but they’re not a silver bullet. Here’s the honest scorecard. Pros Built for connected questions. Multi-hop queries (“friends of friends who also live here”) are natural in a graph and painful in tables. Flexible to extend. Adding a new kind of entity or relationship usually means just adding more triples — no rigid schema migration. Human-friendly and explainable. The structure mirrors how we actually think, and you can trace exactly which connections produced an answer. Great for integration. A graph is a natural place to merge messy data from many sources into one connected view. Cons Building it is real work. Extracting clean entities and relationships from messy data — and deciding that “NYC” and “New York City” are the same thing — is genuinely hard. Quality matters enormously. A sloppy or inconsistent graph can be worse than none at all. A learning curve. Query languages like SPARQL and Cypher, plus data modeling decisions, take time to master. Not ideal for everything. If your data is simple and tabular and you only ask simple questions, a regular database is often the better, simpler tool. A simple example to implement Enough theory — let’s build the Catlin graph for real. We’ll use networkx, which keeps everything in memory. pip install networkx First, represent the facts as triples and load them into a graph: import networkx as nx # A directed graph: edges have a direction (Catlin -> NewYork) kg = nx.DiGraph()# Each fact is a triple: (subject, object, relationship) triples = [ ("Catlin", "NewYork", "lives_in"), ("Catlin", "Mercy Hospital", "works_at"), ("Catlin", "John", "married_to"), ("Catlin", "Luna", "owns"), ("John", "Mercy Hospital", "works_at"), ("John", "Newyork", "lives_in"), ("Luna", "Cat", "is_a"), ("Liam", "Mercy Hospital", "works_at"), ("Liam", "Newyork", "lives_in"), ("Liam", "Rex", "owns"), ("Rex", "Cat", "is_a"), ]for subject, obj, relationship in triples: kg.add_edge(subject, obj, relationship=relationship)print("Entities:", kg.number_of_nodes()) print("Facts:", kg.number_of_edges())# Everything we know about Catlin print("\nFacts about Catlin:") for _, obj, data in kg.out_edges("Catlin", data=True): print(f" Catlin --{data['relationship']}--> {obj}") Running it prints: Entities: 8 Facts: 11 Facts about Catlin: Catlin --lives_in--> NewYork Catlin --works_at--> Mercy Hospital Catlin --married_to--> John Catlin --owns--> Luna Now the part that shows why graphs are special — a question that hops across several relationships: Which of Catlin’s coworkers live in the same city as her and own a cat? def objects_for(entity, relationship): """Follow one relationship out of an entity.""" return [o for _, o, d in kg.out_edges(entity, data=True) if d["relationship"] == relationship] def subjects_for(relationship, obj): """Find every entity that points to obj via this relationship.""" return [s for s, o, d in kg.in_edges(obj, data=True) if d["relationship"] == relationship] catlin_city = objects_for("Catlin", "lives_in")[0] workplaces = objects_for("Catlin", "works_at")answer = [] for workplace in workplaces: for coworker in subjects_for("works_at", workplace): if coworker == "Catlin": continue same_city = catlin_city in objects_for(coworker, "lives_in") owns_cat = any("Cat" in objects_for(pet, "is_a") for pet in objects_for(coworker, "owns")) if same_city and owns_cat: answer.append(coworker)print("Catlin lives in:", catlin_city) print("Coworkers in the same city who own a cat:", answer) Output: Catlin lives in: NewYork Coworkers in the same city who own a cat: ['Liam'] We chained four relationships — works_at, lives_in, owns, is_a — to reach an answer no single fact contained. John is a coworker in Newyork but owns no cat, so he's correctly left out. Liam fits perfectly. That multi-hop walk is the thing graphs do beautifully and tables struggle with. What’s next with knowledge graphs? You’ve now built and queried a real (if tiny) knowledge graph. From here, the path forward is mostly about scale and ambition: Feed it real data. Instead of typing triples by hand, extract them from CSVs, databases, or plain text. This extraction step is where most of the real engineering effort goes. Move to a real graph database. When the graph outgrows memory, graduate to Neo4j (with Cypher) or an RDF triplestore (with SPARQL) for persistence and speed at scale. Deepen the ontology. We gave the graph a tiny taste of reasoning above. A fuller ontology — written in standards like RDFS or OWL — lets the graph validate new data against rules and infer richer facts automatically, which is essential once you’re merging many messy sources. Pair it with AI. One of the hottest uses today is grounding large language models in a knowledge graph — giving a chatbot a structured, trustworthy backbone of facts so it hallucinates less and can explain why it answered the way it did. A clean ontology makes that backbone far more reliable. Add reasoning. More advanced graphs can infer new facts: if Luna is a Cat and a Cat is an Animal, the graph can conclude Luna is an Animal without being told. But none of that changes the foundation you just learned. A knowledge graph is triples plus the ability to walk between them. Start with eleven facts about Catlin and her cat — the very same moves scale to millions. Stay tuned to my next topic of Ontology…