—

Natural Language Processing

Knowledge Graphs and Semantic Web

Published: 2026-08-02

Level: postgraduate

Audience: Postgraduate students in Natural Language Processing

Prerequisite Knowledge

This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.

Previously Covered in This Subject

Word sense disambiguation — covered in Lecture 12 (introduction, lexemes, WordNet, SemCor, the supervised and Lesk approaches that this session recaps).
Supervised machine learning for WSD — covered in Lecture 12 (Naive Bayes, k-nearest neighbours as sense classifiers).
Word embeddings and contextual representations — covered in Lectures 3 and 11 (distributional semantics and contextual embeddings that drive vector-similarity Lesk and automatic KG construction).

13.1 Word Sense Disambiguation — Recap

This section recaps the word sense disambiguation (WSD) material from the previous session. The recap follows two threads — supervised machine learning for WSD and the knowledge-based Lesk algorithm — and it prepares the ground for the rest of this session: once we can pin down the meaning of individual words, we can start connecting those meanings into structured knowledge graphs.

13.1.1 Machine Learning Algorithms for WSD

Hook: You type "bank" into a search engine. Did you mean a place to keep money, or the edge of a river? A human decides in a fraction of a second. How can a machine make the same call?

Natural language is inherently ambiguous — many words carry more than one meaning. Any NLP application, whether conversational AI, question answering, or text generation, must understand the text before it produces output, and understanding starts with resolving ambiguity. Word sense disambiguation (WSD) is the task of determining which meaning of a word is intended in a given context.

This topic was covered in detail in the previous session, where we saw supervised classifiers, WordNet, and the SemCor corpus. The recap below keeps the essentials and adds the specific examples you need for the exam. The word "bank" appears near deposits and mortgage in one text and near river and sloping land in another — these different neighborhoods are exactly the signal a classifier uses.

WSD as supervised classification. When WSD is framed as a machine learning problem, each distinct sense of a word becomes a class label. The task is so a multi-class classification problem: given the context around a target word, pick one sense out of the candidate list.

The formal framing. Let the target word \(w\) have \(K\) candidate senses \(s_1, s_2, \dots, s_K\). The context of \(w\) is the window of surrounding words \(C = (c_{-m}, \dots, c_{-1}, c_{+1}, \dots, c_{+m})\). A supervised classifier learns a function that maps features derived from \(C\) to the correct sense label:

\[ \hat{s} = \arg\max_{s \in \{s_1, \dots, s_K\}} P(s \mid \text{features}(C)) \]

Here \(P(s \mid \text{features}(C))\) is the probability the classifier assigns to sense \(s\) given the context features, and \(\hat{s}\) (read "s-hat") is the chosen sense. Any standard classification algorithm can serve as the learner: Naive Bayes classifiers, Support Vector Machines (SVMs), and feedforward neural networks all apply.

The critical prerequisite is feature engineering — the model needs informative features extracted from the context surrounding the target word. Typical features include:

the part-of-speech (POS) tag of the target word,
the preceding word (and its POS tag),
the following word (and its POS tag),
other surrounding context words inside the window.

These contextual features provide the signal the classifier needs to distinguish between senses. For the word "bank", the features around "deposits" and "mortgage" look nothing like the features around "river" and "sloping land", so a model trained on enough examples learns to associate each feature pattern with the right sense.

Pitfalls in the supervised approach:

Feature sparsity. Each sense of each word has few training examples, so most feature combinations never appear in training. Backing off to more general features (part-of-speech tags instead of exact words) helps.
Rare senses. Senses that appear rarely in the training corpus get little evidence and are often drowned out by the most common sense.
Sense inventory mismatch. Different corpora may label senses differently; the classifier only learns the inventory it was trained on.
Unseen words. A supervised model cannot disambiguate a word it never saw during training — this is the motivation for knowledge-based methods such as Lesk.

The same WSD machinery shows up across industry: search engines decide which meaning of a query word is intended, machine translation systems pick the right target-language word, and voice assistants resolve words like "bat" or "bank" before answering.

13.1.2 The Lesk Algorithm

Purpose. The Lesk algorithm is a knowledge-based approach to WSD: it needs no labeled training data at all. It relies only on a dictionary or a corpus of definitions — typically WordNet — plus the sentence in which the target word appears. It exists because labeled sense data is expensive to produce, while dictionaries are freely available.

The core idea is simple: compute the overlap between the words in the current sentence context and the definition (gloss) and usage examples of each possible sense of the target word, then select the sense with the greatest overlap. The intuition is that a sense definition that shares words with the surrounding context is almost certainly the intended meaning — definitions and contexts about the same thing naturally use the same vocabulary.

Inputs and outputs. The inputs are: the target word \(w\), the sentence (or window) containing \(w\), and a dictionary (WordNet, Wikipedia, or a domain-specific corpus) that lists the candidate senses of \(w\), each with its gloss and example sentences. The output is the single sense \(s^*\) that maximizes the overlap.

Algorithm steps:

Initialize the best sense as the most frequent sense of the word (see the heuristics in Section 13.1.3).
For each sense of the target word in the dictionary:

Collect the signature of that sense — the set of words in its gloss and its example sentences.
Compute the overlap between the signature and the set of context words from the test sentence. The overlap can be a simple count of shared words (string matching) or a vector similarity score using word embeddings.

Select the sense with the maximum overlap as the correct sense.

This version, which compares the target word's signature directly against the context, is called Simplified Lesk. The original Lesk algorithm (Lesk, 1986) instead compares the signature of the target word against the signatures of each context word, and the Corpus Lesk variant adds inverse document frequency weighting — both are discussed in Section 13.1.4.

Worked example: "bank" in a financial sentence. Consider the sentence used in the lecture:

The bank can guarantee deposits will eventually cover future tuition costs because it invests in adjustable-rate mortgage securities.

The context word set is:

\[ C = \{\text{bank, guarantee, deposits, cover, future, tuition, costs, invests, adjustable, mortgage, securities}\} \]

Function words such as the, can, will, because, in, rate are dropped (or equivalently down-weighted). WordNet lists two dominant senses for "bank":

bank₁ — gloss: "a financial institution that accepts deposits and channels the money into lending activities"; examples: "he cashed a check at the bank", "that bank holds the mortgage on my home".

Signature words: financial, institution, accepts, deposits, channels, money, lending, activities, cashed, check, holds, mortgage, home.

bank₂ — gloss: "sloping land (especially the slope beside a body of water)"; examples: "they pulled the canoe up on the bank", "he sat on the bank of the river and watched the currents".

Signature words: sloping, land, slope, beside, body, water, pulled, canoe, sat, river, watched, currents.

Now count the overlap with the context set \(C\):

bank₁ signature \(\cap\ C\) = {deposits, mortgage} → overlap = 2
bank₂ signature \(\cap\ C\) = {} → overlap = 0

The sense with the maximum overlap is bank₁ (the financial institution sense), winning 2 to 0.

Sense-check: the sentence talks about deposits, tuition costs, and mortgage securities — a banking context, not a riverbank scene. The algorithm's verdict matches our intuition, so the result is believable.

This is why the lecture listed the context words guarantee, deposits, tuition, fees, cost, investments, and mortgage: together they point strongly to the financial institution sense. If the context instead contained river, sloping land, or body of water, the algorithm would select the riverbank sense.

When to use Lesk — and where it breaks:

Use it when no labeled data exists for the domain, or as a strong unsupervised baseline.
Short glosses are a weakness. Dictionary entries are short, so the chance of overlap with the context is small. Corpus Lesk (Section 13.1.4) fixes this by adding sense-tagged corpus sentences to the signature.
String matching is brittle. It cannot see that "investments" and "investing" belong to the same family, and it cannot match synonyms at all — vector similarity solves this.
Cost. A single word is cheap to disambiguate (a few set intersections), but processing an entire document word by word is slow without the discourse heuristics below.

13.1.3 Heuristics for WSD

Two practical intuitions are commonly used when data-driven disambiguation fails, or as initialization:

Most frequent sense. In WordNet, senses are ordered by frequency in a standard corpus (such as SemCor). The first sense listed is typically the most common meaning. When no contextual evidence distinguishes the senses, defaulting to the most frequent sense is a strong baseline. For example, if the word "bat" appears in a context where the sense cannot be determined, the most frequent sense is selected — a cricket bat, not a mammal.

One sense per discourse. Within a single document or article, a given word typically maintains the same sense throughout. If "bank" is used in the financial sense early in an article, subsequent occurrences of "bank" in the same article almost certainly carry the same financial meaning. This heuristic lets an early disambiguation decision propagate through the rest of the document.

Heuristic	What it assumes	Role in practice
Most frequent sense	The corpus frequency order matches everyday usage	Strong baseline; right surprisingly often
One sense per discourse	Word senses stay stable inside one document	Turns word-by-word decisions into document-level decisions

Pitfalls:

The most frequent sense is a baseline, not a guarantee — for ambiguous words it can be wrong a large fraction of the time, especially in specialized domains where the rare sense is actually the intended one.
One-sense-per-discourse breaks at discourse boundaries: a newspaper that quotes a biologist and a cricketer in the same article can use "bat" in both senses.
The two heuristics work best combined — initialize with the most frequent sense, then let discourse evidence override it as soon as the context is informative.

13.1.4 Modern Extensions of Lesk

The original Lesk algorithm used plain string matching. Today's implementations use several advances:

Vector similarity. Word embeddings (Word2Vec, GloVe) or contextual embeddings (BERT) replace raw string matching. Instead of counting identical words, the system computes the cosine similarity between the embedding of the context and the embedding of each sense gloss, so "investments" and "investing" contribute even though the strings differ.
Attention mechanisms. Attention weights the contribution of different context words differently — a word right next to the target gets more weight than a distant one, and stop words get almost none.
Expanded knowledge sources. Instead of only WordNet definitions, modern approaches use Wikipedia pages, domain-specific glossaries, or large-scale corpora as the reference for sense definitions.

One textbook variant, Corpus Lesk, extends the signature of each sense with all the words from sense-tagged corpus sentences (for example, from SemCor) and weights each overlapping word by its inverse document frequency:

\[ idf_i = \log\frac{N_{doc}}{n_{d_i}} \]

where \(N_{doc}\) is the total number of documents (glosses and examples) and \(n_{d_i}\) is the number of these documents that contain word \(i\). Function words such as "the" appear in almost every document, so their IDF is low; content words such as "deposits" have high IDF, so the weighting automatically demotes stop words and rewards informative matches.

Method	Similarity measure	Strength
Simplified Lesk	shared-word count (string)	Simple, interpretable
Original Lesk	signature-to-signature comparison	Handles indirect evidence
Corpus Lesk	IDF-weighted overlap	Best-performing Lesk variant
Vector / attention Lesk	embedding similarity	Handles synonyms and morphology

Recap: WSD chooses a word's intended sense, either by supervised classification on engineered context features or by matching the context against sense definitions (Lesk). What has changed over the years is the quality of the similarity measure and the richness of the knowledge source — the fundamental intuition remains the same.

Bridge to this session: notice that WordNet is itself a structured resource: senses are ordered, related to each other, and defined by glosses. That structure is one step away from a full ontology. The rest of this session asks a bigger question — can we make machines understand and connect meanings at web scale? That is exactly the problem the Semantic Web and knowledge graphs were invented to solve.

---

13.2 The Semantic Web Vision

This section introduces the vision behind the Semantic Web: a web in which machines can understand the meaning of data, not just render it. We look at why the traditional web falls short, the data challenges of the modern era, and how converting heterogeneous data into graphs makes complex cross-domain queries possible.

13.2.1 From Syntactic Web to Semantic Web

Hook: You type "my mouse is broken and I need a new one" into a search engine. A human instantly knows you need a computer peripheral. To a machine, "mouse" is just five characters: m-o-u-s-e. A purely syntactic system might suggest an exterminator — or a pet shop.

The Semantic Web is a concept introduced by Tim Berners-Lee, the same person who invented the World Wide Web. Before the Semantic Web, the web was purely syntactic — pages were connected via HTTP links and URLs, but machines could not understand the meaning of the content within those pages. HTML tells a browser how to display text — make this bold, make that a heading — but it tells the machine nothing about what the text actually means or how the entities in it relate to each other in the real world.

Two kinds of web.

Syntactic Web (Web 1.0): a web of documents for people. Machines render, link, and retrieve pages, but they do not interpret the content.
Semantic Web: a web of data for machines. Data is defined and linked in a way that lets machines integrate, automate, and reason over information globally.

Berners-Lee's vision: the Semantic Web is the bridge between human-readable content and machine-processable knowledge.

This limitation has practical consequences. A purely syntactic system operating on string matching alone cannot answer "animals that use sonar but are neither bats nor dolphins" — it needs to understand that the user means barn owls or similar creatures, an inference that depends on semantics, not keywords.

Worked example: the sonar query. Query: "animals that use sonar but are neither bats nor dolphins."

Keyword-search path (syntactic web): the engine looks for pages containing the strings "animals", "sonar", "bats", "dolphins". The top hits are pages about bats and dolphins — the very animals the user excluded. The result is misleading because string matching cannot apply the exclusion.

Semantic path (semantic web): the system recognizes the query structure — a class of things (Animal), a property (uses sonar), and two exclusions (not Bat, not Dolphin). It then applies background knowledge:

The animal kingdom set known to use sonar: {bats, dolphins, barn owls, oilbirds, swiftlets, some shrews} → 6 known groups.
Remove the excluded groups: bats and dolphins → 2 groups removed.
Remaining set: {barn owls, oilbirds, swiftlets, some shrews} → 4 candidate groups.

Final answer: barn owls, oilbirds, swiftlets, and a few shrew species — with the keyword path, this answer was unreachable; with semantic understanding, it falls out of one class-exclusion step.

Sense-check: keyword search answers "what pages contain these words", while the semantic path answers "which entities satisfy these conditions" — a different question, and the one the user actually asked.

Where the syntactic web breaks:

No inference. String equality is not meaning: "mouse" (animal) and "mouse" (peripheral) look identical to a matcher.
No relations. A page that says "Pilani is in Rajasthan" and a page that says "BITS is in Pilani" cannot be joined by a search engine, even though the connection is one hop of reasoning away.
No integration. Data in different formats, languages, and locations stays disconnected, so complex multi-source queries are impossible.

13.2.2 Data Challenges in the Modern Era

Even today, several fundamental challenges motivate the need for semantic technologies:

Data in silos. Data is distributed across multiple locations and stored in multiple formats. In the medical domain, for example, knowledge within a single hospital exists in various formats and is not connected. Professionals spend significant time understanding what data is available, how to interconnect it, and how to make sense of it. An Excel sheet on a government website cannot natively "talk" to a relational database in a hospital.

Heterogeneous formats. Data exists as databases (SQL), CSV files, Excel spreadsheets, PowerPoint presentations, PDFs, video files, audio files, images, and plain text. Integrating these formats is a major challenge.

Implicit semantics. The meaning of data is not always explicit. Machines cannot automatically infer relationships between entities unless those relationships are formally encoded. Today's reasoning systems are beginning to address this, but it remains a barrier.

Background knowledge requirements. Connecting pieces of information often requires background knowledge that may not be readily available in the dataset itself.

Data quality. Distinguishing high-quality data from garbage, spam, or noise is difficult to automate.

Proprietary schemas. Some data uses proprietary schemas that may not be released in open-source environments, creating gaps between systems.

Unstructured data. A large fraction of real-world data is unstructured — video, audio, images, text, PDFs, CSVs — making automated processing difficult.

Ambiguity in natural language. Words with multiple meanings (the core WSD problem from Section 13.1) create barriers to connecting information across documents.

Multilinguality. In India alone, there are 22 constitutional languages, each carrying significant knowledge. Connecting information across languages is a substantial challenge.

Scale. Managing data at terabyte scale across all these dimensions compounds every individual challenge.

Challenge	Example	Why it blocks machines
Silos	Hospital data vs. government Excel sheets	No agreed connection points
Heterogeneous formats	SQL, CSV, PDF, video, audio	Every format needs a different reader
Implicit semantics	A column named "DOB"	Nothing says it means date of birth
Multilinguality	22 Indian constitutional languages	Names and relations differ per language
Data quality	Spam, noise, duplicates	Machines cannot tell good data from garbage

Scope note. These challenges are not solved by a single tool. The Semantic Web stack (Section 13.5.5) is one integrated answer: URIs give every thing an identity, RDF gives every fact a structure, and ontologies give every concept a shared definition. Each layer answers one row of the table above.

13.2.3 Interconnecting Heterogeneous Data

The core question is: how can we interconnect pieces of information that exist in different formats, languages, and locations so that machines can make sense of them?

Semantic Web technologies answer this by converting heterogeneous data into a graph structure where entities are nodes and relationships are edges. This graph structure allows machines to traverse connections, infer new relationships, and answer complex queries that span multiple data sources. The aspiration is to treat the entire web as a database where all important pieces of information are interconnected and noise-free.

Worked example: the Obama query. Query: "What were the most popular songs when Obama was elected?"

This question requires joining three datasets that live in three different formats:

Song data (music charts, e.g., Billboard's Hot 100): ranked songs with their peak dates — stored as a relational table.
Political data (election records): the date Obama won the 2008 US presidential election — November 4, 2008 — stored in a news or government dataset.
Historical/calendar data: the chart week containing that date — the week of November 8, 2008.

Steps in a knowledge-graph-backed system:

Step 1 — identify entities: {song, election, date}.
Step 2 — join on the shared key (the date): the chart week = week of November 8, 2008.
Step 3 — query the song graph restricted to that week, ordered by chart position:

The answer from the graph: "Whatever You Like" by T.I. was the #1 song on the US Billboard Hot 100 the week Obama was elected (November 2008); Beyoncé's "Single Ladies (Put a Ring on It)" took the top spot the following month.

Sense-check: a purely keyword system returns pages about "Obama" or pages about "songs" but cannot combine them. The graph joins three datasets on shared identifiers, so the answer requires no human stitching — which is exactly the point.

Today's AI systems can even generate the query language (SQL, SPARQL, or similar) automatically from natural language — but the prerequisite is integrated data. Without the graph, there is nothing to query.

Recap: the Semantic Web extends the document web with meaning: entities get identities, facts get structure, and machines can reason across data silos.

Bridge to Section 13.3: the mechanism that makes this concrete is the knowledge graph — a graph of entities and relations that the machine can traverse and query. We now look at what a knowledge graph is, and how one is built.

---

13.3 Knowledge Graphs — Core Concepts

This section introduces the knowledge graph — the working mechanism of the Semantic Web. We build one from a simple book example, understand how unique identifiers make data linkable, see how external sources such as DBpedia enrich a graph, and finish with the Graph RAG applications that make knowledge graphs central to modern industry systems.

13.3.1 Building a Knowledge Graph: Book Example

A knowledge graph is, in simple terms, an ontology populated with instances (the ontology idea is formalized in Section 13.4). It represents real-world entities, their properties, and the relationships between them in a graph structure: entities are nodes, and relationships are labeled edges.

To build intuition, consider a book — say, The Glass Palace by Amitav Ghosh. A typical book has an ISBN number, an author, a title, a publisher, and a publication date. The author may have a homepage. The publisher may have a location and its own homepage. All of these pieces of information can be interconnected via the ISBN number as the unique identifier.

Worked example: the book graph. Entities (nodes): the book, the author, the publisher, the author's homepage, the publisher's location. Edges (labeled relations):

The Glass Palace —written by→ Amitav Ghosh
The Glass Palace —published by→ HarperCollins (publisher)
Amitav Ghosh —has homepage→ http://amitavghosh.com (illustrative URL)
HarperCollins —located in→ New York
HarperCollins —has homepage→ http://harpercollins.com (illustrative URL)

A visual sketch of the graph:

            [Amitav Ghosh] ──has homepage──▶ [http://amitavghosh.com]
                 ▲
                 │ written by
                 │
[The Glass Palace] ──published by──▶ [HarperCollins] ──located in──▶ [New York]
                                         │
                                         └────has homepage────▶ [http://harpercollins.com]

Now traverse the graph to answer queries:

"What other books has this author written?" — start at the author node, follow the inverse of "written by" → all books of Amitav Ghosh.
"Where is the publisher located?" — start at the publisher node, follow "located in" → New York.
"What is the author's homepage?" — follow "has homepage" → the URL.

Final answer for each query is one hop across a labeled edge — and none of these answers requires reading the book's text.

Sense-check: the graph stores facts, not prose. Every question above was answered by following edges, which is exactly what machines can do reliably — unlike reading paragraphs.

By traversing these connections, a system can answer the same complex queries in a fraction of a second. The power comes from the structure: the graph does not store an answer per question, it stores facts that combine into any number of answers.

13.3.2 URIs and Unique Identifiers

Every entity in a knowledge graph requires a unique identifier. Just as the syntactic web uses URLs (HTTP addresses) to identify pages, the Semantic Web uses URIs (Uniform Resource Identifiers) or IRIs (Internationalized Resource Identifiers) to identify entities.

What each term means.

URL (Uniform Resource Locator): an address that also tells you how to retrieve the resource, e.g., http://example.com/ian. The web already uses these for pages.
URI (Uniform Resource Identifier): a global name for an entity, e.g., http://example.com/people/ian. It identifies the thing, not a page about the thing.
IRI (Internationalized Resource Identifier): a URI that allows non-ASCII characters (for example, names written in Devanagari or Arabic scripts).

Some URIs are standardized by the World Wide Web Consortium (W3C) for common entities — for example, the foaf:Person vocabulary for people. For enterprise-level applications, custom URIs can be defined for proprietary data.

These unique identifiers enable interoperability — data from different sources can be linked when they share or reference the same URI. Two databases that agree to identify the same book by the same URI (say, its ISBN) can be merged by a machine in one step, because the machine sees that both records point to the same entity.

Pitfalls in identification:

Local strings are not identities. If dataset A writes "Amitav Ghosh" and dataset B writes "Ghosh, Amitav", a machine sees two different strings and two different people. Only a shared URI unifies them.
Same name, different things. "Spring" (season), "Spring" (company), and "Spring" (water source) must get different URIs, or the graph merges unrelated entities.
One thing, many names. A translated book still has one identity — which is why identifiers, not titles, are the join key.

13.3.3 Expanding with External Knowledge (DBpedia)

A knowledge graph built from internal data can be expanded by connecting it to external structured knowledge bases. The most prominent example is DBpedia, which extracts structured information from Wikipedia info boxes — the formatted tables that appear on the right side of Wikipedia articles.

Wikipedia info boxes contain structured data about entities: birth dates, locations, occupations, and so on. The DBpedia project converts this structured information into an ontology format with unique identifiers, making it machine-readable and linkable. By connecting an internal knowledge graph to DBpedia via shared URIs, the graph can be enhanced with external information such as author homepages, geolocations, and temporal data.

Worked example: linking to DBpedia. Suppose the book graph from Section 13.3.1 has an author node for Amitav Ghosh but no details about him. DBpedia publishes structured facts extracted from Wikipedia's info box on Amitav Ghosh:

dbpedia:Amitav_Ghosh —birth date→ 1956-07-11
dbpedia:Amitav_Ghosh —occupation→ novelist, professor
dbpedia:Amitav_Ghosh —alma mater→ Delhi University

If the internal graph uses the same URI (dbpedia:Amitav_Ghosh) for its author node, the machine can merge the two graphs in one step. Now a query "when was the author of The Glass Palace born?" is answerable — the information was never in the internal data; it came from an external source reached through a shared URI.

Expansion continues indefinitely: each new external source adds more nodes and edges. The graph can also handle multilingual information — if the book is translated into French, the graph connects the English and French records through the shared book identifier.

Note on translations: the professor's example treats the translated book as sharing the same ISBN. In real publishing, translations receive their own ISBNs, so practical graphs connect the editions with a dedicated relation (for example, "translation of" linking Le Palais des Miroirs back to The Glass Palace) — either way, a shared identifier or an explicit relation is what lets a machine join the two records.

Sense-check: the enrichment took zero new typing from us — the data was already structured on Wikipedia; the graph merely pointed to it.

13.3.4 Graph RAG and Applications

Knowledge graphs serve as the foundation for Graph Retrieval Augmented Generation (Graph RAG), one of the most popular techniques used in industry today.

How Graph RAG works.

Textual content from documents is converted into a knowledge graph — entities and relationships extracted automatically (Section 13.6 shows how).
When a user asks a question, the system queries the knowledge graph to retrieve relevant context.
The retrieved context is fed to a language model to generate an answer grounded in that context.

This approach differs from naive RAG (which uses vector stores for similarity search over text chunks) and from agentic RAG (which uses autonomous agents). Graph RAG is particularly effective when the information is interconnected and the answer requires traversing multiple relationships — exactly what the book-graph queries above showed.

Variant	Retrieval mechanism	Best when
Naive RAG	Vector similarity over text chunks	Facts live in single passages
Graph RAG	Traversal over a knowledge graph	Answers require multiple hops across entities
Agentic RAG	Autonomous agents with tools	Complex, multi-step research tasks

Q: How is a knowledge graph different from a Graph Neural Network?

A: They are entirely different concepts. A Graph Neural Network (GNN) is a type of neural network that operates on graph-structured data — it learns representations by passing messages between nodes. A knowledge graph is a structured representation of factual knowledge — entities and relationships. You can apply GNN techniques to a knowledge graph, but the two concepts are independent. Google's search system, for example, uses a knowledge graph in the background, not a GNN.

The professor next fielded a question about graph databases.

Q: Is Neo4j related to knowledge graphs?

A: Yes. Neo4j is an open-source tool (with commercial versions) for storing, creating, and querying graphs. It is analogous to how Oracle is a tool for relational databases — you create databases, query them, and extract information. Neo4j does the same for graph-structured data. It can store knowledge graphs, query them using the Cypher query language, and visualize the results.

The conversation continued with a question about Google's public graph projects.

Q: Is Google Open Knowledge Graph related to this concept?

A: Yes. Google was a pioneer in building knowledge graphs for search. Google's Knowledge Graph is a massive structured knowledge base that powers the information panels you see in Google search results. It is accessible via an API and stores knowledge in a graph format. Today, all major search companies — Google, Microsoft, and others — use knowledge graphs as a backend for their search systems.

Applications built on top of knowledge graphs include question answering systems, conversational AI, enterprise resource planning (ERP) systems, and database management tools. The knowledge graph acts as a unified, machine-readable knowledge base that any application layer can query — the same graph serves search, recommendation, and chat.

Recap: a knowledge graph is a graph of entities and labeled relations, held together by unique identifiers (URIs) and expandable through external sources such as DBpedia. It is the retrieval backbone of Graph RAG and of search systems at every major company.

Exam note: the connection between knowledge graphs and Graph RAG is an important application-level concept — be ready to explain how a graph is built from text, queried, and used to ground a language model's answer.

---

13.4 Ontologies

This section defines ontologies — the formal vocabularies that give a knowledge graph its structure. We unpack the definition, walk through each component with a worked elephant example, clarify the boundary between an ontology and a knowledge graph, and survey the tools used to build ontologies.

13.4.1 Definition and Philosophical Foundation

Hook: A hospital database has a column called "DOB", a spreadsheet has "date of birth", and a research paper says "birthdate". Three names, one meaning. How does a machine ever agree on what it is looking at? The answer is an ontology — a shared, formal agreement about what the world contains.

An ontology is a philosophical concept adapted for computer science — the word comes from philosophy, where ontology is the study of what exists. In the real world, everything — trees, plants, laptops, people — can be represented as an entity or concept. An ontology formally specifies all the entities in a particular domain, the relationships among them, and the logical conditions (axioms) that govern those relationships.

Formal definition: an ontology is a formal, explicit specification of a shared conceptualization. Breaking this down:

Formal: Expressed in a machine-readable language with precise syntax — logic, not prose.
Explicit: Every concept, relationship, and constraint is explicitly stated, not implied.
Shared: All teams using the ontology must have a consensus about what it represents — the hospital and the spreadsheet must agree.
Conceptualization: It is a model of the concepts in a particular domain, not a model of specific data.

The definition in one line. An ontology answers, for one domain: what things exist, how they relate, and what rules hold. It is restricted to a particular domain. For an academic institution, the ontology would include concepts like faculty, students, courses, degrees, and research areas. For a medical domain, it would include diseases, symptoms, treatments, and anatomical structures. The key requirement is that each entity has a unique, unambiguous meaning within its context.

A useful analogy is to databases: just as a database schema defines tables, columns, and relationships, an ontology defines concepts, properties, and relationships — but with richer logical expressiveness including axioms and reasoning capabilities.

Professor's analogy — ontology is like a database schema. A database schema tells you which tables exist (students, courses, enrollments), which columns each table has (name, email, course_id), and how tables reference each other. An ontology does the same for concepts: it declares the classes (Student, Course), the properties (name, email), and the relations (enrolled in). The difference is that the ontology is expressed in a logical language, so it can also state rules — "a student must be enrolled in at least one course" — which a database schema cannot express. Schema without data is structure; ontology without instances is the same thing.

13.4.2 Components of an Ontology

An ontology consists of several key components:

The five building blocks.

Classes (also called concepts or entities). These are the key categories in the domain. Different tools may use different terms — "classes," "concepts," or "entities" — but they refer to the same idea. Examples: faculty, student, course, elephant, herbivore.

Properties (attributes). Each class may have properties that describe it. For a person class, properties might include name, email, homepage. These are analogous to columns in a database table.

Relations. Relationships connect classes to each other. Relations can be directional. Examples: is a type of (elephant is a type of animal), is a (adult elephant is a type of elephant), eats (elephant eats plants).

Axioms (restrictions or rules). Logical conditions that must be satisfied. Axioms are primarily expressed in OWL ontologies (Section 13.5.3); RDF and XML formats do not support them.

Instances (individuals). Specific real-world examples of classes. For the faculty class, instances might be specific people. For the course class, instances might be specific course names.

Axioms in action. Examples of axioms from the lecture:

An elephant is classified as an adult elephant if its weight is greater than or equal to 2,000 kg.
If an animal is a herbivore, it cannot be a carnivore (disjoint relationship).
An Indian elephant cannot be an African elephant (disjoint condition).
A student opting for a specialization must take at least three courses from that pool of electives (cardinality restriction).
A student taking a course from one bucket cannot take another course from the same bucket (exclusion constraint).

Worked example: the elephant ontology. Classes: Animal, Elephant, Adult Elephant, Herbivore, Carnivore, Indian Elephant, African Elephant. Properties: weight (in kg), eats (plants or meat).

Relations and axioms:

Elephant ⊑ Animal ("elephant is a type of animal") — the subclass relation.
Adult Elephant ⊑ Elephant, with the rule: instance \(x\) is an Adult Elephant if \(x\)'s weight \(\ge\) 2,000 kg.
Herbivore and Carnivore are disjoint — no animal can be both.
Indian Elephant and African Elephant are disjoint — an instance cannot belong to both classes.

Now add an instance: Raja, an elephant with weight = 2,400 kg, who eats plants.

Step-by-step classification:

Weight check: 2,400 kg \(\ge\) 2,000 kg → Raja is an Adult Elephant (the threshold axiom fires).
Diet check: eats plants → Raja is a Herbivore.
Disjointness check: since Raja is a Herbivore, and Herbivore ⊥ Carnivore, Raja cannot be a Carnivore — the reasoner rejects any statement saying otherwise.
Species check: if the graph also says Raja is an Indian Elephant, then Raja cannot be an African Elephant — another disjointness rule.

Final classifications: {Adult Elephant, Herbivore, Indian Elephant}, and the two negative conclusions follow from axioms alone.

Sense-check: each conclusion came from a rule (threshold, disjointness) applied to a fact (weight, diet). This is reasoning — the property that makes an ontology more than a list of classes.

Pitfalls in designing axioms:

Axioms need the right language. RDF and XML cannot express rules — the elephant threshold and the disjointness conditions above require OWL (Section 13.5.3). Trying to enforce them in plain RDF silently fails.
Over-constraining. An axiom that is too strict (e.g., "every elephant weighs at least 1,000 kg") rejects valid instances and breaks the graph's usefulness.
Under-constraining. Without disjointness, a reasoner cannot detect contradictions — a "herbivore carnivore" instance sails through unnoticed (see Section 13.7.3).
Confusing threshold rules with beginner rules. The 2,000 kg axiom is a domain rule about classification, not a coding rule — it belongs in the ontology's axioms, not in an application's code.

Instances are optional. An ontology may or may not include instances — instances are not mandatory. An ontology without instances defines only the structure (classes, properties, relations, axioms). An ontology populated with instances is called a knowledge graph.

13.4.3 Ontology vs Knowledge Graph

The distinction is simple:

Schema versus schema plus data.

	Ontology	Knowledge graph
Contains	Classes, properties, relations, axioms	Everything in the ontology + instances
Example	Student, Course, "enrolled in", "≥ 3 electives"	"Raja is an elephant", "Chetana teaches NLP", "HarperCollins published The Glass Palace"
Analogy	Database schema	Database schema + data
Optional parts	Instances	Nothing — instances are the point

An ontology defines the schema — the classes, properties, relations, and axioms. It may or may not have instances.
A knowledge graph is an ontology populated with instances. It contains specific facts: this person teaches that course, this book was published by that publisher.

An ontology without instances is like a database schema without data. A knowledge graph is the schema plus the data.

Professor's analogy — the bunch of keys. Imagine a drawer full of keys, all identical and unlabeled. Useless — you cannot tell which opens the house, the car, or the office. The moment you label each key and connect it to what it opens, the bunch becomes actionable. Raw data is the unlabeled bunch; a knowledge graph is the labeled, connected bunch. The labels are the URIs and the connections are the edges — together they turn inert facts into usable knowledge.

13.4.4 Tools for Ontology Creation

Several tools exist for creating ontologies:

Protégé (Stanford University, also spelled Protege in the literature) is the most widely used open-source tool for ontology creation. It provides a graphical interface where users can add classes, define properties, set restrictions, and create instances. The tool generates the formal ontology files (RDF, OWL) automatically. Users interact through a UI — they specify entities and relationships in natural language or structured form, and the tool produces the machine-readable syntax.

Tool	Origin / type	Notes
Protégé	Stanford University, open source	Most widely used; GUI for classes, properties, axioms
TopBraid Composer	Commercial IDE	Model-driven ontology development
Apollo	Academic research tool	Lightweight ontology editor
WebODE	Academic research tool	Web-based ontology engineering platform

The choice of tool depends on the scale and complexity of the ontology. For small teaching ontologies, Protégé alone is enough; for enterprise projects with versioning and teams, the commercial environments add workflow support.

Recap: an ontology is a formal, explicit, shared specification of a domain's concepts, relations, and rules. Fill it with instances and it becomes a knowledge graph — schema plus data.

Exam note: knowledge graphs and ontologies are important conceptual topics for the exam — know the definition, the five components, and the schema-versus-data distinction above.

Bridge to Section 13.5: an ontology is an idea; to put it on a machine we need a formal language. The next section introduces RDF, RDFS, OWL, and SPARQL — the languages of the Semantic Web.

---

13.5 Formal Languages for Ontologies

This section covers the formal languages of the Semantic Web: RDF for expressing facts, RDFS for schemas, OWL for reasoning, and the standard language for reading facts back out of a knowledge graph. It closes with the full layered picture of the technology that ties every language together.

13.5.1 RDF — Resource Description Framework

RDF (Resource Description Framework) is the most widely used formal language for expressing ontologies and knowledge graphs. RDF represents all knowledge as triples — a combination of subject, predicate, and object. A triple is the smallest possible fact, like the simplest possible sentence in grammar: subject → predicate → object.

Structure of a triple.

Subject: The entity being described (a resource).
Predicate: The relationship or property (how the subject relates to the object).
Object: The value or another entity that the subject is connected to.

The object of one triple can become the subject of another triple, so chaining triples forms a directed graph: subjects and objects are nodes, predicates are the labeled edges between them.

Example triples:

(Ian, has_colleague, Uli) — Ian and Uli are colleagues.
(Ian, has_homepage, "http://example.com/ian") — Ian has a homepage at this URL.
(Uli, has_email, "uli@example.com") — Uli has this email address.

A collection of such triples forms an RDF file. RDF files follow XML syntax conventions: every RDF file has a starting tag and a closing tag (similar to XML), and within these tags all the triples are expressed. The syntax is verbose but machine-readable.

Worked example: the Ian–Uli triples as a graph and as RDF/XML.

The three facts above form this tiny graph:

[Ian] ──has_colleague──▶ [Uli]
 [│                      │
 [└──has_homepage──▶ "http://example.com/ian"
                        [└──has_email──▶ "uli@example.com"

Note how "Uli" appears as the object of the first triple and as the subject of the third — the same node reused, which is what turns a list of facts into a connected graph.

The same content in RDF/XML syntax (showing the start/end tags):

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://example.com/">
  <rdf:Description rdf:about="ex:Ian">
    <ex:has_colleague rdf:resource="ex:Uli"/>
    <ex:has_homepage>http://example.com/ian</ex:has_homepage>
  </rdf:Description>
  <rdf:Description rdf:about="ex:Uli">
    <ex:has_email>uli@example.com</ex:has_email>
  </rdf:Description>
</rdf:RDF>

Sense-check: every angle bracket opens and closes, and each fact appears as subject → property → value. A machine can parse this file and reconstruct the graph exactly — nothing is left to interpretation.

Q: Why are RDF and OWL based on XML rather than JSON?

A: JSON is a structured key-value format that is easier to process for simple data exchange. However, OWL ontologies require reasoning capabilities — the ability to infer new relationships from existing ones using description logic. JSON cannot express these logical constructs. RDF and OWL need the expressiveness of XML to represent axioms, disjointness conditions, and logical inferences. In modern practice, simpler knowledge representations do use JSON, but when reasoning is required, the XML-based formats are necessary.

13.5.2 RDFS — RDF Schema

RDFS (RDF Schema) provides the schema framework for creating RDF files. It defines what classes, properties, and constraints are allowed — analogous to how an XML Schema defines the structure of an XML document.

What RDFS specifies.

What is a class (using rdf:type or rdfs:Class).
What is a property (using rdf:Property).
Class hierarchies (using rdfs:subClassOf).
Domain and range constraints on properties — what types of entities can be the subject and object of a given property.

For example, declaring that the property has_colleague has domain Person and range Person means the RDFS-aware system knows that anything on either end of a has_colleague edge is a person — a constraint that plain RDF does not enforce.

A small RDFS example:

<rdfs:Class rdf:about="ex:Person"/>
<rdfs:Class rdf:about="ex:Course"/>
<rdf:Property rdf:about="ex:teaches">
  <rdfs:domain rdf:resource="ex:Person"/>
  <rdfs:range rdf:resource="ex:Course"/>
</rdf:Property>

This declares two classes (Person, Course), a property (teaches), and the constraint that teaches connects a Person to a Course.

RDFS is not a standalone format for knowledge graphs. It serves as the backbone — the schema — that governs how RDF files are constructed. Knowledge graphs are expressed in RDF or OWL format, not in RDFS format alone.

13.5.3 OWL — Web Ontology Language

OWL is a more sophisticated language for creating ontologies. While RDF is simple and widely adopted, OWL adds reasoning capabilities based on description logic — a formal logical language.

Why OWL matters. OWL supports axioms — logical conditions and rules that enable inference. For example:

If class E belongs to class C, then there exists some instance in C that also belongs to class E (an existential restriction).
Tissue union part-of-heart can be expressed as a class intersection in OWL.
Disjointness conditions (an Indian elephant cannot be an African elephant) are expressible in OWL but not in RDF.

OWL also adds constructs that RDFS lacks: disjoint classes (Male and Female — nothing can be both), cardinality restrictions (a person has exactly two biological parents), and inverse properties (if isHusbandOf is the inverse of isWifeOf, the machine infers the reverse relation without it being typed explicitly).

Description logic components. OWL ontologies are built on description logic, which divides knowledge into two parts:

TBox (Terminological box): Defines the terminology — the classes and their relationships. This is the schema-level knowledge: faculty, course, student. A TBox example from the medical domain: \(PericardiumTissue \sqsubseteq partOf.Heart\) — "pericardium tissue is a subclass of things that are part of the heart."
ABox (Assertional box): States the facts or instances. This is the data-level knowledge: Chetana is a faculty member, NLP is a course, Student X is enrolled in NLP. A classic ABox example: \(HappyMan(Bob)\) — "Bob is an instance of HappyMan."

Every description logic system, including OWL, has these two components. The TBox defines what can exist; the ABox asserts what does exist.

Professor's analogy — the two boxes. Think of the TBox as the rulebook and the ABox as the score sheet. The rulebook says what players, positions, and rules exist (classes and axioms). The score sheet records what actually happened in this match (instances and facts). A reasoner can read both: from "NLP is a course" and "a course is a class of the academic domain", it knows NLP belongs in the domain's vocabulary even though that was never written down.

OWL files also use RDF tags — an OWL file contains RDF syntax plus more OWL-specific constructs for axioms, disjointness, cardinality restrictions, and other logical conditions.

Trade-off: OWL is more powerful than RDF but requires significantly more computational resources for reasoning. This is why OWL is less commonly used in production systems today — the compute cost of checking OWL files can be prohibitive. However, OWL is important in research areas like neurosymbolic AI, which combines neural networks with symbolic reasoning for artificial general intelligence (AGI).

13.5.4 SPARQL — Query Language

SPARQL (SPARQL Protocol and RDF Query Language) is the standard query language for RDF and OWL knowledge graphs. Its syntax is similar to SQL. A SPARQL query allows extracting information from an RDF or OWL knowledge graph.

How a SPARQL query reads. A query states a pattern of triples with variables (prefixed with ?). The engine finds every way to fill the variables from the graph. This is the professor's example — the top-liked songs during the Obama election period:

SELECT ?song (COUNT(?vote) AS ?likes)
WHERE {
  ?vote in_favor_of ?song .
  ?vote during_period "Obama election" .
}
GROUP BY ?song
ORDER BY DESC(?likes)

The query reads: find every vote triple, keep only votes cast during the "Obama election" period, group them by song, count each song's votes, and list the songs from most liked to least.

Worked example: tracing the SPARQL query. Suppose the graph contains these vote triples for the election period:

Vote	in_favor_of	during_period
vote_1	Song A	"Obama election"
vote_2	Song A	"Obama election"
vote_3	Song B	"Obama election"
vote_4	Song C	"Obama election"
vote_5	Song C	"Obama election"
vote_6	Song B	"earlier period"

Step 1 — apply the WHERE pattern: vote_6 is dropped (wrong period); the five remaining votes match. Step 2 — GROUP BY ?song: Song A holds votes {1, 2} = 2; Song B holds {3} = 1; Song C holds {4, 5} = 2. Step 3 — ORDER BY DESC(?likes): Song A (2 likes) and Song C (2 likes), then Song B (1 like); the tie between A and C is broken only if the query asks for it.

Final answer: A and C tied at 2, B at 1.

Sense-check: every number came from counting triples in the graph — no text search, no guessing. The graph stored the facts; SPARQL merely rearranged them.

Today, natural language queries can be automatically converted into SPARQL queries by AI systems, so memorizing the syntax is not essential for practical use — understanding what a query asks is.

13.5.5 The Semantic Web Technology Stack

The Semantic Web technology stack is often called the "Semantic Web cake" due to its layered, colorful appearance. From bottom to top:

URI / IRI (Uniform Resource Identifier / Internationalized Resource Identifier): Unique identifiers for every entity. Standardized by the W3C for common entities; custom URIs can be defined for enterprise data.
XML: The base markup language for syntax.
RDF (Resource Description Framework): The framework for expressing knowledge as triples (subject, predicate, object).
RDFS (RDF Schema): The schema layer defining what classes and properties are valid.
OWL (Web Ontology Language): The advanced ontology language with reasoning capabilities.
SPARQL: The query language for extracting information from RDF/OWL knowledge graphs.
Logic, Proof, and Trust: Upper layers for security, trust verification, and logical reasoning.
Applications: Question answering, semantic search, data analytics, and other systems built on top of the knowledge graph.

A visual sketch of the stack:

+----------------------------------------------+
| User Interface & Applications                |  ← layer 8
+----------------------------------------------+
| Trust, Proof & Cryptography                  |  ← layer 7
+----------------------------------------------+
| Unifying Logic (Reasoning & Rules)           |  ← layer 7
+----------------------------------------------+
| Ontology Vocabulary: OWL                     |  ← layer 5
+----------------------------------------------+
| Schema Vocabulary: RDFS                      |  ← layer 4
+----------------------------------------------+
| Data Interchange & Query: RDF + SPARQL       |  ← layers 3 & 6
+----------------------------------------------+
| Syntax & Identifiers: XML + URI / IRI        |  ← layers 1 & 2
+----------------------------------------------+

Each layer builds on the one below: XML provides syntax for RDF, RDFS constrains RDF's vocabulary, OWL adds reasoning on top of RDFS, and SPARQL reads everything back out.

Recap: RDF expresses facts as triples, RDFS constrains their schema, OWL adds axioms and inference, and SPARQL queries the result — all stacked on XML and URIs.

Exam note: expect questions on the relationship between ontologies and knowledge graphs, RDF triples, and the Semantic Web stack. The distinction between RDF, RDFS, and OWL is important — know what each layer adds. The concept of TBox (terminology) and ABox (assertions/facts) in description logic may appear.

Bridge to Section 13.6: the stack is the target format. The open problem is scale — nobody types billions of triples by hand. The next section shows how knowledge graphs are built automatically from text.

---

13.6 Automatic Construction of Knowledge Graphs

This section explains how knowledge graphs are built automatically from text — the ontology learning pipeline — the NLP techniques involved, and a concrete code-level walkthrough that builds a graph from a Wikipedia page in minutes.

13.6.1 Ontology Learning and Population

Purpose. Manually creating ontologies using tools like Protégé is feasible for small domains but does not scale. Nobody types billions of RDF triples by hand. For large-scale applications, knowledge graphs must be constructed automatically from text — this is called ontology learning, and it is the difference between a classroom exercise and an industrial knowledge graph.

The process has three stages:

The three-stage pipeline.

Concept extraction: Identify the key concepts (entities) in the text using named entity recognition (NER) or part-of-speech tagging. This finds the nodes — spotting "London" and "England" in a news article.
Relation extraction: Identify the relationships between entities using dependency parsing, relation extraction models, or LLM-based extraction. This finds the edges — realizing that the phrase "is the capital of" links London to England.
Ontology population: Fill the ontology with the specific instances extracted from the data. A populated ontology is a knowledge graph — the schema from the ontology plus the entities and relations mined from the text.

Automatic extraction techniques are fast but produce noisy results. Entities may be partially extracted (e.g., "BITS" and "Pilani" separately instead of "BITS Pilani"), relations may be incorrectly assigned, and some extracted triples may be nonsensical. The quality of the output depends on the sophistication of the NLP tools used.

The noise problem — and why speed still wins.

Partial entities. NER can split a single entity into pieces: "BITS" and "Pilani" instead of "BITS Pilani".
Wrong relations. A dependency parser may link two entities that are not actually related in meaning.
Nonsense triples. Some extracted (subject, predicate, object) combinations are meaningless, and nothing in the pipeline notices.

Despite the noise, automatic construction is valuable because it is fast and requires minimal compute resources — no large language models or GPU clusters are needed. Simple NLP libraries can produce a usable knowledge graph from any text corpus in minutes. Human review or automated filtering (Section 13.6.3) then improves the quality in a second pass.

13.6.2 NLP Techniques for KG Construction

The following NLP tools and techniques are used for automatic knowledge graph construction:

The technique toolbox.

Named Entity Recognition (NER): Identifies entities (people, organizations, locations, dates) in text. Tools like spaCy provide pre-trained NER models.
Dependency Parsing: Analyzes the grammatical structure of sentences to extract subject-verb-object triples. spaCy's dependency parser can automatically extract triples from text.
Relation Extraction Models: Specialized models trained to identify semantic relationships between entities.
LLM-based Extraction: Large language models can extract entities and relations from text using prompt engineering — describe the desired triple format and the model fills it in.

For Indian languages, tools and models are available through organizations like AI for Bharat (IIT Madras research initiative) and Sarvam (a commercial organization building small language models for Indian languages). These include named entity taggers and machine translation systems for Indian scripts. For handwritten or ancient scripts (Sanskrit, Pali), OCR is first applied to digitize the text, and then NLP tools process the digital text. Bharat Gen is a related initiative for Indian language AI models.

Q: How can we build a knowledge graph from old Indian literature in Sanskrit or Pali?

A: OCR can digitize handwritten scripts, then machine translation or language-specific NER tools can extract entities and relations. AI for Bharat and Sarvam are building NLP tools for Indian languages including Sanskrit and Pali. The pipeline is the same as for any language — digitize, then extract — the difference is the availability of language-specific models.

A second student question pushed the same pipeline to brand-new data.

Q: For new or unseen data, how can we automatically find objects, properties, and relationships?

A: Use contextual word embeddings — semantically similar entities will lie in the same vector space. You can construct knowledge graphs for new entities by rerunning the extraction algorithm. Word embedding techniques enable this for previously unseen data: because the model was trained on the general distribution of language, new words inherit useful positions from the words they appear with, and the extraction pipeline can be re-run without retraining.

13.6.3 Code Example: Building a Knowledge Graph from Text

The following approach shows how to automatically build a knowledge graph from a Wikipedia page using Python with spaCy and NetworkX:

Fetch and clean text. Download a Wikipedia page (e.g., the "Data Science" page). Use Beautiful Soup to clean the HTML content — remove tags, ASCII characters, and formatting — to produce plain text.
Extract entities and relations. Use spaCy's built-in entity extraction and dependency parsing functions to identify entities and the relationships between them. This produces a set of (subject, predicate, object) triples.
Build the graph. Use the NetworkX library to construct a directed graph from the extracted triples. Each triple becomes two nodes (subject and object) connected by a labeled edge (predicate).
Visualize and analyze. The resulting graph can be visualized using NetworkX or exported to tools like Neo4j. Statistics such as the number of nodes, edges, and connected components provide an overview of the graph's structure.

Worked example: the Data Science page run.

Input: the English Wikipedia article "Data Science" (about 10,000 words of text after cleaning).

Step 1 — Beautiful Soup strips HTML tags and markup, leaving plain sentences. Step 2 — spaCy's NER marks entities (statistics, machine learning, data mining, Python, R), and the dependency parser extracts relations such as data science —uses— statistics and data mining —subset of— machine learning. Step 3 — NetworkX builds a directed graph: each (subject, predicate, object) triple contributes two nodes and one edge.

Output statistics for this run:

4,023 nodes (terms) — the extracted entity vocabulary.
5,393 edges (connections) — the extracted relations.

The extracted entities include concepts like data warehouse, data mining, data integration, data fusion, and data augmentation.

Noise observed: some entity names are partially extracted or incorrectly segmented, and a minority of the relations are semantically off. The speed and zero-resource nature of the extraction make it practical for an initial graph; subsequent human review or automated filtering improves quality.

Sense-check: 5,393 edges for 4,023 nodes means an average degree of about 1.3 edges per node — a sparse, mostly chain-like graph typical of automatic extraction, which is why filtering (below) is the next step.

Filtering the graph. To reduce complexity, the graph can be filtered by limiting the maximum number of node-to-node connections (e.g., restricting to nodes with at most two hops). This produces a smaller, more focused subgraph — the core concepts around "data science" — which is far easier to visualize and to load into a graph database.

Recap: knowledge graphs are built automatically in three stages — concept extraction, relation extraction, and ontology population — using NER and dependency parsing, with noise as the price of speed.

Exam note: understanding how knowledge graphs are automatically constructed from text (using NER, dependency parsing) is relevant — know the three stages and the pipeline of the code example.

Bridge to Section 13.7: once graphs exist at scale, they become useful: the next section surveys industry applications, Linked Open Data, and the reasoners that keep graphs consistent.

---

13.7 Applications of Knowledge Graphs and Ontologies

This section surveys where knowledge graphs and ontologies are used in industry, introduces the Linked Open Data initiative, and explains reasoners — the tools that infer new facts and keep large graphs consistent.

13.7.1 Industry Applications

Knowledge graphs and ontologies have wide-ranging applications across industries:

Word sense disambiguation. The hierarchical structure of ontologies (parent class, child class, properties) provides rich contextual information that helps disambiguate word meanings more effectively than flat representations. Knowing that bank has senses arranged under financial and geographical branches gives a disambiguator structural evidence to work with — the hierarchy is context the flat bag-of-words approach from Section 13.1 never sees.

Information retrieval and semantic search. Knowledge graphs improve search precision by understanding the meaning of queries rather than relying on keyword matching. Google's Knowledge Graph powers the information panels in search results: because the graph knows "Perth" is a City located in Australia, a system can answer "how far am I from Perth" with a distance computation instead of a text match.

Machine translation. Ontologies help map concepts across languages by providing language-independent identifiers for entities and relationships. Instead of aligning English words to French words, systems align both to shared concepts — "moulin" and "mill" both point to the same machine concept, so translation survives vocabulary gaps.

Query understanding. Knowledge graphs provide background knowledge that helps systems understand user intent and resolve ambiguity in queries. A query about "apple" is disambiguated by the graph when the context includes "iPhone".

Life sciences and medical research. Stanford University's BioPortal hosts a large collection of biomedical ontologies for cancer research, myocardial infarction, and other medical domains. The UMLS (Unified Medical Language System) is a comprehensive ontology with thousands of concepts. These resources were used extensively during COVID-19 for connecting disparate medical data — linking research papers, drug databases, and clinical records across labs and hospitals.

LinkedIn. Knowledge graphs are used to connect employee databases with job requirements. When an HR professional searches for candidates with specific skills, experience, and project backgrounds, the knowledge graph enables efficient mapping between requirements and candidate profiles — the search finds people who satisfy all constraints, not pages that mention the keywords.

Sentiment analysis. Ontologies provide structured knowledge about entities and their attributes, which can be used to interpret sentiment in context. Mapping words to an emotion ontology lets analysts categorize text into emotion vectors — Anger, Joy, Fear, Trust — instead of a single positive/negative label.

Question answering and conversational AI. Knowledge graphs serve as the structured backend that provides factual, grounded answers to user queries — the same graph architecture behind the QA systems in Section 13.3.4.

13.7.2 Linked Open Data

Linked Open Data (LOD) is an open initiative, originally driven by the European government, that makes structured datasets publicly available and interlinked. The nucleus of the LOD ecosystem is DBpedia — the structured extraction of Wikipedia info boxes.

The LOD cloud contains thousands of datasets from diverse domains:

Government data: Policies, statistics, and public records from European, Indian, and other governments.
Industry data: Datasets from Netflix, geographic databases (GeoNames), and other commercial sources.
Academic data: Publications from IEEE, ACM, and other research organizations.
Domain-specific data: Medical, legal, financial, and other specialized datasets.

Each dataset in the LOD cloud is published in RDF format with unique URIs, allowing datasets to be linked to each other.

Worked example: the Amsterdam link. The DBpedia entry for Amsterdam carries population and history facts. The GeoNames dataset carries geographic coordinates. A single triple connects them:

dbpedia:Amsterdam —sameAs→ geonames:2759793

Because both datasets agree on this one identity link, an application can pull Amsterdam's population from DBpedia and instantly plot it on a map using the GeoNames coordinates — two datasets, one shared URI, zero human copying.

Sense-check: the link works because each dataset identified the same city with its own URI and then declared the equivalence. That declaration is the "open" part of Linked Open Data.

This creates a web of interconnected, openly accessible, high-quality structured data: the DBpedia entry for Amsterdam links to GeoNames for latitude and longitude, which links to other geographic datasets.

Rules for participation. To contribute data to the LOD cloud, datasets must satisfy certain criteria — primarily, they must use RDF format and provide unique URIs for their entities. Two simple rules, and the entire cloud becomes joinable.

13.7.3 Reasoners and Inference

Reasoners are tools that can infer new relationships from existing ontological knowledge. Tools like RacerPro and FaCT++ (also written "Palette" in some references) perform logical inference on OWL ontologies: they read the TBox axioms and the ABox facts and derive facts that were never explicitly stated.

Worked example: inferring an indirect relationship. The ontology contains these two facts:

Chetana teaches Course X.
Student Y is enrolled in Course X.

No statement anywhere says Chetana teaches Student Y. But the ontology also carries a rule (an axiom of the TBox): a person who teaches a course teaches every student enrolled in that course.

The reasoner applies the rule:

Match the rule's premises against the ABox: teaches(Chetana, Course X) ✓ and enrolled(Y, Course X) ✓.
Both premises hold, so the rule fires.
Conclusion: Chetana teaches Student Y — a new triple that was never typed into the graph.

Final result: one new fact derived from two existing facts and one rule.

Sense-check: without the rule, a search for "does Chetana teach Student Y?" returns nothing. With the reasoner, the answer is derived in milliseconds — this is exactly the "inference" that separates a database from a knowledge graph.

Noise detection and auto-correction. Reasoners can also identify inconsistencies and errors in automatically constructed knowledge graphs. If an RDF file contains contradictory statements (e.g., an entity classified as both a herbivore and a carnivore), the reasoner flags the inconsistency and suggests corrections. This is particularly valuable when knowledge graphs are built automatically from noisy text data (Section 13.6) — the reasoner plays the role of the automated reviewer that the pipeline lacks.

Pitfalls of reasoners:

Garbage in, garbage out. A reasoner is only as good as its axioms. A wrong rule produces confident wrong conclusions.
Noise amplification. A noisy auto-constructed graph can let one bad triple combine with a rule to derive dozens of misleading facts — which is why consistency checking is run early.
Incomplete ontologies. If the TBox is missing a rule, the reasoner silently infers nothing — absence of a derivation is not proof of absence in the world.
Compute cost. Reasoning over large OWL ontologies is expensive, which is one reason production systems prefer lighter RDF-based pipelines.

Recap: knowledge graphs power search, healthcare, recruiting, and QA systems; Linked Open Data publishes them at web scale; and reasoners both derive new facts and catch inconsistencies.

Bridge to Section 13.8: one of the newest and most visible applications of knowledge graphs is Graph RAG — grounding large language model answers in graph-retrieved context. The lecture closes with a first look at that idea.

---

13.8 Introduction to Retrieval Augmented Generation (RAG)

The lecture concluded with a brief introduction to Retrieval Augmented Generation (RAG), which will be covered in detail in the next session. This section captures the motivation, the core idea, and the RAG variants — plus the connection back to knowledge graphs.

13.8.1 Motivation and Core Idea

Hook: Ask a general-purpose language model "who is teaching NLP in the MTech AIML batch this semester?" It cannot know — that fact is neither in its training data nor fixed in time. RAG is the standard solution to this problem.

Motivation. General-purpose language models (like GPT) do not have access to enterprise-specific or up-to-date information. For example, a generic LLM cannot answer "who is teaching NLP in the MTech AIML batch" because that information was not in its training data and may change over time. Retraining the model on every new fact is impractical — RAG addresses this by providing external, up-to-date knowledge to the language model at query time.

Core idea. A RAG system works in two phases:

Retrieve: fetch relevant documents or knowledge from an external source — a search index, a vector database, or a knowledge graph — based on the user's question.
Generate: pass the retrieved context to the language model, which produces an answer grounded in that context.

Because the knowledge lives outside the model, the system's answers stay current and domain-specific without retraining. The model is a generator; the retrieval source is the memory.

This two-phase design is why the professor saved the topic for its own module: RAG combines search, embeddings, and language models, and the details (chunking, indexing, ranking, prompting) fill an entire upcoming session.

13.8.2 RAG Variants and Knowledge Graph Connection

Variants. Several RAG architectures exist:

Naive RAG: Uses vector stores and similarity search to retrieve relevant text chunks. The simplest form — split documents into chunks, embed them, and fetch the nearest chunks to the query.
Graph RAG: Uses a knowledge graph to retrieve structured, interconnected context. This is one of the most popular techniques in industry (Section 13.3.4).
Agentic RAG: Uses autonomous agents that can reason, plan, and use tools to retrieve and synthesize information — the agent decides which sources to query, in which order, and when to stop.

Variant	Memory	Strength
Naive RAG	Vector store of text chunks	Fast, simple, good for single-passage answers
Graph RAG	Knowledge graph (entities + edges)	Multi-hop questions across connected facts
Agentic RAG	Multiple tools + agent loop	Complex, multi-step research tasks

Connection to knowledge graphs. Knowledge graphs provide the structured backend for Graph RAG systems. The entities and relationships in the graph serve as the retrieval corpus, enabling more precise and contextually rich retrieval than simple vector similarity search — the difference between "which chunk mentions this word" and "which entities connect through these relations" (the book-graph queries of Section 13.3.1).

13.8.3 Student Questions and Answers

Q: When we give skills and requirements to an AI coding agent, is it using knowledge graphs internally to search GitHub repositories?

A: Most likely, yes. AI agents typically use a combination of pre-trained language models (possibly small, specialized models for specific tasks like code generation), tool use (access to search engines, code repositories, etc.), memory systems, and retrieval architectures. There is a high probability that RAG or Graph RAG is part of the backend, but the exact architecture is proprietary and not publicly disclosed.

Recap: RAG grounds a language model's answers in external knowledge retrieved at query time — via vectors (naive RAG), graphs (Graph RAG), or agents (agentic RAG).

Exam note: Quiz 3 does not include RAG content; RAG will be covered in future sessions. Know the three variants and their connection to knowledge graphs for the end-semester material.

Bridge to the next session: the next session begins the RAG module in full detail — retrieval, indexing, and grounding. After that comes text summarization, and then the review session for the end-semester exam.

---

Exam Guidance Summary

Knowledge graphs and ontologies are important conceptual topics for the exam — expect definition-style questions on both (Section 13.4).
Expect questions that test understanding of the relationship between ontologies and knowledge graphs (schema vs. schema plus data), RDF triples, and the Semantic Web technology stack (Section 13.5).
The distinction between RDF, RDFS, and OWL is important — know what each layer adds: triples, schema, and reasoning respectively.
The concept of TBox (terminology) and ABox (assertions/facts) in description logic may appear — the TBox defines what can exist, the ABox asserts what does exist.
Understanding how knowledge graphs are automatically constructed from text (using NER, dependency parsing) is relevant — recall the three stages: concept extraction, relation extraction, ontology population (Section 13.6).
The connection between knowledge graphs and Graph RAG is an important application-level concept (Section 13.3.4).
Quiz 3 does not include RAG content; RAG will be covered in future sessions.
Upcoming sessions: RAG module (next session), text summarization application (following session), and a review session for the end-semester exam.

---

Key Industry Applications

Google Knowledge Graph: Powers Google search's information panels and structured answers. Accessible via API; the backend for modern search (Section 13.3.4).
Google Open Knowledge Graph: An open knowledge graph initiative by Google for the web corpus.
Neo4j: Open-source and commercial graph database for storing, querying, and visualizing knowledge graphs using the Cypher query language.
Stanford Protégé: Open-source tool for creating and editing ontologies (Section 13.4.4).
Stanford BioPortal: Repository of biomedical ontologies for cancer research, cardiology, and other medical domains.
DBpedia: Structured knowledge graph extracted from Wikipedia info boxes; nucleus of the Linked Open Data cloud (Sections 13.3.3 and 13.7.2).
Linked Open Data (LOD): Open initiative linking thousands of structured datasets from governments, industry, and academia — participation requires RDF format and unique URIs.
LinkedIn Knowledge Graph: Used for connecting employee profiles with job requirements and recommendations.
AI for Bharat (IIT Madras): Research initiative building NLP tools and models for Indian languages.
Sarvam: Commercial organization building small language models for Indian languages.
Bharat Gen: Initiative for Indian language AI models.
spaCy: NLP library used for named entity recognition and dependency parsing in knowledge graph construction (Section 13.6.2).
NetworkX: Python library for constructing and visualizing graph structures (Section 13.6.3).
Beautiful Soup: Python library for cleaning HTML content during text preprocessing.
RacerPro / FaCT++: OWL reasoners that infer new relationships and detect inconsistencies in ontologies (Section 13.7.3).
UMLS (Unified Medical Language System): Comprehensive medical ontology with thousands of concepts.

---

NLP Lecture 13 notes

Natural Language Processing· postgraduate· 2026-08-02

Sections Breakdown

113.1 Word Sense Disambiguation — Recap

Supervised multi-class classification for WSD and the knowledge-based Lesk algorithm for choosing a word's intended sense.

213.2 The Semantic Web Vision

Tim Berners-Lee's vision of a web of machine-understandable data, the limits of the syntactic web, and the data challenges of the modern era.

313.3 Knowledge Graphs — Core Concepts

An ontology populated with instances: entities as nodes, labeled relations as edges, URIs, DBpedia enrichment, and Graph RAG.

413.4 Ontologies

Formal, explicit, shared specification of a domain's concepts, relations, and axioms; ontology versus knowledge graph.

513.5 Formal Languages for Ontologies

RDF triples, RDFS schemas, OWL reasoning, SPARQL queries, and the layered Semantic Web technology stack.

613.6 Automatic Construction of Knowledge Graphs

The ontology-learning pipeline — concept extraction, relation extraction, and ontology population from raw text.

713.7 Applications of Knowledge Graphs and Ontologies

Industry applications, Linked Open Data, and reasoners that infer new facts and preserve graph consistency.

813.8 Introduction to Retrieval Augmented Generation (RAG)

Grounding LLM answers in external knowledge retrieved at query time — naive, graph-based, and agentic variants.

Postgraduate students in Natural Language Processing

Exam Revision Notes

Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.

13.1 Word Sense Disambiguation

Must-know: WSD is a multi-class classification over senses; Lesk is the knowledge-based alternative that picks the sense whose gloss/example words overlap the context the most (bank₁ won 2 to 0).

\[idf_i = \log\frac{N_{doc}}{n_{d_i}}\]

Top pitfall: String matching misses morphological variants (investments vs investing) — vector similarity fixes this; most-frequent-sense is only a baseline.

Self-check: Why does the one-sense-per-discourse heuristic fail in a newspaper quoting both a biologist and a cricketer?

Connects to: Semantic Web vision, Knowledge graphs

13.2 The Semantic Web Vision

Must-know: The syntactic web connects documents by URL; the Semantic Web connects data by meaning so machines can integrate, automate, and reason over information globally.

Top pitfall: Keyword search cannot apply exclusions (bats/dolphins) or join datasets across formats; graphs with shared identifiers are the prerequisite.

Self-check: Which three datasets and join key answer 'most popular songs when Obama was elected'?

Connects to: Word Sense Disambiguation, Knowledge graphs

13.3 Knowledge Graphs

Must-know: In the book graph the ISBN is the unique identifier and every query is an edge traversal; URIs make data linkable, and DBpedia enriches a graph via shared URIs.

Top pitfall: Local strings are not identities — 'Ghosh, Amitav' and 'Amitav Ghosh' are two entities without a shared URI.

Self-check: How is a knowledge graph different from a Graph Neural Network?

Connects to: Ontologies, Automatic construction, RAG

13.4 Ontologies

Must-know: An ontology is a formal, explicit, shared specification of a conceptualization with five components (classes, properties, relations, axioms, optional instances); populated, it becomes a knowledge graph.

Top pitfall: Confusing instances with classes, and thinking RDF can enforce axioms — disjointness and thresholds require OWL.

Self-check: If Raja weighs 2,400 kg and eats plants, which classes does he belong to and which is he excluded from, and why?

Connects to: Knowledge graphs, Formal languages

13.5 Formal Languages for Ontologies

Must-know: RDF expresses facts as triples (subject-predicate-object); RDFS constrains the schema; OWL adds reasoning; SPARQL queries the graph; all three stack on XML and URIs.

Top pitfall: RDF and XML cannot express axioms — disjointness and cardinality require OWL; JSON is simpler but cannot reason.

Self-check: Why can't plain RDF state that Indian elephants and African elephants are disjoint?

Connects to: Ontologies, Automatic construction

13.6 Automatic KG Construction

Must-know: The three-stage pipeline — concept extraction (NER), relation extraction (dependency parsing), and ontology population; automatic extraction is noisy but fast and needs zero heavy compute.

Top pitfall: Entities split in half ('BITS' + 'Pilani'), wrong relations, and nonsense triples — human review or reasoners clean up afterward.

Self-check: What statistics did the Wikipedia Data Science run (4,023 terms / 5,393 connections) reveal about automatic KG construction?

Connects to: Knowledge graphs, Applications

13.7 Applications and Reasoners

Must-know: Graphs answer constraint queries (Perth is a City in Australia); Linked Open Data requires RDF plus unique URIs; reasoners derive new facts and flag contradictions.

Top pitfall: A reasoner amplifies noise — one bad triple plus a rule can derive many misleading facts; consistency checks must run early.

Self-check: What does the Amsterdam DBpedia-to-GeoNames sameAs triple achieve, and what are the two rules for joining the LOD cloud?

Connects to: Formal languages, RAG

13.8 Retrieval Augmented Generation (RAG)

Must-know: RAG has two phases — retrieve external knowledge, then generate a grounded answer; variants are Naive (vectors), Graph RAG (knowledge graph), and Agentic RAG (agents + tools).

Top pitfall: A generic LLM cannot answer enterprise-specific or time-varying facts without retrieval — and Quiz 3 does not include RAG.

Self-check: Why does Graph RAG retrieve more relevant context than naive RAG on multi-hop interconnected questions?

Connects to: Knowledge graphs, Applications

Previous LectureLecture 12 · Contextual Word Embedding and Word Sense Disambiguation

Next LectureLecture 01 · Software Engineering for Machine Learning — Foundation and Overview

Was this lecture useful?

Loading comments…