Knowledge Graphs and LLMs in Action you own this product

Build AI systems using connected data

Alessandro Negro with Vlastimil Kus, Giuseppe Futia and Fabio Montagna
Forewords by Maxime Labonne, Khalifeh AlJadda

October 2025
ISBN 9781633439894
472 pages

Included with a Manning Online subscription

printed in black & white

available in Polish, Russian, Simplified Chinese

catalog / Data Science / Machine Learning / Knowledge Graphs

resources: Source code Supplememental material Book forum Source code on Github Register your pBook for a free eBook

table of content

Part 1 Foundations of hybrid intelligent systems

1 Knowledge graphs and LLMs: A killer combination

1.1 Knowledge graphs

1.2 Large language models

1.3 KGs and LLMs: Stronger together

1.4 The paradigm shift in data-driven applications

1.4.1 The four pillars of knowledge graphs

1.5 Building data-driven applications using KGs and LLMs

1.5.1 Example use case: Drug discovery and development

1.5.2 Example use case: Conversational AI for customer support

1.5.3 Deciding whether to use a KG

1.6 Knowledge graph technologies

1.6.1 Taxonomies and ontologies

1.7 How do we teach KGs and LLMs?

2 Intelligent systems: A hybrid approach

2.1 What is intelligence?

2.2 Designing an intelligent system

2.2.1 What is an intelligent system?

2.2.2 Categories of intelligent systems

2.2.3 Characteristics of an intelligent system

2.3 Knowledge acquisition and representation

2.4 Reasoning

2.5 Reasoning engines

2.5.1 Limitations of a pure deductive reasoning engine

2.5.2 Using inductive reasoning and ML

2.5.3 The role of LLMs in the reasoning engine

2.6 A KG approach to IASs

Part 2 Building knowledge graphs from structured data sources

3 Create your first knowledge graph from ontologies

3.1 Knowledge graph building: Warmup

3.1.1 Business and domain understanding

3.1.2 Data understanding

3.2 Understanding knowledge graph technologies

3.2.1 RDF or LPG? A goal-driven discussion

3.2.2 Representing edge properties with RDF and LPG

3.3 Building a knowledge graph

3.3.1 Ontology ingestion and processing with neosemantics

3.3.2 Annotation ingestion and processing

3.4 Querying the data

3.5 Reasoning over the KG

4 From simple networks to multisource integration

4.1 Biomedical knowledge graphs and applications

4.2 Multi-omic applications of KGs

4.2.1 Creating a KG from the PPI and protein-disease networks

4.2.2 High-level analysis of the resulting KGs

4.2.3 Domain-specific analysis of the PPI and disease KG

4.3 Pharmaceutical applications of KGs

4.3.1 Deep analysis of the Hetionet knowledge graph

4.3.2 LLM-assisted interpretation of pathway analysis results

4.4 Clinical applications of KGs

4.4.1 LLM-guided clinical decision support analysis

Part 3 Building knowledge graphs from text

5 Extracting domain-specific knowledge from unstructured data

5.1 The archives challenge

5.2 Key concepts of knowledge extraction

5.2.1 Recognizing named entities

5.2.2 Extracting relations

5.3 Building KGs with large language models

5.3.1 Using LLMs

5.3.2 Prompt engineering examples

5.3.3 Prompt engineering guidelines

5.3.4 KG building: Traditional NLP or LLMs?

6 Building knowledge graphs with large language models

6.1 Transforming an archive to a KG

6.1.1 Graph modeling

6.1.2 Creating a metagraph

6.1.3 Normalization and cleansing

6.1.4 Graph-based entity resolution

6.2 Intellectual network analysis: The value of graphs

6.3 Next steps in the Rockefeller Archive Center project

6.4 The value of knowledge graphs in the LLM era

7 Named entity disambiguation

7.1 From recognition to disambiguation

7.2 Understanding named entity disambiguation

7.3 Domain-based NED and LLMs

7.4 Business and domain understanding

7.4.1 Context

7.4.2 Use case definition

7.5 Understanding the data

7.5.1 Unstructured data

7.5.2 Domain ontologies

7.6 Building a SoHO knowledge graph

7.6.1 Defining the schema

7.6.2 Processing and ingesting documents

7.6.3 Disambiguating and ingesting medical entities

7.6.4 Processing, loading, and mapping ontologies

7.6.5 Generating entity co-occurrences

7.7 KG-based use cases

7.7.1 Conceptual search

7.7.2 Structured knowledge-based search

7.7.3 KG-based interpretability and discovery

7.7.4 Uncovering new knowledge

8 NED with open LLMs and domain ontologies

8.1 Understanding limitations of traditional NED systems

8.2 Ingesting the domain ontology

8.3 Setting up the model with Ollama and Llama 3.1 8B

8.4 End-to-end NED process

8.4.1 Named entity recognition

8.4.2 Candidate selection

8.4.3 Candidate disambiguation

8.5 Conclusions

Part 4 Machine learning on knowledge graphs

9 Machine learning on knowledge graphs: A primer approach

9.1 Machine learning on graphs: Why?

9.2 Machine learning on graphs: What?

9.2.1 Node classification

9.2.2 Link prediction (a.k.a. relationship prediction)

9.2.3 Clustering and community detection

9.2.4 Graph classification

9.3 Machine learning on graphs: How?

9.3.1 Node classification and link prediction

9.3.2 Graph classification

9.3.3 Graph clustering

10 Graph feature engineering: Manual and semiautomated approaches

10.1 Manual node features

10.1.1 Degree

10.1.2 Triangles

10.1.3 Density

10.1.4 Geodesic (or shortest) path

10.1.5 Closeness

10.1.6 Betweenness

10.1.7 PageRank

10.1.8 Prediction

10.2 Manual relationship features

10.2.1 Node-based representation

10.2.2 Path-based features

10.3 Semiautomated feature extraction

10.3.1 Performing ReFeX manually

10.3.2 Performing ReFeX automatically with code

11 Graph representation learning and graph neural networks

11.1 Embeddings in graph representation learning

11.1.1 Understanding graph embeddings: From discrete to continuous

11.1.2 Real-world applications and examples

11.2 The encoder–decoder model

11.2.1 The encoder: Converting graph structure to vectors

11.2.2 The decoder: Reconstructing graph properties

11.2.3 The power of the framework

11.2.4 Node2Vec: An example of an encoder–decoder framework

11.3 Shallow embeddings: A first approach to graph representation

11.3.1 Understanding shallow embeddings

11.3.2 Limitations of shallow embeddings

11.4 Embeddings in knowledge graphs

11.4.1 Loss function

11.4.2 Multirelationship decoder

11.5 Message passing and graph neural networks

11.5.1 The message-passing framework: A neural conversation

11.5.2 Motivation and intuition: Why message passing works

11.5.3 The basic GNN model

11.5.4 Message passing with self-loops

11.6 Generalized aggregation and update methods

11.6.1 Neighborhood normalization

11.6.2 Neighborhood attention

11.6.3 Multihead attention and transformer connections

11.6.4 Generalized update methods

11.7 The synergy of GNNs and LLMs

12 Node classification and link prediction with GNNs

12.1 Node classification for anti-money laundering applications

12.1.1 Input data

12.1.2 Graph processor: Data preparation

12.1.3 Graph processor: Homogeneous PyG graph

12.1.4 Encoder–decoder architecture

12.1.5 Evaluation and analysis

12.2 Link prediction for movie recommendations

12.2.1 Input data

12.2.2 Graph processor: Data preparation

12.2.3 Graph processor: Heterogeneous PyG graph

12.2.4 Encoder–decoder architecture

12.2.5 Evaluation and analysis

Part 5 Information retrieval with knowledge graphs and LLMs

13 Knowledge graph–powered retrieval-augmented generation

13.1 AI agents

13.2 Chatting with the LLM

13.3 Challenges in the production environment

13.4 Chatting with the AI about private data

13.4.1 Retrieval-augmented generation

13.4.2 Vector-based RAG limitations

13.4.3 Graph RAG

13.4.4 Reasoning agents

13.4.5 Let’s chat with our KG

14 Asking a KG questions with natural language

14.1 Querying a knowledge graph in the policing domain

14.1.1 Enabling domain experts with knowledge graphs

14.2 RAG for KG querying: Capabilities and challenges

14.2.1 RAG effectiveness with complete context

14.2.2 RAG fragility with incomplete retrieval

14.3 Schema-based approach for querying KGs

14.3.1 Understanding and using graph schemas

14.4 Think like an expert: Using metadata for enhanced querying

14.5 Intent detection: Understanding user expectations

14.5.1 Classifying by visualization type

14.5.2 Is it data, documentation, or just complaining?

14.6 From schema to LLM-ready context

14.6.1 Schema extraction and representation

14.6.2 Enriching schemas with descriptive annotations

14.6.3 A practical approach to schema representation

14.7 It’s time to think: Understanding LLM reasoning

14.7.1 The order matters: Answer first vs. reasoning first

14.7.2 Thinking in queries: From text to Cypher

14.7.3 Structuring output for reliable query generation

14.8 Response summarization: From results to insights

15 Building a QA agent with LangGraph

15.1 Building the LangGraph pipeline

15.1.1 System architecture overview

15.1.2 Configuring pipeline components

15.1.3 Schema translation service

15.1.4 State management design

15.1.5 Pipeline agent implementation

15.1.6 Pipeline integration layer

15.2 Streamlit application

15.2.1 Application overview

15.2.2 LangGraph integration

15.3 Expert-emulating investigation

15.3.1 Identifying the initial case

15.3.2 Spatial analysis of surveillance coverage

15.3.3 Vehicle pattern detection

15.3.4 Context-aware request refinement

15.3.5 Historical record analysis

15.4 Future directions and enhancements

15.4.1 Learning from use

15.4.2 Enhancing core capabilities

15.4.3 Advanced evolution paths

Appendixes

Appendix A: Introduction to graphs

A.1 What is a graph?

A.2 Graphs as models of networks

A.3 Representing graphs

Appendix B: Neo4j

B.1 Introduction to Neo4j

B.2 Installing Neo4j

B.2.1 Installing a Neo4j server

B.2.2 Neo4j Desktop installation

B.3 Cypher

B.4 Installing plugins

B.4.1 Installing APOC Core

B.4.2 GDS installation

B.5 Cleaning

Appendix C: Building knowledge graphs from structured sources

C.1 MicroRNA–disease association: Warmup

C.1.1 Key concepts

C.1.2 Business understanding

C.1.3 Data understanding

C.2 Building the miRNA knowledge graph

C.2.1 Importing known miRNA–disease connections

C.2.2 Importing the disease ontology

C.2.3 Importing miRNA information

C.3 Exploring and analyzing the miRNA KG

Appendix D: references

Overview

3 Create your first Knowledge Graph from ontologies

Building a useful knowledge graph starts with business goals and data understanding, not technology. The chapter frames knowledge graph construction as a semantic integration problem: fusing heterogeneous data sources that differ by format, storage, syntax, and—crucially—meaning. It proposes using ontologies as a reference schema and controlled vocabulary to harmonize synonyms, disambiguate acronyms, and align different levels of granularity. Grounding the discussion in a clinical use case—supporting clinicians who must recognize rare diseases—the chapter adopts the Human Phenotype Ontology and an ontology-annotated dataset to create a unified, queryable representation that preserves provenance and enables exploration of disease–phenotype relationships.

The chapter compares the main knowledge graph technologies through a goal-driven lens. RDF excels at standardized, interoperable representations and rich semantics for reasoning, but requires modeling patterns (n-ary relations, named graphs, or RDF-star) to attach metadata to specific assertions. Labeled Property Graphs attach properties directly to nodes and edges, making them efficient and intuitive for relationship-centric metadata such as evidence, source, frequency, onset, and curation details. Given clinicians’ needs to compare and trace annotation-level details, the chapter favors LPG for the core graph while noting bridges between the two worlds and vendor tooling that brings inference capabilities to property graphs. The takeaway is pragmatic: let the use case dictate the model.

Practically, the chapter walks through a repeatable pipeline aligned with business and data understanding, preparation, model creation, and querying. It imports the HPO ontology, derives clean identifiers and labels, ingests the annotations file to create disease nodes and disease–phenotype links, and enriches relationships with provenance and interpretive fields (evidence categories, frequency, onset, curator, dates). After pruning extraneous ontology scaffolding, the resulting graph supports queries that rank diseases by observed phenotypic features, inspect co-occurrence patterns, and trace sources. Finally, ontology-based reasoning over the HPO hierarchy enables inference from high-level categories down to specific traits, letting clinicians navigate different granularities with a precise vocabulary, transparent provenance, and actionable insights for rare disease diagnosis.

The mental model describing the KG construction process as a specification of the CRIPS-DM model, from understanding the business goal to defining the KG queries that support the clinicians' activities.

The CRIPS-DM model adapted to KGs. A subset of the components of this diagram, including business understanding, data understanding, data preparation, and KG model creation/update, represent key phases described in this chapter.

Understanding the business domain for creating a KG that supports the clinicians' activities. This phase is not strictly related to the technical aspects, but it is fundamental for the next steps.

An annotated Venn diagram shows that Type 1 Diabetes Mellitus can be considered as either a disease or a phenotypic feature. Based on the context, two different IDs can be adopted.

Understanding the data to support the clinicians' activities. This fundamental explorative phase gets the key information needed to construct the KG.

Data transformation from a table row to a KG edge. Information included in this table is adapted to define the properties of nodes and the edges of the KG.

Ontology ingestion and processing.

A portion of the HPO ontology loaded in the graph database using LPG as storage model. We can distinguish between two types of information: ontological information (left side) and domain-specific information related to the phenotypic features (right side).

Annotation data set ingestion and processing to finalize the construction of the KG.

Querying the generated KG to support the clinician's activities.

Result of a query that gets all the phenotype features related to Type 1 diabetes.

Summary

Constructing the knowledge graph (KG) is a complex process because it requires extracting and integrating information from heterogeneous sources.
Incorporating these sources aims to harmonize their data and leads to a coherent perspective on the general information.
At the end of the building process, the resulting KG must be a unified, well-grounded, and meaningful representation of data from different sources, where the individual pieces of information are fused into a unique view.
A well-driven KG construction requires a clear idea of the problem you want to solve, an understanding of the reference domain, and a phase involving data scouting, exploration, and comprehension.
The Resource Description Framework (RDF) and the labeled property graph (LPG) are two of the most prominent technologies for materializing KGs.
The RDF data model focuses on knowledge representation and is particularly suitable for constructing ontologies.
The LPG approach intends to provide a fast and query-based traversal mechanism of graph data and path analysis features, emphasizing the efficiency of data storage and access.
Understanding the differences between RDF and LPG is crucial to selecting the best technologies for your specific purpose.
Building a KG from the Human Phenotype Ontology (HPO) dataset can be particularly helpful to clinicians, which enables them to make better diagnoses, starting with the analysis of the phenotypic features detected in a patient.

Kohler, S., Gargano, M., Matentzoglu, N., Carmody, L. C., Lewis-Smith, D., Vasilevsky, N. A., ... & Robinson, P. N. (2021). The human phenotype ontology in 2021. Nucleic acids research, 49(D1), D1207-D1217. https://academic.oup.com/nar/article/49/D1/D1207/6017351?login=true
Orlandi, F., Graux, D., & O'Sullivan, D. (2021, January). Benchmarking RDF Metadata Representations: Reification, Singleton Property, and RDF. In 2021 IEEE 15th International Conference on Semantic Computing (ICSC) (pp. 233-240). IEEE. https://ieeexplore.ieee.org/abstract/document/9364401/
Stickle, D., & Turk, J. (1997). A kinetic mass balance model for 1, 5-anhydroglucitol: applications to monitoring of glycemic control. American Journal of Physiology-Endocrinology and Metabolism, 273(4), E821-E830. https://journals.physiology.org/doi/full/10.1152/ajpendo.1997.273.4.E821

FAQ

What business problem does this chapter address?

The chapter shows how to build a knowledge graph that helps clinicians diagnose rare diseases. It starts from business goals, identifies the clinician as the target persona, and designs a KG that unifies heterogeneous data, preserves clinical context (phenotype hierarchies), and exposes provenance so clinicians can trust and compare evidence.

Which data sources are used to build the KG?

Two HPO sources are used: - hp.owl (OWL/RDF): the Human Phenotype Ontology with standardized phenotype terms, hierarchies, synonyms, and cross-references. - phenotype.hpoa (TSV): curated annotations linking diseases (e.g., OMIM, Orphanet) to HPO phenotypic features, with metadata such as evidence, frequency, onset, and provenance.

Why are ontologies essential for semantic integration?

Ontologies provide a common vocabulary and structure (concepts, properties, relationships) that: - Reconcile synonyms and acronyms (e.g., “Type 2 diabetes” variants, ambiguous “PE”). - Align different granularities (e.g., “necrosis” vs “lobular necrosis”). - Enable mappings from local schemas to a shared reference model so heterogeneous sources can be fused into one coherent KG.

RDF or LPG: which model fits this use case and why?

Both are viable, but LPG is chosen because the use case centers on rich, edge-specific metadata (source, evidence, onset, frequency, curator, date) on the relationship between a disease and a phenotype. LPG stores properties directly on relationships and offers efficient traversal for query workflows clinicians need. RDF excels at ontology modeling, and the HPO ontology itself is in RDF/OWL.

How can I represent relationship metadata in RDF, and what are the trade-offs?

Common RDF patterns: - N-ary relations: introduce an Annotation node to hold metadata; clear but adds indirection. - Named graphs: group triples into a graph and attach provenance to the graph; powerful but can add management overhead. - RDF-star: annotate a triple directly; compact and readable, but engine support and performance can vary. LPG attaches properties directly on edges, which is simpler for this metadata-heavy scenario.

What tools and environment are used?

Neo4j 5.20.0 (Enterprise), APOC 5.20.0, and Neosemantics (n10s) 5.20.0 for loading RDF and building an LPG-based KG. rdflib (Python) is shown for exploring OWL as triples. Sample code and queries are provided in the chapter’s GitHub repository: https://github.com/alenegro81/knowledge-graphs-and-llms-in-action/tree/main/chapters/ch03

How is the ontology (hp.owl) loaded and prepared in Neo4j?

Steps: - Create the database and add constraints/indexes for Resource.uri and Resource.id; index HpoPhenotype.id and HpoDisease.id. - Configure neosemantics (e.g., handleVocabUris: IGNORE, applyNeo4jNaming: true). - Import hp.owl via n10s.rdf.import.fetch. - Enrich Resource nodes whose URIs start with HP_ by adding label HpoPhenotype and computing id (e.g., HP:0000819).

How are HPO annotations ingested and how is edge metadata preserved?

Process: - LOAD CSV of phenotype.hpoa (TSV), skip header rows. - MERGE HpoDisease nodes from database_id and set their labels from disease_name. - MERGE HAS_PHENOTYPIC_FEATURE edges from disease to HpoPhenotype using hpo_id. - Add relationship properties conditionally: source, evidence, onset, frequency, sex, modifier, aspect, biocuration. - Derive helpful fields (e.g., createdBy, creationDate from biocuration; evidenceName/Description; aspectName/Description; url to PubMed/OMIM) using APOC string utilities and batch updates.

How does the KG support clinical queries for diagnosis?

Clinicians can: - Retrieve phenotypic features of a known disease (e.g., OMIM:222100 for Type 1 diabetes). - Input a set of observed features (e.g., Growth delay, Large knee, Sensorineural hearing impairment, Pruritus, Type I diabetes mellitus) and rank diseases by the number of matching phenotypes. - Inspect provenance on each disease–phenotype link (e.g., evidence type, source PMID, curator, date) to assess trust and relevance.

How is ontology-based reasoning applied in this KG?

By leveraging the HPO hierarchy (SUBCLASSOF): - Expand high-level features (e.g., “Abnormality of the endocrine system”, HP:0000818) to their subclasses. - Use Neosemantics’ n10s.inference.nodesInCategory to infer diseases linked via any subclass features. - Combine explicit and inferred links to broaden differential diagnosis while preserving traceability.

pro $24.99 per month

access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
choose one free eBook per month to keep
exclusive 50% discount on all purchases
renews monthly, pause or cancel renewal anytime

lite $19.99 per month

access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more

eBook

pdf, ePub, online

$64.99 $32.49

you save $32.50 (50%)

include audio $24.99 $12.49

pro $24.99 per month

access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
choose one free eBook per month to keep
exclusive 50% discount on all purchases
renews monthly, pause or cancel renewal anytime

lite $19.99 per month

access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more

eBook

$64.99 $32.49

you save $32.50 (50%)

include audio $24.99 $12.49

eBook

pdf, ePub, online

$64.99 $32.49

you save $32.50 (50%)

include audio $24.99 $12.49

pro $24.99 per month

access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
choose one free eBook per month to keep
exclusive 50% discount on all purchases
renews monthly, pause or cancel renewal anytime

lite $19.99 per month

access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more