Why building a Knowledge Graph is far more than extracting entities and relationships.
Introduction
Knowledge Graphs have become one of the fundamental building blocks of modern Artificial Intelligence. From semantic search engines and digital libraries to Retrieval-Augmented Generation (RAG), question answering, recommendation systems, and scientific knowledge discovery, many intelligent applications rely on structured knowledge rather than isolated pieces of text.
While recent advances in Transformer models have significantly improved tasks such as Named Entity Recognition (NER) and Relation Extraction (RE), constructing a production-ready Knowledge Graph remains a much broader engineering challenge. Extracting triples from text is only one stage in a considerably larger pipeline.
This challenge becomes even more significant for low-resource languages such as Sri Lankan Tamil, where limited annotated datasets, scarce linguistic resources, and complex morphological characteristics make large-scale knowledge extraction considerably more difficult.
During the development of our Noolaham Knowledge Graph, we initially viewed the project as a conventional Information Extraction problem. However, as the system evolved, it became increasingly clear that successful Knowledge Graph construction required much more than a sequence of NLP models.
Instead of continuously improving individual models in isolation, we shifted our attention toward architecting a modular, extensible, and storage-independent knowledge engineering pipeline capable of evolving over time without requiring complete redesigns.
This article discusses the engineering decisions that shaped that architecture.
Information Extraction Is Only One Layer of the System
Most research on Relation Extraction concludes with the generation of structured triples.
Although this representation is suitable for evaluating extraction models, it is insufficient for constructing a real Knowledge Graph.
A Knowledge Graph must answer questions such as:
- Is this entity already present in the graph?
- Does this relationship conform to the ontology?
- Are multiple surface forms referring to the same real-world entity?
- Can the extracted knowledge be exported to different graph technologies?
- Can downstream AI systems reuse the graph independently of its storage backend?
These questions are architectural rather than algorithmic.
Consequently, the project evolved from an Information Extraction pipeline into a complete Knowledge Graph engineering pipeline.
Designing for Modularity Rather Than Monolithic Processing
One of the earliest architectural decisions was to avoid tightly coupling individual NLP components.
Instead of treating the pipeline as a single end-to-end model, each responsibility was isolated into an independent processing stage.
Rather than asking:
“How can we improve the relation extraction model?”
we asked:
“How can every component evolve independently without affecting the remaining system?”
This philosophy led to a highly modular architecture where sentence segmentation, entity recognition, relation classification, normalization, graph construction, and exporting are completely decoupled.
Such modularity provides several advantages:
- Independent benchmarking of components
- Easier debugging
- Model replacement without system redesign
- Clear separation of responsibilities
- Simplified experimentation
These principles closely mirror modular knowledge graph engineering frameworks, where reusable components are orchestrated through well-defined interfaces instead of tightly integrated pipelines.
From Static Relations to Dynamic Relation Schemas
Traditional relation extraction systems typically classify relationships using a single global label set.
For example,
WORKED_AT
LIVED_IN
PART_OF
BORN_IN
CONTRIBUTED_TO
...
Every entity pair is evaluated against the same collection of candidate relations regardless of its semantic context.
While this approach is straightforward, it unnecessarily enlarges the prediction space.
Instead, we introduced Dynamic Relation Schemas.
The relation classifier no longer receives every possible relation.
Instead, it first examines the entity types.
PERSON
│
▼
LOCATION
Only then is the corresponding schema loaded.
{
LIVED_IN
BORN_IN
DIED_IN
STUDIED_IN
VISITED
}
Similarly,
PERSON
↓
ORGANIZATION
activates an entirely different semantic relation family.
This hierarchical decision process reduces ambiguity, improves extensibility, and establishes a natural bridge toward ontology-driven validation.
Separating Information Extraction from Knowledge Graph Construction
Perhaps the most significant architectural change occurred when we realized that extracting triples and constructing a Knowledge Graph are fundamentally different tasks.
Initially, extracted triples were inserted directly into Neo4j.
Triples
↓
Neo4j
Although functional, this tightly coupled the extraction pipeline with a single storage technology.
As the project matured, this approach became increasingly restrictive.
Instead, we introduced an intermediate Knowledge Graph ETL layer.
This additional layer became responsible for transforming extracted information into graph-ready knowledge.
Rather than modifying the extraction process itself, all graph-specific refinement now occurs after triple generation.
The result is a cleaner separation between language understanding and graph engineering.
Knowledge Graph Construction Requires Normalization
Extracted entities rarely exist in their canonical forms.
Consider the following examples.
யாழ்ப்பாணத்தில்
யாழ்ப்பாணத்திற்கு
யாழ்ப்பாணத்தின்
Although linguistically different, each refers to the same location.
If inserted directly into a graph database, these forms would generate multiple independent nodes representing the same real-world entity.
To address this problem, a dedicated normalization stage was introduced within the Knowledge Graph ETL pipeline.
Rather than modifying the extraction models, normalization operates exclusively on completed triples.
This design preserves the original extraction evidence while ensuring that the Knowledge Graph stores canonical entities.
By separating linguistic normalization from Information Extraction, the architecture remains easier to benchmark and considerably easier to maintain.
Storage Should Never Define the Architecture
Knowledge Graph projects are frequently designed around a particular database.
Once Neo4j is selected, every component gradually becomes dependent upon Neo4j-specific representations.
We intentionally avoided this design.
Instead, we introduced an independent Export Layer.
The extraction pipeline now produces an internal representation that is independent of any storage backend.
Neo4j becomes one possible consumer rather than the architectural centre of the system.
This approach significantly improves interoperability.
The same extracted knowledge can be:
- stored in Neo4j,
- serialized as RDF Turtle,
- exported as JSON,
- or integrated into future graph platforms,
without modifying the Information Extraction pipeline itself.
This separation between graph construction and graph serialization is consistent with modern knowledge graph engineering practices that emphasize interoperability and reusable graph representations.
Architecture as a Research Contribution
One of the most valuable lessons from this project is that meaningful research contributions are not always driven by larger neural networks or novel Transformer architectures. In knowledge engineering, equally significant advances often emerge from architectural design decisions that improve modularity, interoperability, extensibility, and long-term maintainability.
Throughout the development of this pipeline at the Center for Tamil Natural Language Processing Research (CTNLPR), our objective gradually shifted from building an information extraction system to engineering a reusable knowledge engineering framework.
This evolution led to several important architectural decisions:
- Separating information extraction from knowledge graph construction.
- Introducing dynamic relation schemas based on entity-type combinations.
- Designing reusable processing layers with clearly defined responsibilities.
- Treating graph export as an interchangeable backend rather than a database-specific implementation.
- Isolating normalization and canonicalization from language models through a dedicated Knowledge Graph ETL layer.
Individually, these decisions may appear incremental. Collectively, however, they establish a modular architecture that is significantly easier to benchmark, extend, maintain, and adapt to future research directions.
This experience reinforces an important principle: knowledge engineering is fundamentally a systems engineering discipline, where long-term success depends not only on model performance, but also on how effectively individual components collaborate within a coherent architecture.
Looking Forward
At CTNLPR, we view this work not as a finished Knowledge Graph, but as the foundation of a broader Tamil Knowledge Engineering ecosystem.
The architecture has been intentionally designed so that individual layers can evolve independently while preserving the integrity of the overall system. As more advanced language models, semantic technologies, and ontology engineering methodologies emerge, they can be integrated without redesigning the complete pipeline.
Our long-term vision extends beyond extracting entities and relationships from documents. We aim to establish a modular semantic infrastructure capable of transforming unstructured Tamil digital collections into interconnected, machine-understandable knowledge that supports intelligent search, semantic reasoning, question answering, digital humanities research, and future AI-driven applications.
Ultimately, the contribution of this work is not defined by a single algorithm or model. It lies in demonstrating that building reliable Knowledge Graphs for low-resource languages is fundamentally an architectural challenge—one that requires the integration of natural language processing, software engineering, and knowledge engineering into a unified, extensible framework.