The Building Blocks of Knowledge Graphs: a Look at Cognee’s Approach

The Buzz Around Knowledge Graphs

Knowledge graphs are everywhere these days. Tech giants use them, AI practitioners rely on them to supercharge data storage and retrieval functions, and everyone wants them as the memory or semantic layer for their LLM applications. But what exactly are they?

If you haven’t worked with knowledge graphs directly, they might seem like an extra layer of complexity whose benefits aren’t immediately obvious. In reality, they’re quite straightforward structures that capture complex information—along with the relationships that give it meaning—in a way that is both intuitive and powerful.

At their core, knowledge graphs organize information so machines can understand, navigate, and reason with it. They don’t just store facts; they connect them, allowing us to see patterns, uncover insights, and get answers to complex queries that would otherwise be difficult to respond to.

In this post, we’ll take a practical look at knowledge graphs. We’ll do more than just define them; we’ll also see how they can serve as a memory layer, a semantic framework, and a reasoning engine for an AI system like cognee.

We’ll keep things simple: first, we’ll look at how information can be extracted from natural text, then we’ll break down the core data structures—graphs, nodes, and relationships. Finally, we’ll cover cognee’s DataPoints and see how they enable a flexible and dynamic approach to building knowledge graphs.

What Is a Knowledge Graph, Really?

To make sense of knowledge graphs, let’s first unpack the term itself. ‘Knowledge’ is what we want to capture, and ‘graph’ is how we structure it.

Essentially, a graph is just a set of nodes and edges. Nodes represent entities—people, things, companies, places—and edges define the relationships between them, such as who knows whom, what belongs to whom, or where something happened.

Let’s start with two simple sentences:

1. Alice bought a book.
2. She read it in a park.

There’s no single “correct” way to represent this as a knowledge graph, but here’s one approach that aligns well with cognee’s model:

Nodes:

• Alice (Person)
• A Purchase Event (Event [type=“purchase”])
• A Reading Event (Event [type=“reading”])
• Book (Medium)
• Park (Location)

Edges (Relationships):

• (A Purchase Event) → (by) → (Alice)
• (A Purchase Event) → (of) → (The Book)
• (A Reading Event) → (by) → (Alice)
• (A Reading Event) → (of) → (The Book)
• (A Reading Event) → (at) → (The Park)

And that’s all a graph needs—nodes and edges. Even with just these few pieces of data, we can already see meaningful relationships forming. A knowledge graph can capture a vast amount of meaning simply by connecting related facts.

Over time, researchers and engineers have developed powerful ways to search, analyze, and extract insights from graphs, harnessing the informational potential of the connections stored within them. This ability to uncover hidden relationships is a key reason tech giants use knowledge graphs, and why they’re becoming essential for AI practitioners.

Dedicated graph databases like Neo4j and FalkorDB treat graphs as a fundamental data structure, enabling us to efficiently store, query, and navigate complex networks of information. Libraries like NetworkX make it easy to analyze graphs programmatically. Building on these tools, cognee has been designed specifically to create knowledge graphs by automatically extracting both facts and deeper meaning from raw data.

DataPoint: Cognee’s Knowledge Graph Building Block

In cognee, a DataPoint is the core building block of a knowledge graph. Each DataPoint type defines both nodes (entities) and their connections (relationships), providing a structured way to model real-world information.

When concrete instances of DataPoints are created, they naturally form an interconnected graph, where each instance is a node and its fields define the edges. This makes it easy to store, query, and expand knowledge dynamically, without needing to rely on rigid database schemas.

Types of Nodes (Entities)

Each node in the graph has a type that reflects the real-world entity it represents:

• Person → Represents individuals (e.g., Alice)
• Object → Represents items (e.g., The Book)
• Location → Represents places (e.g., The Park)
• Event → Represents actions or occurrences (e.g., A Purchase, A Reading)

Types of Edges (Relationships)

Edges define how these entities interact. Each edge also has a type:

• by → Links an Event to the Person who performed it (e.g., Alice bought the book).
• of → Links an Event to the Object it involves (e.g., The Purchase event involved the book).
• at → Links an Event to the Location where it happened (e.g., Alice read the book at the park).

from cognee.infrastructure.engine import DataPoint

class Person(DataPoint):
    name: str
    age: int

    metadata: dict = {"index_fields": ["name"], "type": "Person"}

class Object(DataPoint):
    __tablename__ = "object"
    name: str
    pydantic_type: str = "Object"

    _metadata: dict = {"index_fields": ["name"], "type": "Object"}

class Location(DataPoint):
    __tablename__ = "location"
    name: str
    pydantic_type: str = "Location"

    _metadata: dict = {"index_fields": ["name"], "type": "Location"}

class Event(DataPoint):
    __tablename__ = "event"
    type: str  # Event type: "purchase" or "reading"
    by: Person  # Relationship: (Event) → (by) → (Person)
    of: Object  # Relationship: (Event) → (of) → (Object)
    at: Location = None  # Relationship: (Event) → (at) → (Location) (Optional)
    pydantic_type: str = "Event"

    _metadata: dict = {"index_fields": ["type", "by", "of"], "type": "Event"}

Now, using these definitions, we can instantiate nodes and edges for our example:

# Creating Nodes (Entities)
alice = Person(name="Alice", age=30)
book = Object(name="The Great Gatsby")
park = Location(name="Central Park")

# Creating a Purchase Event (Alice bought the book)
purchase_event = Event(type="purchase", by=alice, of=book)

# Creating a Reading Event (Alice read the book in the park)
reading_event = Event(type="reading", by=alice, of=book, at=park)

A Peek at the Practical Potential

Although our example is simple, it already shows how a few nodes and edges can capture meaningful relationships. Adding more details makes a knowledge graph grow and become more useful. Suppose we add:

1. Alice owns The Great Gatsby.
2. She purchased it at Barnes & Noble.

With this information, new entity types naturally emerge—such as bookstore, business, book, and author. As more related data is added, the graph expands naturally, with the same nodes getting referenced multiple times, resulting in a richer overall structure.

This structure isn’t just useful for data storage; it also makes searching and retrieval more effective. Well-established algorithms can traverse the network, following connections between nodes to retrieve subgraphs that contain relevant data.

These subgraphs can then be analyzed to uncover patterns, relationships, and insights that might otherwise be lost in a traditional relational database. Unlike relational storage, which often relies on complex JOIN operations, knowledge graphs allow for more direct, intuitive navigation of interconnected data.

Now, let’s step back and look at three examples of practical use cases where cognee’s knowledge graphs can make a difference.

Use Case 1: Enterprise Knowledge Management & Discovery

Companies generate a lot of data: reports, emails, meeting notes, onboarding docs, SOPs, and many other forms of internal documentation. Much of it can get lost in disconnected systems. Unlike traditional databases, however, knowledge graphs don’t rely on a fixed schema; they can organize this information into meaningfully interconnected networks, which grow flexibly as new data comes in.

With a system like cognee, this process happens automatically. Cognee ingests both structured and unstructured data, including documents, scanned files, images, and even audio, with built-in transcription support. Powered by DataPoints, it captures key facts and relationships without manual direction, then stores them in an informative, insightful, and intuitive knowledge graph.

Real-world application #1: In an enterprise context, cognee could ingest all of a company’s data, structuring it within a knowledge graph which might serve as the memory layer for an internal knowledge-sharing bot. This graph could be embedded with the company’s specific culture and language, ensuring retrievals that would align with the business’s ethos.

Use Case 2: Personalized Content & User Experience

In any system, each user forms a network of interactions by engaging with products, topics, and locations in ways that shape their experience over time. As we’ve seen, a knowledge graph doesn’t just store these interactions; it connects them to each other and to other parts of the data.

Following these connections can reveal unique patterns, and cognee offers various ways to uncover them based on the entities and relationships captured in the knowledge graph. Built-in searches for insights, summaries, and other intelligent queries based on more intricate graph concepts are also available.

Real-world application #2: Using cognee, an app’s or website’s home page can be made to update itself in real-time based on how a user interacts with it. This “auto-curation” would enable relevant content to be shown to the user dynamically, without the need for any manual revisions.

Use case 3: Healthcare Data Integration

In a healthcare institution, data comes from many sources: general medical knowledge, patient records, internal administrative data, etc. A knowledge graph can meaningfully connect all of this information, as well as create appropriate access tiers depending on user roles (i.e. doctors, nurses, admin staff, and patients all need access to different segments of the data).

Cognee already supports this functionality, making knowledge graphs practical for privacy-aware applications. We’re also in the middle of a major update to our user management system, with even more powerful features on the way.

Real-world application #3: A healthcare data management tool that integrates cognee could generate personalized reports for patients and tailored summaries for doctors and nurses, ensuring each user receives precisely the information they need in the most suitable format.

Tapping Into the Power of Knowledge Graphs

In this post, we explored the fundamentals of knowledge graphs and how they work in cognee, including nodes, relationships, and the process of extracting meaning from text. We introduced DataPoints, which serve as the building blocks of cognee’s AI-driven knowledge graphs, and we discussed practical use cases that hint at their vast potential.

Although it’s fun to workshop real-world applications, the above examples aren’t just theoretical—the tools to implement them are already available. Graph storage and querying are well-supported by Neo4j, FalkorDB, and libraries like NetworkX, and thanks to vector stores such as pgvector, AI integration is more accessible than ever. Cognee brings these pieces together by automating knowledge graph creation and interaction, making it possible to put the use cases we’ve discussed—and many others—into practice, right now.

Over the coming weeks, we’ll cover some of the heavier lifting that cognee does behind the scenes to make all we’ve talked about possible. We’ll look at how it extracts deeper meaning from text, links concepts by meaning, and enables more powerful AI reasoning. So, stay tuned to learn more about using knowledge graphs to make AI systems even smarter!

Join Our Community