Achieving Production-Quality Knowledge Graphs: Challenges with Ontology Enforcement, Temporal Linking, and Graph Topology

[NSK-DV]

Discussion: Achieving Production-Quality Knowledge Graphs with Cognee (Resume/CV Use Case)

Context

We have been evaluating Cognee (v0.5.1 through v0.5.3) for building knowledge graphs from professional documents.
Our objective is to understand how to achieve production-quality graph output with:

• Structured entities
• Typed relationships
• Temporal attributes
• Deduplication across documents

Below we describe our use case, implementation approach, observed issues, and key questions.

---

1. Use Case — Resume / CV Knowledge Graph

We aim to ingest professional resumes (PDFs) and build a temporal knowledge graph capable of answering reasoning queries such as:

• What skills does this person have?
• Where did they work and in what roles?
• What did they publish, and when?
• How did their career evolve over time (e.g., roles in 2013 vs 2019)?
• Which organizations are connected through shared employees?
• What is the temporal progression across multiple CV updates?

These are not keyword search problems. They require structured entities, typed relationships, and temporal reasoning over a traversable graph.

---

2. Ingestion Pipeline

We used Cognee’s standard API with the FalkorDB community adapter:

import cognee

cognee.config.set_llm_config(...)
cognee.config.set_vector_db_config(...)

await cognee.add(file_path)
await cognee.cognify(temporal_cognify=True)
Test Document

A 5-page academic CV (Thanh CV.pdf) containing:

Education: 2 degrees

Employment: 4 positions

Other experience: 4 entries

Honors: 5

Research awards: 2

Publications: 23

Patents: 2

Presentations: 4

Software projects: 1

Skills: 21

Personal statement

3. Custom Extraction Prompt and OWL Ontology
a) Extraction Prompt

We provided a detailed extraction prompt (approximately 65 lines) defining:

Entity Types (16)

Person, Organization, Role, Skill, Project

Education, Certification, Location, Award

Publication, Patent, Course, Internship

VolunteerRole, Achievement, Language

Relationship Types (15+)

employment, studiedAt, heldRole, skilledIn

builtProject, certifiedAs, awardedBy

published, patented, coursesAt

internAt, volunteeredAt, achievedIn

locatedIn, speaks

Quality Rules

Always connect entities

Use specific relationship names

Handle publications and patents correctly

b) OWL Ontology

We also provided a complete OWL ontology (200+ lines) including:

Classes (17+)

Person, Organization, Role, Skill, Project

Education, Certification, Location, Award

Publication, Patent, Course, Internship

VolunteerRole, Achievement, Language

Event Subclasses

EmploymentEvent

EducationEvent

ProjectEvent

AwardEvent

PublicationEvent

PatentEvent

InternshipEvent

Temporal Modeling

TimeSpan aligned with OWL Time Interval for temporal anchoring

4. Observed Graph Quality Issues

After ingestion and cognify, the graph showed the following issues:

a) Star Topology and Leaf Node Problem

Approximately 91.5 percent of nodes were leaf nodes

Nodes were connected only via generic ASSOCIATED_WITH edges

Only 8.5 percent of nodes had two or more meaningful relationships

b) Incorrect Hub Entity

Most connected node: "Starbucks Customers"

Expected: "Starbucks Corporation"

This indicates incorrect semantic anchoring.

c) Noisy and Generic Relationships

Edges such as: "is associated with financial metric"

Not aligned with defined schema

Ontology Not Enforced

Duplicate relationship variants observed:

SUBJECTTO vs SUBJECT TO

SEGMENTREVENUE vs SEGMENT REVENUE

This suggests the ontology is not enforced during extraction.

d) Missing Temporal Model

No valid_at or invalid_at properties

No temporal edges such as:

IN_PERIOD

YEAR_OVER_YEAR

NEXT_PERIOD

The temporal_cognify=True flag did not produce usable temporal structure.

e) No Deduplication

Each pipeline run creates new UUIDs

Re-ingesting the same document results in duplicate entities

There is no merge or upsert mechanism.

f) No Provenance

Approximately 1 percent source page coverage

No reliable linkage between entities and source text

This prevents traceability.

g) Low Skill Extraction Recall

Extracted: 9 out of 21 skills (approximately 43 percent recall)

Missing:

Soft skills (leadership, mentoring, training)

Technical skills (statistics, linear algebra, algorithm development, programming)

5. Core Questions

Our primary question:

Why is Cognee not able to produce a structured, connected, temporal knowledge graph suitable for reasoning across documents and across time?

Specific Questions
1. Ontology Usage

When we provide an OWL ontology:

Is it used during extraction (schema-first)?

Or only for post-processing / validation?

Our observations suggest post hoc usage only.

2. Temporal Cognify

How is temporal_cognify=True intended to work?

Should it generate temporal edges?

Should it assign validity intervals?

Should it link entities across time?

Currently, no temporal structure is produced.

3. Graph Connectivity

How can we ensure:

Typed relationships instead of generic edges

Multi-hop connectivity between entities

Avoidance of star topology

4. Deduplication and Entity Resolution

Is there a supported strategy for:

Entity resolution across documents

Merge / upsert logic

Linking overlapping entities across multiple ingestions

6. Goal

We aim to build a production-grade temporal knowledge graph capable of:

Multi-hop reasoning

Cross-document entity linking

Temporal querying

Schema consistency

High recall extraction

7. Request

We would appreciate guidance on:

Best practices for enforcing schema and ontology

Proper use of ontology within Cognee

Temporal modeling capabilities

Deduplication and entity resolution strategies

Recommended architecture for production-quality graph construction

Thank you.

[akhil-dv]

@Vasilije1990 , can you please have a look at this use case and suggest?

[jagmarques]

The star topology and generic ASSOCIATED_WITH edges suggest the LLM extraction is not actually using your ontology as a hard constraint during entity/relationship extraction - it is likely used as a hint at best.

Two things that help in practice:

1. Schema-first extraction with structured output. Instead of relying on the framework to enforce your ontology, use a function-calling / structured output approach where the LLM must return entities and relationships matching your exact schema. This eliminates the generic edge problem entirely.

2. Deduplication via entity resolution. Run a post-processing pass that does fuzzy matching on entity names + types, then merge duplicates. For temporal linking, attach valid_from/valid_to as node properties during extraction rather than relying on the framework to infer them.

The provenance gap (1% source coverage) is the hardest part. You need to pass chunk-level references through the extraction pipeline so each entity traces back to its source span.

[Vasilije1990]

@akhil-dv please write to me at vasilije@cognee.ai and our team can schedule a call and help

[kinthaiofficial]

Achieving production-quality knowledge graphs for agents hits several fundamental tensions:

Ontology enforcement vs. schema flexibility. Strict ontologies give you consistent, queryable graphs but break when agents encounter entity types that don't fit the predefined schema. Loose schemas let agents capture anything but make downstream querying unreliable ("what does this edge type mean again?"). Our pragmatic approach: core ontology for well-understood entity types (Person, Task, Decision, Artifact), with a properties bag for novel attributes. This preserves queryability for the common case while not blocking novel observations.

Temporal linking is hard because agents don't always timestamp correctly. Agents sometimes reason about past events ("what we decided last week") without providing explicit timestamps. To build accurate temporal links, you need to either extract implicit timestamps from conversation context or attach "event ordering" metadata (this event happened before/after X) rather than requiring absolute timestamps.

Graph topology drifts over time. Agents keep adding nodes and edges, but they don't clean up outdated relationships. An agent might add "is_working_on: Task X" and never remove it when Task X completes. We solve this with confidence scores + decay: edges that were true at time T but haven't been reinforced get their confidence score decayed. Below a threshold, they're treated as historical (not authoritative) rather than being deleted.

The MESI coherency problem for shared graphs. When multiple agents read and write the same graph, you get stale reads. We use a simplified coherency protocol: before writing to a graph node, invalidate other agents' cached views of that node. This adds latency but prevents agents from making decisions on outdated graph state.

Memory architecture details: https://blog.kinthai.ai/why-character-ai-forgets-you-persistent-memory-architecture