The Box Beside Your Search Results
Search for "APJ Abdul Kalam" on Google and something interesting happens. Alongside the usual list of blue links, a box appears on the right (or on top, if you are on a phone) with his photograph, a one-line description, his birth date, the schools he studied at, and a short list of awards including the Bharat Ratna. You did not ask for any of this in a special format — you just typed a name — yet Google answered with clean, organised facts instead of a pile of paragraphs you would have to read through yourself.
That box is called a Knowledge Panel, and it is not generated by Google reading web pages at the moment you search. It is pulled, almost instantly, from a giant structure that Google built years earlier by connecting millions of real-world people, places, and things to one another. Google gave this structure a name when it launched the technology in May 2012: the Knowledge Graph. In its original announcement, Google said the Knowledge Graph already held more than 500 million real-world objects and over 3.5 billion facts and relationships connecting them. Much of that seed data traced back to Freebase, an open structured database built by a company called Metaweb, which Google had acquired in 2010.
This chapter is about how that box gets built — how you take scattered facts about the world and turn them into a structure a computer can search, connect, and reason over in a fraction of a second.
Structured vs Unstructured: Why Computers Need Both
Most of the information on the internet is unstructured data — free-flowing text, images, and video that make perfect sense to a human reader but have no fixed shape a program can rely on. A textbook paragraph about APJ Abdul Kalam might read: "Avul Pakir Jainulabdeen Abdul Kalam was born in Rameswaram and later worked at the Indian Space Research Organisation (ISRO) before serving as President of India." A human reads that sentence and instantly extracts several separate facts. A computer, unless it runs sophisticated natural language processing, just sees a string of characters — it has no built-in notion of who was born where, or what "worked at" means as opposed to "served as."
Structured data, in contrast, has a predictable shape. A spreadsheet with columns like Name, Birthplace, and Employer is structured — a program can jump straight to the Birthplace column without reading any prose at all. The trouble with spreadsheets is that real-world knowledge rarely fits neatly into rows and fixed columns. Kalam has a birthplace, but he also has awards (more than one), academic degrees (more than one), and books he authored (more than one). Some entities need dozens of relationship types, others need only two or three, and new relationship types keep appearing as knowledge grows. A knowledge graph is a way of structuring data that keeps the precision of a spreadsheet while staying as flexible as a web of connected facts — which is exactly why it is shaped like a graph rather than a table.
Entities, Relationships, and Triples: The Building Blocks
Every knowledge graph is built from three ingredients.
- An entity is a distinct real-world thing worth naming: a person (APJ Abdul Kalam), a place (Rameswaram), an organisation (ISRO), or even an abstract concept (the Bharat Ratna award). In graph terms, each entity becomes a node.
- A relationship connects two entities and says how they relate — "bornIn," "workedAt," "servedAs." In graph terms, each relationship becomes a directed edge between two nodes. Relationships are sometimes called predicates.
- An attribute is a fact that belongs to a single entity rather than connecting two entities — for example, Kalam's birth date, 15 October 1931, is an attribute of the entity "APJ Abdul Kalam," not a link to another node in the graph.
Put an entity, a relationship, and another entity together, and you get the atomic unit of every knowledge graph: the triple, written as (subject, predicate, object). "Kalam workedAt ISRO" is a triple. So is "Rameswaram locatedIn Tamil Nadu." A knowledge graph, no matter how large, is simply a very large collection of such triples, all connected wherever the same entity appears as the subject of one triple and the object of another.
Direction matters. The triple (Kalam, workedAt, ISRO) is not the same statement as (ISRO, workedAt, Kalam) — organisations do not "work at" people. This is why a knowledge graph is technically a directed graph with labelled edges: every edge has an arrowhead and a name, and both are part of the fact being stored. If you have studied graphs in your data structures unit — nodes and edges used to model networks like road maps or friendship networks — a knowledge graph is that same idea, specialised so that every edge also carries meaning.
Worked Example: Turning Sentences into a Graph
Take these plain-English facts about APJ Abdul Kalam, the kind you might find in a school textbook:
- APJ Abdul Kalam was born on 15 October 1931 in Rameswaram.
- Rameswaram is located in Tamil Nadu.
- APJ Abdul Kalam worked at ISRO.
- ISRO is headquartered in Bengaluru.
- APJ Abdul Kalam served as the 11th President of India.
- APJ Abdul Kalam received the Bharat Ratna.
To convert this into a knowledge graph, walk through each sentence and pull out the subject, the relationship, and the object, normalising each relationship into a single reusable label:
(APJ Abdul Kalam, bornIn, Rameswaram)
(Rameswaram, locatedIn, Tamil Nadu)
(APJ Abdul Kalam, workedAt, ISRO)
(ISRO, headquarteredIn, Bengaluru)
(APJ Abdul Kalam, servedAs, President of India)
(APJ Abdul Kalam, receivedAward, Bharat Ratna)
Notice that "Rameswaram" and "ISRO" each appear twice — once as an object (something Kalam is connected to) and once as a subject (something with its own facts attached). This is exactly what turns a flat list of facts into a connected graph rather than six separate, isolated statements. Drawn out, the structure looks like this:
bornIn locatedIn
Kalam ────────────────────► Rameswaram ────────────────► Tamil Nadu
Kalam ───workedAt───► ISRO ───headquarteredIn───► Bengaluru
Kalam ───servedAs───► President of India
Kalam ───receivedAward───► Bharat Ratna
Six sentences have become one connected shape with four nodes reachable directly from "Kalam," and two more nodes — Tamil Nadu and Bengaluru — reachable one extra step away. That extra step is where knowledge graphs start to earn their keep, as the next section shows.
Representing and Querying a Knowledge Graph in Python
A list of triples is easy to store, but searching through every triple one by one gets slow as a graph grows to millions of facts. A common approach is to build an adjacency structure: a dictionary that maps each entity directly to the list of relationships leading out of it, so looking up everything connected to one entity takes a single dictionary access instead of a full scan.
triples = [
("APJ Abdul Kalam", "bornIn", "Rameswaram"),
("Rameswaram", "locatedIn", "Tamil Nadu"),
("APJ Abdul Kalam", "workedAt", "ISRO"),
("ISRO", "headquarteredIn", "Bengaluru"),
("APJ Abdul Kalam", "servedAs", "President of India"),
("APJ Abdul Kalam", "receivedAward", "Bharat Ratna"),
]
graph = {}
for subject, predicate, obj in triples:
graph.setdefault(subject, []).append((predicate, obj))
def query(entity, relation=None):
facts = graph.get(entity, [])
if relation:
return [obj for rel, obj in facts if rel == relation]
return facts
Trace what happens as the loop runs. Before the loop, graph is an empty dictionary. Each iteration reads one triple and appends a (relation, object) pair under the subject's key:
- After triple 1:
graphbecomes{"APJ Abdul Kalam": [("bornIn", "Rameswaram")]}. - After triple 2: a new key is added,
graph["Rameswaram"] = [("locatedIn", "Tamil Nadu")]. - After triple 3: the existing list grows,
graph["APJ Abdul Kalam"] = [("bornIn", "Rameswaram"), ("workedAt", "ISRO")]. - By the end of the loop,
graph["APJ Abdul Kalam"]holds all four outgoing facts about Kalam, whilegraph["Rameswaram"]andgraph["ISRO"]each hold one fact of their own.
Now run three queries and trace each one:
print(query("APJ Abdul Kalam"))
# [('bornIn', 'Rameswaram'), ('workedAt', 'ISRO'), ('servedAs', 'President of India'), ('receivedAward', 'Bharat Ratna')]
print(query("APJ Abdul Kalam", "bornIn"))
# ['Rameswaram']
birth_city = query("APJ Abdul Kalam", "bornIn")[0]
birth_state = query(birth_city, "locatedIn")[0]
print(birth_state)
# Tamil Nadu
The first call passes no relation argument, so the if relation: check fails and the function returns every fact attached to Kalam, unfiltered. The second call passes "bornIn", so the list comprehension keeps only pairs where rel == "bornIn", leaving the single-item list ['Rameswaram']. The third block is the interesting one: it takes the object returned by the first query, the string "Rameswaram", and feeds it back into query as a brand-new subject. This is a multi-hop query — the answer to "which state was Kalam born in" required walking across two edges, Kalam to Rameswaram and then Rameswaram to Tamil Nadu, even though no triple directly connects Kalam to Tamil Nadu at all. Nothing in the original data ever states "Kalam bornInState Tamil Nadu"; that fact emerges purely from following the graph's structure one step further.
The graph dictionary is fast in only one direction: given a subject, one lookup finds every fact leading out of it. Asking the reverse question — "who received the Bharat Ratna?" — is not something graph can answer directly, because "Bharat Ratna" appears only as an object in this data, never as a key. Answering it means scanning every triple instead:
def find_subjects(relation, obj):
return [s for s, p, o in triples if p == relation and o == obj]
print(find_subjects("receivedAward", "Bharat Ratna"))
# ['APJ Abdul Kalam']
find_subjects walks the original triples list and unpacks each tuple into s, p, and o, keeping only the subject when both the predicate and the object match. With six triples, scanning all of them is instant. A production knowledge graph with billions of triples cannot afford to scan everything for every reverse question, so real graph databases build a second index running object-to-subject as well as subject-to-object — the same trade-off computer scientists make when choosing a doubly linked list over a singly linked list: extra memory spent up front in exchange for fast traversal in both directions later.
Multi-Hop Reasoning: Why the Graph Shape Matters
Multi-hop traversal is the single biggest reason knowledge graphs exist instead of everyone just using spreadsheets or relational database tables. In a traditional relational database, answering "which state was Kalam born in" when birthplace and state live in two different tables requires a join — matching a foreign key in one table against a primary key in another. One join is manageable. But real questions often need several hops: "Which recipients of the Bharat Ratna also worked at an organisation headquartered in Bengaluru?" needs three or four joins chained together, and every additional join in a relational database tends to make the query slower and harder to write correctly.
A graph handles the same question by simply walking edges: start at every node connected by a receivedAward edge to "Bharat Ratna," follow each one's workedAt edge, then check whether that organisation has a headquarteredIn edge pointing to "Bengaluru." The number of hops can grow without the underlying operation changing — it is still "follow the next labelled edge" at every step, which is exactly what specialised graph databases are optimised to do quickly even across millions of nodes.
This flexibility comes with a companion concept called an ontology — essentially a schema for a knowledge graph, defining which relationship labels are allowed and which types of entities they can connect (a bornIn edge should go from a person to a place, not from a place to an award). Large knowledge graphs use an ontology to keep millions of contributors and automated extraction pipelines consistent, so that "born in" and "place of birth" do not end up as two different, disconnected relationship types describing the same idea.
How the Real World Builds Knowledge Graphs
The triple format used in this chapter is not just a teaching simplification — it mirrors the Resource Description Framework (RDF), a World Wide Web Consortium standard for representing knowledge graph data as subject-predicate-object statements so that data published by different organisations can be linked together. Large RDF knowledge graphs are commonly queried using SPARQL, a query language purpose-built for pattern-matching across triples, in much the same way SQL is purpose-built for querying relational tables.
Search engines also collect facts more directly, straight from the pages that publish them. schema.org is a shared vocabulary of entity types and properties launched jointly by Bing, Google, and Yahoo in June 2011, with Yandex joining soon after, so that website owners could mark up their own pages with structured tags using a common, agreed set of names. A recipe page can label its ingredient list and cooking time; a bookshop's product page can label a book's author, price, and availability. When a search engine reads that markup, it does not need to guess the facts out of prose at all — the page has already handed over ready-made triples that can be merged straight into the graph.
Not every system uses the RDF triple format directly. Many production knowledge graphs, especially inside companies, are stored as property graphs, where nodes and edges can carry multiple attributes directly (an edge might store not just "workedAt" but also a start year and an end year), and are queried with graph-native languages rather than SPARQL. Graph databases such as Neo4j popularised this style.
One of the largest openly editable knowledge graphs in the world is Wikidata, launched in 2012 as a sister project to Wikipedia within the Wikimedia movement. Anyone can add or correct structured facts on Wikidata — including facts about Indian cities, freedom fighters, festivals, and scientists — and those facts can flow into Wikipedia infoboxes across many language editions, including Hindi, Tamil, Bengali, and other Indian-language Wikipedias, whenever a local article is set up to pull from Wikidata. It is a useful place to see the entity-relationship-triple model of this chapter operating at real-world scale, built by volunteers rather than a single company.
Where This Leads
Knowledge graphs stored as clean triples are powerful for exact lookups, but real knowledge is full of gaps — a graph might know Kalam's birthplace but be missing an entry for a newly built research institute, or a relationship someone simply never got around to adding. A more advanced technique, which you will encounter as you go further into machine learning, is the knowledge graph embedding: training a model to represent every entity and relationship as a list of numbers (a vector) positioned in space so that patterns among existing triples can help predict plausible missing ones. That is a topic for a later, more advanced chapter — the graph-of-triples model covered here is the foundation everything else is built on top of.
What you can already do with the ideas in this chapter is significant. Search engines use knowledge graphs to answer factual questions directly instead of just linking to pages. Voice assistants use them to answer questions like "who was India's 11th president" or "when was Kalam born" by looking up a stored fact instead of searching the open web at query time. Shopping and streaming platforms use graph-shaped data to connect customers, products, and past purchases so that recommendations can follow multi-hop patterns like "people who bought this also bought that." Banks and payment platforms lean on graph analysis for fraud detection, since a fraud ring often shows up not as one suspicious transaction but as an unusual pattern of connections between accounts — exactly the kind of structure a graph is built to reveal.
The next time a Knowledge Panel appears beside your search results, you know what is happening underneath it: somewhere in a data centre, your query matched an entity node, and the panel you see is simply that node's outgoing edges — bornIn, servedAs, receivedAward — rendered as a photograph and a few tidy lines of text. Six sentences turned into a graph earlier in this chapter using nothing more than a pen and a table; Google's Knowledge Graph is the same idea, built out to hundreds of millions of entities and billions of edges.
Think About It
Think about this: How would you explain knowledge graphs: structured information to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.
Practice Exercises
Now it is time to practice! Complete these challenges to solidify your understanding:
- Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
- Exercise 2: Find a real-world example where knowledge graphs: structured information is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
- Exercise 3: Create a mind-map connecting knowledge graphs: structured information to at least 3 other topics you have studied.
Key Takeaways — Summary and Recap
Let us recap what we covered: the core ideas behind knowledge graphs: structured information, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.