Guide

What Is a Knowledge Graph in AI?

A knowledge graph is a designed representation of entities and explicit relationships. In AI systems, it gives applications reusable structure for identity, context, traversal, and integration. But the graph does not automatically make its contents complete, correct, current, or sufficient for a trustworthy answer.

Written by Ziqqur

At a glance

What is a knowledge graph?

A graph-based representation of entities and the relationships among them.

What makes it useful for AI?

It makes selected identities, relationship types, constraints, and context explicit and queryable.

Is it the same as a graph database?

No. A graph database is storage and query technology. A knowledge graph is an information representation that may use one.

Does every knowledge graph use an ontology?

No. Some use formal ontologies; others use lighter schemas, labels, and controlled vocabularies.

Can AI build a knowledge graph?

AI can help extract entities, propose relationships, classify records, and link references, but those outputs still need validation and maintenance.

Do knowledge graphs reduce hallucinations?

They may reduce some unsupported outputs when an application retrieves relevant, correct, current graph evidence and uses it properly. They do not eliminate hallucinations.

Do knowledge graphs provide provenance?

They can represent provenance when sources, versions, activities, and agents are recorded. A connected graph alone is not provenance.

Imagine an enterprise AI assistant receives this question:

Which customer incidents involve services owned by teams covered by the new escalation policy?

The answer may depend on which incidents affected which services, which team owns each service, which policy version is active, which teams fall within its scope, and which source record supports each relationship.

A document search system might retrieve relevant incident reports and policy passages. A knowledge graph can make the relationship chain explicit:

Incident 247 → Service Alpha → Team Atlas → Policy 3.2

That path is useful, but the graph still has to answer harder questions:

How does it know “Service Alpha” and “svc-alpha” are the same service?
Which source asserted that Team Atlas owns the service?
Is the ownership relationship current?
Was the policy relationship extracted by a model or recorded directly?
What happens when two sources disagree?

Those questions reveal what makes a knowledge graph more than a diagram of circles and arrows.

1Source records

Disconnected, inconsistently labeled documents

Incident reportService catalogTeam directoryPolicy document

2Entities

Resolved, canonical objects

Incident 247Service AlphaTeam AtlasPolicy 3.2

3Typed relationships

Explicit, directional connections

Incident →affected→ ServiceService →owned by→ TeamTeam →covered by→ Policy

4Context and evidence

Why the statement should be trusted

Valid fromSource recordVersionConfidenceReview status

A useful knowledge graph does more than connect records. It preserves identity, relationship meaning, context, and evidence.

Foundations

What Is a Knowledge Graph?

A knowledge graph in AI is a graph-based representation of entities and the relationships among them, used to give applications explicit identity, context, and connection.

Entities may represent people, organizations, documents, products, services, policies, events, places, concepts, or claims. Relationships make selected connections explicit, such as ownership, dependency, location, approval, citation, supersession, membership, or derivation.

The graph may also attach identifiers, types, timestamps, versions, jurisdictions, source systems, confidence values, and review status.

The broad knowledge-graph literature treats graph data models, query languages, schema, identity, context, construction, refinement, and quality as central concerns.¹

That matters because a graph is not useful merely because it contains nodes and edges.

Its usefulness depends on what those nodes and edges mean, how identities are resolved, how statements are supported, and how the graph changes over time.

Key insight

A knowledge graph is not a copy of reality.

It is a designed representation that decides which entities, identities, relationships, contexts, and evidence should remain explicit.

Central framework

The Five Layers of a Useful Knowledge Graph

A useful knowledge graph needs more than a set of connected records. A practical way to evaluate one is through five layers:

entities;
identity;
relationships;
context and constraints;
evidence and maintenance.

This is a practical editorial framework, not a formal industry standard.

Entities

What things exist?

IncidentServiceTeamPolicy

Identity

Which references mean the same thing?

AliasesStable IDsEntity resolution

Relationships

How are the entities connected?

AffectedOwned byCovered bySupersedes

Context and constraints

When and under what conditions does the relationship hold?

TimeScopeJurisdictionPermissionsVersion

Evidence and maintenance

Why should the statement be believed, and how does it change?

SourceExtraction methodReviewConflictSupersession

A knowledge graph becomes useful when it preserves entities, identity, relationships, context, and evidence over time.

1. Entities

Entities are the things the graph represents.

For the enterprise example, the entities may include:

Incident 247;
Service Alpha;
Team Atlas;
Escalation Policy 3.2;
Service Catalog Record 882.

An entity is more than a word in a document.

The graph needs some way to distinguish it from other entities and connect references to the same underlying thing.

2. Identity

Identity answers questions such as:

Does “Service Alpha” mean the same thing as svc-alpha?
Is “Atlas” the same team as “Platform Reliability”?
Is Policy 3.2 a new document or a revision of Policy 3.1?
Do two records refer to the same customer?

Identity may be represented through stable identifiers, canonical records, aliases, source-system IDs, entity-resolution rules, human review, or probabilistic matching.

Identity is one of the main reasons knowledge graphs can support relationship-heavy questions—and one of the main reasons they are difficult to build.

If two entities are merged incorrectly, the graph can create false relationships.

If one entity is split into several duplicates, the graph may miss important connections.

3. Relationships

Relationships describe how entities are connected.

In the enterprise example:

Incident 247 affected Service Alpha.
Service Alpha is owned by Team Atlas.
Team Atlas is covered by Policy 3.2.
Policy 3.2 supersedes Policy 3.1.

The relationship type matters.

“Owned by” is different from:

maintained by;
depends on;
approved by;
mentioned in;
similar to.

The direction can matter too.

Service Alpha is owned by Team Atlas

is not the same statement as:

Team Atlas is owned by Service Alpha.

A knowledge graph makes those distinctions explicit.

4. Context and Constraints

A relationship may only hold under certain conditions.

The graph may need to record when the relationship became valid or expired, which jurisdiction or policy version applies, which source supplied it, who may access it, what confidence level applies, and which business unit or tenant owns it.

For example:

Team Atlas is covered by Policy 3.2

may only be true:

after July 1;
in the United States;
for critical services;
while Policy 3.2 remains active.

Without that context, the graph can preserve a relationship but still mislead the application.

5. Evidence and Maintenance

A graph statement should ideally reveal where the relationship came from, whether it was recorded, extracted, inferred, or predicted, whether it was reviewed, whether other sources conflict, whether it was superseded, and when it was last checked.

Knowledge-graph construction research treats source integration, extraction, mappings, metadata, quality assurance, and incremental updates as major technical problems.²

A graph that cannot explain how its important relationships were created or updated may be hard to trust, even when the structure is easy to inspect.

Scope

Is Every Graph a Knowledge Graph?

No.

A graph is a general mathematical or computational structure consisting of nodes and edges.

Graphs can represent social networks, roads, dependencies, molecular structures, communication systems, state transitions, and many other relationships.

A graph becomes a knowledge graph when it is used to represent knowledge about a domain through entities and meaningful relationships, usually with some combination of identity, types, schema, context, or semantics.

There is no single universal threshold that every system must cross.

But a random collection of unlabeled nodes and edges is not automatically a useful knowledge graph.

The graph should support interpretation and reuse.

Terminology

Knowledge Graph vs. Graph Database

A graph database is a database system designed to store and query graph-structured data.

ISO/IEC 39075:2024 defines GQL for modeling, storing, querying, and modifying structured data represented as property graphs.³

A knowledge graph is an information representation.

It may be stored in:

a property-graph database;
an RDF triple store;
another graph-oriented system;
a combination of systems.

This means the terms overlap but are not synonyms.

A graph database can store a social network, routing graph, application dependency graph, fraud network, or knowledge graph.

A knowledge graph may also involve more than the database itself: identity services, extraction pipelines, source connectors, schemas, ontologies, validation, quality controls, publication layers, search, and AI applications.

Terminology

Knowledge Graph vs. Ontology

An ontology is a formal or semi-formal model of concepts, categories, properties, relationships, and constraints in a domain.

A knowledge graph usually contains instance-level statements.

For example, an ontology may define:

Service as a class;
Team as a class;
ownedBy as a relationship between services and teams;
CriticalService as a subclass of Service.

The knowledge graph may then contain:

Service Alpha is a Service.
Team Atlas is a Team.
Service Alpha is owned by Team Atlas.
Service Alpha is a Critical Service.

OWL 2 provides formally defined constructs for classes, properties, individuals, restrictions, equivalence, disjointness, and other ontology relationships.⁴

But not every knowledge graph uses a formal ontology.

Some use lightweight schemas, labels, controlled vocabularies, application conventions, or validation rules.

The distinction is useful:

An ontology describes the conceptual model. A knowledge graph contains represented statements about entities in that model.

In practice, terminology varies, and some systems blend the two.

Graph database

Role: Store and query graph-structured data

Contents: Nodes, edges, labels, properties

Neo4j-compatible property graph

Knowledge graph

Role: Represent domain entities and relationships

Contents: Identities, statements, context, sources

Service–team–policy graph

Ontology

Role: Define concepts and constraints

Contents: Classes, properties, restrictions, axioms

Service, Team, ownedBy

A knowledge graph may use a graph database and may be structured by an ontology, but the three terms are not interchangeable.

Data models

How Knowledge Graphs Are Represented

Knowledge graphs can use different data models.

Two important families are:

RDF graphs;
property graphs.

RDF Graphs

RDF is a W3C graph data model.

It represents information through subject-predicate-object triples.⁵

For example:

Service Alpha — owned by — Team Atlas

The three parts are:

subject: Service Alpha;
predicate: owned by;
object: Team Atlas.

RDF uses IRIs to identify resources and properties.⁵

RDF datasets can also include a default graph and named graphs. How named graphs are interpreted as context or provenance depends on the application rather than on one universal RDF-dataset meaning.⁵

SPARQL is a W3C query language for RDF graphs.⁷

A SPARQL query can match graph patterns, including required, optional, and combined relationships.

Property Graphs

Property graphs typically represent:

nodes;
relationships;
labels;
properties.

For example:

a node labeled Service;
a node labeled Team;
a relationship labeled OWNED_BY;
a property such as validFrom: 2026-01-10.

Property graphs are common in graph databases and application development.

GQL provides a standardized language for property-graph data.³

Which Model Is Better?

There is no universal answer.

The choice may depend on interoperability, standards requirements, query patterns, infrastructure, ontology needs, developer tooling, performance, data exchange, and application design.

The article’s main concept does not depend on choosing one model.

Both approaches can represent entities and explicit relationships.

Construction

How Is a Knowledge Graph Built?

A knowledge graph is not created merely by selecting a graph database.

A production graph may be built through a pipeline.

1. Define the Use Case

Start with the questions and workflows the graph must support.

For example:

Which services are affected by this incident?
Which policies apply to this team?
Which products depend on this component?
Which claims cite the same evidence?

The use case determines which entities and relationships deserve explicit representation.

2. Select Sources

Sources may include relational databases, documents, APIs, spreadsheets, logs, catalogs, taxonomies, existing knowledge bases, and human expertise.

3. Define Entities and Relationships

The graph needs a model.

The team must decide:

what counts as an entity;
which entity types exist;
which relationship types exist;
which properties matter;
what context must be preserved.

4. Extract or Map Records

Structured sources may be mapped directly.

Unstructured sources may require:

named-entity recognition;
relation extraction;
classification;
document parsing;
language-model extraction;
human annotation.

5. Resolve Identity

References from different sources must be linked or kept separate.

This may involve:

exact identifiers;
deterministic rules;
probabilistic matching;
embedding similarity;
human review.

6. Assert, Infer, or Propose Relationships

A relationship may be:

recorded directly in a source;
asserted manually;
mapped from a database field;
inferred from rules;
predicted by a model;
proposed for review.

Those are different evidential situations.

The graph should not present all of them as equally certain unless that is justified.

7. Attach Context and Evidence

Important statements may need:

source identifiers;
source passages;
timestamps;
versions;
extraction methods;
confidence;
review status;
validity intervals;
agent or author information.

8. Validate

Validation may include:

schema checks;
ontology checks;
duplicate detection;
conflict detection;
source verification;
human review;
test queries;
quality metrics.

9. Publish and Query

The graph is loaded into a system where applications can query or traverse it.

10. Update and Govern

The graph must handle:

new records;
deleted records;
changed identities;
superseded policies;
conflicting claims;
schema evolution;
access control;
versioning;
reprocessing.

The construction process is continuous.

1Sources

2Parsing and mappingMapped

3Entity extractionExtracted

4Identity resolution

5Relationship assertion or inferenceInferred

duplicate entity · unsupported edge

6Context and evidence attachmentRecorded

7ValidationReviewed

stale relationship · conflicting source

8Published graph

Updates, conflicts, and supersession — update, validate, republish

A knowledge graph is built through source integration, identity resolution, relationship construction, validation, and ongoing maintenance.

AI-assisted construction

Can AI Build a Knowledge Graph?

AI can help build a knowledge graph by extracting entities, proposing relationships, classifying entity types, linking references, summarizing records, suggesting schema mappings, detecting duplicates, or generating graph queries.

Knowledge-graph research includes representation learning, acquisition and completion, temporal knowledge graphs, and knowledge-aware applications as major areas.⁸

But AI-generated graph content introduces risk.

A model may invent an entity, infer an unsupported relationship, merge different entities, split one entity into duplicates, ignore uncertainty, miss temporal qualifiers, overgeneralize from one passage, or create inconsistent edge labels.

A graph generated by AI is not trustworthy merely because it is structured.

The extraction process should distinguish:

what the source explicitly states;
what the system infers;
what the model predicts;
what has been reviewed.

Knowledge graph → AI

Graph supplies

IdentityRelationshipsConstraintsContextEvidence

AI application uses for

RetrievalQuestion answeringRecommendationsGraphRAGWorkflow support

Using a graph and building a graph are different trust problems.

AI → knowledge graph

AI proposes

EntitiesRelationshipsClassificationsAliasesSummaries

Validation gate

Source checkSchema checkConfidence thresholdHuman reviewConflict detection

Knowledge graphs can supply structure to AI systems, while AI can help construct graphs. Model-generated additions still require validation.

Applications

How Do AI Systems Use Knowledge Graphs?

AI systems may use knowledge graphs in several ways.

Entity Resolution

The graph can help an application map different references to the same entity.

For example:

“Service Alpha”
svc-alpha
“Authentication API”

may resolve to one service.

Relationship-Aware Retrieval

A system can retrieve information based on explicit connections.

For example:

Find incidents connected to services owned by Team Atlas.

Multi-Hop Questions

The system can follow several relationships:

policy → team → service → incident → customer

This is useful when the answer depends on facts distributed across sources.

Recommendations

A graph can support recommendations based on:

shared attributes;
paths;
communities;
dependencies;
user-item relationships.

Fraud and Risk Analysis

Graphs can reveal:

shared accounts;
suspicious transaction chains;
hidden ownership;
repeated counterparties;
unusual network structures.

Data Integration

A knowledge graph can connect records from multiple systems through shared entities and identifiers.

Question Answering

Many knowledge-graph question-answering systems translate a natural-language question into a structured query and separately resolve entities mentioned in the question.⁹

The graph does not answer a natural-language question by itself.

The application still needs:

entity linking;
query generation;
result interpretation;
answer formatting.

Retrieval

Knowledge Graphs in RAG and GraphRAG

A knowledge graph can support retrieval-augmented generation.

Instead of retrieving only semantically similar text chunks, the system may also retrieve:

connected entities;
relationship paths;
graph neighborhoods;
hierarchy information;
community summaries;
graph-scoped documents.

Microsoft Research currently describes GraphRAG as an end-to-end technique combining text extraction, network analysis, and LLM prompting and summarization.¹⁰

One influential GraphRAG paper constructs an entity graph from source text, organizes the graph into communities, generates community summaries, and uses those summaries for broad questions over a corpus.¹¹

That is one GraphRAG architecture.

The term is also used for other combinations of:

graph construction;
graph traversal;
vector search;
graph expansion;
reranking;
generation.

GraphRAG is not a single standardized system.

A future dedicated article should cover it in greater depth.

Related architecture

Knowledge Graph vs. Vector Database

A vector database and a knowledge graph solve different retrieval problems.

A vector database makes learned similarity searchable.

A knowledge graph makes selected entities and relationships explicit and traversable.

Vector retrieval is often useful for:

semantic passage search;
multimedia similarity;
recommendations;
retrieval across different wording.

Knowledge graphs are often useful for:

stable identity;
relationship traversal;
multi-hop questions;
explicit constraints;
graph-wide integration.

The two can be combined.

For the architectural tradeoffs, see Knowledge Graph vs. Vector Database.

Trust boundary

Knowledge Graphs and Provenance

A graph can represent provenance.

The W3C PROV model describes provenance through entities, activities, agents, and derivations.¹²

For example, a graph may represent that:

Incident 247 was generated from Log Bundle 19;
the incident-service relationship was extracted by Process 4;
Service Catalog Record 882 asserted the ownership relationship;
Reviewer A approved the mapping;
Policy 3.2 superseded Policy 3.1.

PROV-O defines an OWL 2 encoding of the PROV data model for representing and exchanging provenance information.¹³

But not every knowledge graph contains provenance.

A graph may show:

Incident 247 → Service Alpha → Team Atlas → Policy 3.2

without recording:

which source supplied each edge;
which version was active;
whether the edge was inferred;
when it was used;
whether it participated in an AI answer.

A connected path is not automatically provenance.

To claim answer provenance, the system must record what was actually retrieved, used, transformed, or applied. For the broader framework, see What Is AI Provenance?

Possible support path (domain graph)

IncidentServiceTeamPolicy

This path exists in the graph.

Possible support ≠ recorded execution

Recorded answer provenance

Query timestamp

Graph version

Source record

Source passage

Extraction method

Reviewer

Retrieved nodes and edges

Final claim

This records what was used and how the claim was produced.

A graph can show that entities are connected. Provenance records where the relationships came from and whether they participated in producing an answer.

Strengths

What Are Knowledge Graphs Good At?

Knowledge graphs are especially useful when the application needs stable entity identity, explicit relationship types, multi-hop traversal, integration across systems, hierarchy and dependency queries, contextual constraints, reusable domain structure, inspectable relationship paths, source-linked assertions, or graph-based analytics.

They become especially valuable when the same entities and relationships support many workflows.

A graph built for one narrow chatbot question may not justify its maintenance cost. A graph reused across search, recommendations, analytics, governance, incident response, policy evaluation, integration, and AI retrieval may become a durable organizational asset.

Tradeoffs

What Do Knowledge Graphs Cost?

A knowledge graph introduces operational costs.

Modeling

The team must decide what to represent.

Entity Resolution

Duplicate and ambiguous references must be reconciled.

Extraction

Unstructured sources must be parsed and mapped.

Validation

Relationships and claims must be checked.

Schema Evolution

The domain model changes.

Freshness

Relationships can expire or become outdated.

Conflict Handling

Sources may disagree.

Permissions

Sensitive entities and relationships require access controls.

Evaluation

The team needs to test whether the graph supports the intended queries.

Maintenance

The graph must be updated, monitored, and governed over time.

The difficult part is rarely drawing the graph.

The difficult part is keeping the represented knowledge useful.

Limits

What Knowledge Graphs Do Not Guarantee

A knowledge graph does not automatically guarantee truth, completeness, currentness, correct identity resolution, correct relationships, correct reasoning, explainability, provenance, hallucination-free AI, deterministic behavior, legal compliance, or fair outcomes.

A graph can exactly return an outdated relationship, expose a clean path through incorrect data, link to a source that does not support the claim, or include model-generated edges that were never reviewed. It can be structurally valid and still be wrong.

A knowledge graph improves what the system can represent and query.

It does not remove the need for:

source governance;
validation;
version control;
process records;
evaluation;
authorization;
abstention when evidence is insufficient.

Checklist

How to Evaluate a Knowledge Graph

Ask these questions.

1. What are the entities?

Are the graph’s main objects clearly defined?

2. How is identity resolved?

How are aliases, duplicates, and conflicts handled?

3. What do the relationships mean?

Are edge types precise, directional, and documented?

4. What context is preserved?

Does the graph record time, version, scope, jurisdiction, source, or confidence where necessary?

5. Where did the statements come from?

Can important nodes and edges be traced to source records?

6. What was extracted or inferred?

Does the graph distinguish direct records from model predictions or rule-derived relationships?

7. How is quality validated?

Are there schema checks, tests, human review, and conflict detection?

8. How is the graph updated?

What happens when sources change, policies are superseded, or entities merge?

9. What can the graph answer reliably?

Are the supported query patterns clear?

10. What does the graph not know?

Does the system expose missing or uncertain relationships rather than silently assuming them?

Frequently asked questions

What is a knowledge graph in simple terms?

A knowledge graph is a structured map of things and how they are related.

Unlike a simple visual diagram, it usually uses stable identifiers, relationship types, properties, and queryable structure.

Is a knowledge graph a database?

A knowledge graph is an information representation.

It is often stored in a graph database or triple store, but the graph may also depend on extraction, identity, schema, validation, and governance systems around the database.

What is the difference between a knowledge graph and an ontology?

An ontology defines concepts, categories, properties, relationships, and constraints.

A knowledge graph contains represented statements about entities, often using the ontology or schema.

Not every knowledge graph uses a formal ontology.

How are knowledge graphs used in AI?

They are used for:

entity resolution;
retrieval;
multi-hop questions;
recommendations;
data integration;
graph analytics;
RAG;
question answering;
agent context.

Can AI build a knowledge graph?

AI can help extract entities, propose relationships, classify records, and link references.

Those outputs still need validation because models can invent, merge, omit, or misclassify graph content.

What is GraphRAG?

GraphRAG is a family of retrieval-augmented generation approaches that use graph-derived structure or graph retrieval.

It is not one standardized architecture.

Do knowledge graphs prevent hallucinations?

No.

They may reduce some unsupported outputs when relevant, correct, current graph evidence is retrieved and used properly.

They do not eliminate model errors. See What Are AI Hallucinations?

Are knowledge graphs explainable?

Their explicit nodes, edges, and paths can make some relationships easier to inspect.

But a graph path does not automatically explain how a final AI answer was produced.

Can knowledge graphs and vector databases work together?

Yes.

A graph can define entities, relationships, and constraints, while vector search retrieves semantically similar passages or media.

Hybrid systems are common when both capabilities are needed, but they add synchronization and orchestration costs.

Does every knowledge graph use RDF?

No.

Some use RDF and SPARQL.

Others use property graphs, GQL, Cypher, Gremlin, or custom graph representations.

Closing

Conclusion

A knowledge graph is more than a collection of nodes and edges. It is a designed representation of entities, identity, relationships, context, and evidence.

Its value comes from making selected distinctions explicit and reusable.

That can help AI systems retrieve context, follow relationships, integrate sources, and answer multi-step questions. But the graph is only as useful as the sources, identities, relationships, constraints, and maintenance processes behind it.

A graph can support trustworthy AI.

It does not create trust automatically.

When a system must defend an answer, the graph should not only show what is connected.

It should also preserve where important relationships came from, what version was active, what was inferred, and what actually participated in producing the result.

Where Ziqqur fits

Ziqqur’s public position should stay narrower than “knowledge graphs make AI trustworthy.” The relevant problem is whether a high-liability answer can be connected to approved source versions, exact evidence, processing history, and visible gaps when the available record is insufficient.

See how Ziqqur approaches source-traced answers

References

1.
Aidan Hogan et al.. Knowledge Graphs. ACM Computing Surveys, 2021. https://arxiv.org/abs/2003.02320
2.
Marvin Hofer, Daniel Obraczka, Alieh Saeedi, Hanna Köpcke, and Erhard Rahm. Construction of Knowledge Graphs: State and Challenges. 2023. https://arxiv.org/abs/2302.11509
3.
International Organization for Standardization. ISO/IEC 39075:2024, Information Technology — Database Languages — GQL. https://www.iso.org/standard/76120.html
4.
World Wide Web Consortium. OWL 2 Web Ontology Language Primer, Second Edition. December 11, 2012. https://www.w3.org/TR/owl2-primer/
5.
World Wide Web Consortium. RDF 1.1 Concepts and Abstract Syntax. February 25, 2014. https://www.w3.org/TR/rdf11-concepts/
6.
World Wide Web Consortium. RDF Schema 1.1. February 25, 2014. https://www.w3.org/TR/rdf-schema/
7.
World Wide Web Consortium. SPARQL 1.1 Query Language. March 21, 2013. https://www.w3.org/TR/sparql11-query/
8.
Shaoxiong Ji et al.. A Survey on Knowledge Graphs: Representation, Acquisition, and Applications. 2020. https://arxiv.org/abs/2002.00388
9.
Daniel Diomedi and Aidan Hogan. Question Answering over Knowledge Graphs with Neural Machine Translation and Entity Linking. 2021. https://arxiv.org/abs/2107.02865
10.
Microsoft Research. Project GraphRAG. https://www.microsoft.com/en-us/research/project/graphrag/
11.
Darren Edge et al.. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. 2024. https://www.microsoft.com/en-us/research/publication/from-local-to-global-a-graph-rag-approach-to-query-focused-summarization/
12.
World Wide Web Consortium. PROV-DM: The PROV Data Model. April 30, 2013. https://www.w3.org/TR/prov-dm/
13.
World Wide Web Consortium. PROV-O: The PROV Ontology. April 30, 2013. https://www.w3.org/TR/prov-o/