ChronoGrapher: Event-Centric Knowledge Graph Construction via Informed Graph Traversal

Abstract

Event-centric knowledge graphs help enhance coherence to otherwise fragmented and overwhelming data by establishing causal and temporal connections using relevant data. We address the challenge of automatically constructing event-centric knowledge graphs from generic ones. We present ChronoGrapher, a two-step system to build an event-centric knowledge graph from grand events such as the French Revolution. First, a pruned, semantically informed best-first search traversal retrieves a subgraph from large, open-domain knowledge graphs. We define event-centric filters to prune the search space and a heuristic ranking to prioritize nodes like events. Second, we combine a structured triple enrichment method with a text-based triple enrichment method to build event-centric knowledge graphs. ChronoGrapher demonstrates adaptability across datasets like DBpedia and Wikidata, outperforming approaches from the literature. Furthermore, it is designed to be flexible and to operate over any knowledge graph accessible through Header, Dictionary, and Triples dumps or SPARQL endpoints. To evaluate the utility of these constructed graphs, we conduct a preliminary user study comparing different prompting techniques for event-centric question-answering. Our results demonstrate that prompts enriched with event-centric knowledge graph triples yield more factual answers, measured by how well answers are grounded in source information, than those enriched with generic triples or base prompts, while preserving succinctness and relevance.

1. Introduction

We tackle the problem of building event-centric knowledge graphs (KGs) automatically starting from generic KGs. An event-centric KG can be seen as a KG that focuses on events as central entities, rather than generic entities. An event is an occurrence or happening that can be described by its attributes and relationships to other entities within a KG. It includes information such as time, location, participants, and other relevant properties. Relating events together provide coherence to otherwise fragmented and overwhelming data by establishing causal and temporal connections using relevant data. There are numerous scenarios in which systems could assist individuals in constructing event-centric KGs in their tasks: in news article retrieval for event-centric exploration (Voskarides et al., 2021), in the legal domain where experts must associate events that could bolster their case (Filtz et al., 2020), or in the historical domain when generating hypotheses by retrieving valuable information from archives (Merono et al., 2015).

Let us imagine a historian seeking to understand the events that happened at the end of the French Revolution. Our system aims to produce an event-centric KG, as illustrated in Figure 1, which we manually created using mainly the Simple Event Model (SEM) (Van Hage et al., 2011) ontology and Wikidata. Figure 1 shows that the Coup of 18 Brumaire directlyPrecedes the French Consulate, and that Napoleon was a participant in the Coup of 18 Brumaire, and First Consul during the French Consulate. We can therefore infer that the Coup of 18 Brumaire marked the beginning of the French Consulate and enabled Napoleon to become First Consul.

Figure 1.

One Example of an Event-Centric Knowledge Graph (KG) on the Coup of 18 Brumaire.

It should be noted that the classification of entities such as the French Directory and the French Consulate can be ambiguous, as they may be interpreted either as governing bodies (i.e., institutional entities) or as historical periods marking distinct phases in political history. In our work, we choose to treat such entities as events, consistent with how they are often described in historical discourse (e.g., “the period of the French Directory”) and represented in sources like DBpedia and Wikidata, where these entities frequently include temporal attributes (start and end dates) and are part of event-type hierarchies.

Previous work has approached event-centric KG construction as a two-step process: first, identifying relevant cues within a large memory or knowledge base (Step 1), and second, analyzing and reasoning about these cues (Step 2) (Sloman, 1996). Recent studies have also used generic KGs as background knowledge to support event-centric KG construction (Guan et al., 2022). In this context, we approach event-centric KG construction using the following two steps: given an input event node in a KG, we extract an event-centric subgraph from that KG (Step 1), and we enrich and link this subgraph with additional information to build a new event-centric KG (Step 2). Each triple in the event-centric subgraph from Step 1 has a sub-event of the input event as its subject or its object, making the extracted content directly relevant to the construction of the new event-centric KG in Step 2. Most existing event-centric KG resources are; however, built from annotated text (Leetaru & Schrodt, 2013; Nguyen et al., 2016; Rospocher et al., 2016) or from generic KGs (Gottschalk & Demidova, 2018) (Step 2), but do not focus on identifying related events for event-centric KG construction (Step 1). Likewise, event subgraph extraction (Step 1) has been used for downstream tasks such as question-answering (QA) (Jia et al., 2021; Li et al., 2021; Souza Costa et al., 2020), but does not focus on building event-centric KGs (Step 2). We propose ChronoGrapher that both retrieves event-centric subgraphs and generates new event-centric KGs, as well as an evaluation of an event-centric KG constructed by ChronoGrapher in a QA setting in the form of a user study. ChronoGrapher, along with the source code and detailed instructions to reproduce the experiments, is publicly available on GitHub under the GPL-v3 license, ¹ and archived on Zenodo. ²

Our objective is to construct event-centric KGs that support downstream tasks such as QA, for example by enabling the summarization of complex events like the French Revolution or verifying whether figures like Napoleon and Paul Barras were both involved in the Coup of 18 Brumaire. We define three research questions:

1. RQ1:

How to extract an event-centric subgraph from a KG, given an input event node? (Step 1)

RQ2:

How to create an event-centric KG from that subgraph? (Step 2)

RQ3:

Can integrating event-centric KGs into a QA pipeline improve the output quality of large language models (LLMs) compared to using LLMs alone?

Figure 2 provides an overview of the different tasks we tackle, as well as the input and output of each component.

Figure 2.

Overview of the Diverse Tasks We Tackle to Answer Our Research Questions. The Example on the Bottom Is With the French Revolution as Starting Node and DBpedia as the Knowledge Graph (KG). ChronoGrapher Integrates Both a Subgraph Extraction Step Through a Pruned, Semantically Informed Best-First Search Traversal, and a KG Construction Step Through a Structured Triple Enrichment Method and a Text-Based Triple Enrichment Method.

For each of the research questions, we hypothesize the followings:

1. RQ1:

Due to the vastness of KGs, exploring the entire graph is impractical. A search strategy can help efficiently extract the most relevant parts of the graph.

RQ2:

Combining both coarse-grained (e.g., entity-level) and finer-grained (e.g., roles) information leads to a richer and more useful meaningful representation.

RQ3:

Since KGs can be difficult to navigate or interpret directly, they are often not exposed to end users. Instead, their utility can be evaluated through downstream tasks such as QA, where improved performance indicates higher-quality structure and content.

To address these questions, we present ChronoGrapher, a framework composed of two components. First, a pruned, semantically informed best-first search traversal mechanism extracts event-centric subgraphs around a given event node (RQ1). Second, a KG construction module converts this subgraph into an event-centric KG using information from both the structure and literals (RQ2). We then evaluate the resulting KGs through a QA task to assess whether integrating event-centric KGs enhances the performance of LLMs compared to using LLMs alone (RQ3).

For RQ1, ChronoGrapher performs an informed graph traversal to extract subgraphs composed of sub-events that are related to a given event node in the KG. It is a pruned, semantically informed best-first search. First, it uses event-centric filters to prune the search space and to guide the exploration of the graph, and it identifies which ones are the most relevant to build an event-centric KG. Second, it adds a ranking stage to prioritize nodes for the best-first search part, which, to the best of our knowledge, has not been used in search systems starting from one node in KGs. We define the ranking heuristics based upon syntactic and semantic properties of the graph.

For RQ2, ChronoGrapher combines a structured triple enrichment method (or IRI-based method, where IRI stands for Internationalized Resource Identifier) with a text-based triple enrichment method (or abstract-based method) to generate an event-centric KG. The structured triple enrichment method is a rule-based system that converts the triples from the original KG into event-centric ones. The text-based triple enrichment method is linked to the valuable information embedded in textual literals, such as dbo:abstract. For this, we extract frame-based semantics (Fillmore & Baker, 2001) from these texts using semantic parsing. Frames can be seen as templates with placeholders to be filled in. For example, from the sentence “The coup of 18 Brumaire ended the French Revolution,” one could extract a Causation frame where “coup of 18 Brumaire” is the Cause and “end of the French Revolution” is the Effect.

Concerning the technical novelty of the work, most methods for representing events in KGs are underdeveloped, manually built and time-consuming, and ChronoGrapher is a method for building event-centric KGs automatically from a generic KG. Unlike most approaches, ChronoGrapher integrates data from existing KGs and texts, and results in more concise and precise outputs than baselines adapted from existing systems. The modularity of our approach ensures flexibility and adaptability, while the novel combination and adaptation of previously unintegrated elements contributes to the field and improves the adapted baselines (Fionda et al., 2015; Isele et al., 2010). We evaluate ChronoGrapher and adapted methods from the literature (Fionda et al., 2015; Isele et al., 2010) against ground truth events from EventKG (Gottschalk & Demidova, 2018). ChronoGrapher shows adaptability and efficiency across datasets like DBpedia and Wikidata, outperforming existing methods.

For RQ3, we assess whether integrating event-centric KGs enhances the performance of LLMs compared to using LLMs alone. A human evaluation is conducted to compare three types of zero-shot QA prompts (without explicit context, with triples from generic KGs, with triples from event-centric KGs) and six types of different questions. Our results demonstrate that prompts enriched with event-centric KG triples yield more factual answers compared to those enriched with generic KG triples or base prompts, measured by how well answers are grounded in source information, achieving groundedness scores of 2.85, 2.24, and 1.11, respectively, while preserving succinctness and relevance.

2. Related Work

In this section, we review related work along three dimensions: (i) event-centric KGs and their usage, (ii) methods for event-centric KG construction from KG, and (iii) retrieval augmented generation. Recent advances have introduced new approaches to build event-centric KGs with various applications (i). In particular, we propose a method for event-centric KG construction, which directly contributes to this field. Unlike most previous methods that focus on constructing event-centric KGs from unstructured data, our approach builds KGs from existing, structured KGs. To achieve this, our aim is to improve how event-centric subgraph information is searched and navigated within input KGs, by optimizing existing graph traversal methods. To this end, we present related methods that facilitate this process (ii), including link-traversal-based techniques for dynamic data discovery, graph navigational languages for expressing complex patterns, and entity relatedness measures to prioritize relevant nodes. Lastly, we review works that utilize event-centric KGs to improve the performance of LLMs, highlighting the practical applications of event-centric KGs in downstream tasks (iii).

(i) Event-centric KGs and their usage. Recent research on KGs has emphasized the importance of having more event-centric structures to facilitate the analysis and understanding of sequence of events (Riedl, 2016). In this context, event-centric KGs have been developed in a wide range of domains, including news (Leetaru & Schrodt, 2013; Nguyen et al., 2016; Rospocher et al., 2016), political events (Boschee et al., 2015), literary narratives (Kawamura et al., 2019), the biomedical domain (Liu et al., 2018), tourism (Wu et al., 2020), the legal domain (Filtz et al., 2020), olfactory heritage (Lisena et al., 2022), and plenary debates (Sinikallio et al., 2021). In the digital humanities and cultural heritage domains, KGs are increasingly used to link objects to events and the stories surrounding them. For example, the Arco project constructs an Italian cultural heritage KG (Carriero et al., 2019) that was built on XML data using the eXtreme Design methodology (Blomqvist et al., 2010). Other projects focus on understanding historical processes, whether through the history of a city such as Amsterdam (Noordegraaf et al., 2019) or through various historical archives (Meroño-Peñuela & Hoekstra, 2014; Singh et al., 2016; Tomasi, 2021; Van den Akker et al., 2010). Van den Akker et al. (2010) focused on the extraction and modeling of events from the text archive, and Tomasi (2021) proposes an agile cataloging process to build a KG. These works primarily extract events from textual sources, often employing domain-specific heuristics or manual structuring.

In this work, we focus on KG construction from KG. The work most closely related to ours is EventKG (Gottschalk & Demidova, 2019), an event-centric KG that was built starting from large, generic KGs, such as DBpedia or Wikidata. EventKG follows a global and schema-driven approach, where event types are predefined and extracted in bulk across the entire KG. In contrast, our methods adopts a local and dynamic approach: we start from a given input event, that is a node in the KG, and automatically retrieves a subgraph that contains sub-events of that input event. This allows for more context-sensitive and targeted event graph construction. Moreover, our framework is designed to be more flexible: it can be applied to any KG, not limited to the largest open-domain KGs, and it can be configured to retrieve subgraphs around any type of node, not just events, making it broadly adaptable beyond the event-centric setting.

In addition to the KG construction part, event-centric KGs have been explored for downstream applications. For example, Guyet (2020) improved sequential pattern mining with time and reasoning to analyze complex dynamical systems. Understanding such systems helps in acquiring new knowledge but also in predicting and controlling its behavior. Event-centric KGs also help in decision-making, for instance, in the epidemiological domain (Bakalara et al., 2021) or in maritime transport (Del Mondo et al., 2021). Kroll et al. (2020) lastly uses structured narrative representations to build hypotheses on knowledge bases. These applications underscore the growing importance of event-centric KGs in both analytical and predictive tasks.

(ii) Methods for event-centric KG construction from KG. To construct event-centric KGs from KGs, our method performs a pruned, semantically informed, best-first search graph traversal. Although not originally designed for event-centric KG construction, several sub-domains offer valuable methods and insights that support this task. We draw on techniques from linked data traversal, graph navigational languages, and entity relatedness and summarization to inform our approach. These methods guide how information is explored, filtered, and extracted from large graphs, which is crucial for retrieving event-centric content efficiently. We compare their scope to ChronoGrapher’s.

Linked-traversal based methods focus on identifying and extracting task-relevant information by navigating large-scale web data. Also framed as Link Traversal Query Processing (LTQP), the engines start with seed URIs and dynamically discovers sources by following hyperlinks (Hartig et al., 2009; Hartig & Freytag, 2012). One of the pioneering systems in this domain is LDSpider (Isele et al., 2010), which employs diverse search strategies such as breadth-first search or load balancing to crawl web data. Subsequent systems aimed to reduce the search space during the traversal, encoding features like property selection (Schaffert et al., 2012) or basic graph patterns (Umbrich et al., 2012). Systems such as Linked Data-fu (Stadtmüller et al., 2013) and LiDAQ (Umbrich et al., 2012) and its extensions (Umbrich et al., 2015) added reasoning capabilities to their approaches. Other systems like SQUIN (Hartig, 2013) focused on optimizing query execution efficiency. Lynden et al. (2013) propose a hybrid SPARQL query execution strategy that combines link traversal with distributed query processing over SPARQL endpoints. A follow-up of their work (Hartig & Özsu, 2016) evaluated 14 ranking approaches to prioritize result-relevant data sources early during query execution. Taelman and Verborgh (2023) extend LTQP by leveraging structural properties of decentralized systems such as solid to improve query performance at scale. As a follow-up, Eschauzier et al. (2023) investigate the behavior of the link queue in LTQP and reveals two distinct execution patterns. Their findings highlight the importance of understanding link queue behavior for optimizing LTQP performance in decentralized settings. Lastly, Comunica (Taelman et al., 2018) is a modular query engine for Linked Data, designed to flexibly support and evaluate diverse query algorithms, SPARQL features, and Web interfaces. These methods offer a variety of traversal strategies designed for efficient and goal-directed search through KGs, which we draw on to dynamically guide the extraction of event-centric subgraphs in our method.

Graph navigational languages allow structured and iterative exploration of Linked Data through declarative instructions to retrieve nodes or subgraphs. There are two types of approach, namely SPARQL extensions (Fionda et al., 2019; Harris et al., 2013; Reutter et al., 2015) and standalone languages (Fionda et al., 2015; Hartig & Pérez, 2016). Most of these approaches use regular expressions, such as SPARQLeR (Kochut & Janik, 2007) and PSPARQL (Alkhateeb et al., 2009), and later nested regular expressions, such as Zauner et al. (2010) and nSPARQL (Pérez et al., 2010) to explore the graph. Although our traversal is not expressed in a declarative language, we compare the scope and output of our method to those of navigational languages. Our approach can handle both local KGs and SPARQL endpoints, and its output is a subgraph, referred to as a “region” in the context of GeL (Fionda & Pirrò, 2017) and NautiLOD (Fionda et al., 2015). The most expressive system appears to be LDQL (Hartig & Pérez, 2016) which separates pattern processing and source selection. These approaches provide techniques to extract nodes or subgraphs that match specific semantic criteria, which we draw on to refine and optimize the extraction of event-centric subgraphs in our framework.

Entity relatedness methods support the identification of paths, “regions” or subgraphs of high semantic relevance within KGs (Jiménez et al., 2022). Entity relatedness systems compute all paths with search heuristics and activation criteria to prune the search space and rank paths (Herrera, 2017). The search heuristics include the bidirectional search (Fang et al., 2011; Tiddi et al., 2016), backward search heuristic (Herrera et al., 2016), SPARQL queries (Pirrò, 2015), exploratory association search (Cheng et al., 2014), and A* (De Vocht et al., 2013). Activation criteria include entity clustering (Cheng et al., 2014), metrics based on node degree (Fang et al., 2011; Moore et al., 2012) or ontology (Lohmann et al., 2010), and similarity measures (De Vocht et al., 2013; Herrera et al., 2016) such as Jaccard, Wikipedia link-based measures (Witten & Milne, 2008), or SimRank (Jeh & Widom, 2002). For ranking paths, metrics include PF-ITF (Pirrò, 2015), exclusivity-based relatedness (Herrera et al., 2016), and point mutual information (Hulpuş et al., 2015). Table 1 provides an overview of the entity relatedness systems we described.

Entity summarization systems (Liu et al., 2021) take a KG as input and output a graph that retains certain original properties of the graph. The methods used to select nodes are similar to the ranking ones from entity relatedness systems. These systems offer a range of search heuristics and path-ranking strategies to identify meaningful connections between nodes, which we adapt to dynamically guide the extraction of subgraphs in our framework.

Table 1.

Overview of Entity Relatedness Systems.

System	Path search	Activation criteria	Ranking
Tiddi et al. (2016)	Bidirectional search	Primitives	Cost functions
Profiler (Herrera et al., 2016)	Backward search heuristic	Similarity measures	–
RECAP (Pirrò, 2015)	SPARQL queries	–	Path informativeness
EXPLASS (Cheng et al., 2014)	Exploratory association search	Clustering entities	–
De Vocht et al. (2013)	A*	Jaccard-based metrics	Top $k$ paths
Moore et al. (2012)	Shortest paths	Low-degree nodes	Top $k$ paths
REX (Fang et al., 2011)	Bidirectional search	Degree of node	Interestingness measure
RelFinder (Lohmann et al., 2010)	All paths	Class, link and length filter	–

“–” indicates that the component is absent in the system.

Our method traverses KGs to extract event-centric subgraphs for event-centric KG building, similar to link traversal-based methods and graph navigational languages. It operates on local graphs or any SPARQL endpoint and produces meaningful subgraphs, similarly to systems like Fionda and Pirrò (2017) and Fionda et al. (2015). Unlike existing traversal methods, which often lack finer-grained control and expressiveness, our approach introduces flexible navigation and reasoning capabilities. It employs filters for search space pruning without prior knowledge of predicates, unlike graph navigational languages requiring regular expressions. Additionally, we introduce a ranking stage inspired by entity relatedness and summarization systems, prioritizing nodes based on a cost function. To the best of our knowledge, this dynamic prioritization is only present by Hartig and Özsu (2016) across in existing navigational systems, and only propose two graph-related approaches. In contrast to entity relatedness systems that typically compute all paths between entities, our system dynamically computes paths. Furthermore, our approach requires only one starting node as input, with target nodes defined as variables. It extracts subgraphs from the original KG, aiming to retrieve all events of a given entity, disregarding specific property considerations as in entity summarization systems. Lastly, while entity summarization techniques focus on preserving specific property distributions, our method targets the extraction of complete event-centric subgraphs, ensuring the retrieval of all sub-events linked to the input node.

(iii) Retrieval augmented generation (RAG). RAG studies have shown that LLMs store factual knowledge in their parameters (Petroni et al., 2019), for example, in the form of implicit knowledge bases (Razniewski et al., 2021; Roberts et al., 2020). However, the mechanisms to retrieve and understand this knowledge remain challenging. RAG systems (Chen et al., 2024) explicitly provide external information to the model through a dedicated knowledge retriever component. By separating knowledge storage from generation, RAG systems improve interpretability and often lead to more factual, diverse, and contextually grounded output (Lewis et al., 2021), with applications in tasks such as QA (Chen et al., 2017) or reasoning (Sun et al., 2024). Systems such as ORQA (Lee et al., 2019) or REALM (Guu et al., 2020) learn the retriever and the reader jointly, whereas systems like DrQA (Chen et al., 2017) have a fixed document retrieval component. Karpukhin et al. (2020) propose a dense passage retriever to index all documents in a latent space. Petroni et al. (2020) augment the reader with a retriever in an unsupervised way.

In our user study, we adopt a RAG-like setup to compare three types of zero-shot prompting strategies for QA: one prompting without explicit context, and two prompting with triples from generic KGs and event-centric KGs, respectively. Our knowledge retriever component is implemented using SPARQL queries that extract relevant triples from the KG to condition the LLM’s generation.

3. ChronoGrapher

As displayed in Figure 2 from Section 1, ChronoGrapher takes an event IRI as input, extracts an event-centric subgraph where all triples contains sub-events of that input IRI, and outputs an event-centric KG. In this section, we formalize the two main components: subgraph extraction (Section 3.1) and event-centric KG construction (Section 3.2). We begin by defining the core concepts used throughout the two components: KGs, event-centric KGs, event and subevent.

Definition 1 (Knowledge Graph)

A knowledge graph ( $\mathcal{K}\mathcal{G}$ ) is an RDF graph where the nodes represent entities (subjects or objects) and literals (objects) and the edges represent the relationships (predicates) between these entities and literals. Formally, $\mathcal{K}\mathcal{G}=\{(s,p,o)|s\in \mathcal{E},o\in \mathcal{E}\cup \mathcal{L},p\in \mathcal{R}\}$ , where $\mathcal{E}$ is the set of entities (nodes) in the KG, $\mathcal{L}$ is the set of literals in the KG, and $\mathcal{R}$ is the set of predicates (edges) representing relationships in the KG.

Definition 2 (Event-Centric KG)

In this work, an event-centric KG is a KG whose vocabulary, classes, and relationships originate from the SEM (Van Hage et al., 2011) and the NIF (Hellmann et al., 2013) ontologies. There are four core classes in SEM: sem:Event (what), sem:Actor (who), sem:Place (where), and sem:Time (when). The NIF ontology enables to integrate text data in KGs.

Definition 3 (Event and Sub-Event)

An event is defined as an occurrence in time that can be characterized by attributes from the SEM ontology, such as actor and location. A sub-event is defined as an event that forms part of a larger, composite event. Sub-events maintain the same formal structure as events but are contextually linked to parent events through temporal, causal, or structural relations (e.g., sem:subEventOf).

3.1. Event-Centric Subgraph Extraction (RQ1)

Given a target event of interest and a knowledge graph $\mathcal{K}\mathcal{G}$ , our goal is to extract an event-centric subgraph from $\mathcal{K}\mathcal{G}$ that captures relevant information about this event. To achieve this, we propose a link traversal-based method tailored to the event-centric setting. Our approach takes the form of a pruned best-first search: it incrementally explores the most promising nodes while explicitly pruning others, enabling focused and efficient traversal.

We begin by introducing the core concepts required for graph traversal (Section 3.1.1) and formally define the task and the search algorithm (Section 3.1.2). We then present the two key components of our method: the event-centric filters, which prune the search space by discarding nodes (Section 3.1.3); and the ranking and scoring mechanism, which selects the highest scoring nodes for expansion based on their contextual relevance (Section 3.1.4). Together, these components drive the extraction of compact and semantically meaningful subgraphs centered around a given event. To facilitate understanding of the subgraph extraction task and its components, we summarize the key definitions used throughout this section in Table 2.

Table 2.

Useful Definitions for the Subgraph Extraction Task.

Definition number	Definition name	Relevance to subgraph extraction task
4	Ingoing triples	Node expansion (cf. Definition 6)
5	Outgoing triples	Node expansion (cf. Definition 6)
6	Node expansion	KG traversal
7	Event-centric subgraph retrieval task	Task
8	Pruned best-first search	Method, with two main components: node pruning and node ranking
9	Event-centric filters	Node pruning (cf. Definition 8)
10	Relation patterns	Node ranking (cf. Definition 8)
11	Scoring	Node ranking (cf. Definition 8)
12	Preference function	Node ranking (cf. Definition 8)

KG = knowledge graph.

3.1.1. Preliminaries

We formally define preliminary concepts that are useful for our subgraph extraction task and our link traversal-based method: the ingoing and outgoing triples of a node in a KG, as well as node expansion.

Definition 4 (Ingoing Triples)

Let $\mathcal{K}\mathcal{G}=\{(s,p,o)|s\in \mathcal{E},o\in \mathcal{E}\cup \mathcal{L},p\in \mathcal{R}\}$ , and $\mathcal{P}(\mathcal{K}\mathcal{G})=\{\mathcal{A}|\mathcal{A}\subseteq \mathcal{K}\mathcal{G}\}$ the set of all subsets of $\mathcal{K}\mathcal{G}$ . The ingoing triples of a node $n$ are formally defined as follows:

$$\begin{array}{rl}ingoin{g}_{\mathcal{K}\mathcal{G}}:\mathcal{E}& ⟶\mathcal{P}(\mathcal{K}\mathcal{G})\\ n& ⟼\{(s,p,n)\mid \mathrm{\exists }p\in \mathcal{R},\mathrm{\exists }s\in \mathcal{E},\text{ such that }(s,p,n)\in \mathcal{K}\mathcal{G}\}\end{array}$$

Definition 5 (Outgoing Triples)

Let $\mathcal{K}\mathcal{G}=\{(s,p,o)|s\in \mathcal{E},o\in \mathcal{E}\cup \mathcal{L},p\in \mathcal{R}\}$ , and $\mathcal{P}(\mathcal{K}\mathcal{G})=\{\mathcal{A}|\mathcal{A}\subseteq \mathcal{K}\mathcal{G}\}$ the set of all subsets of $\mathcal{K}\mathcal{G}$ . The outgoing triples of a node $n$ are formally defined as follows:

$$\begin{array}{rl}outgoin{g}_{\mathcal{K}\mathcal{G}}:\mathcal{E}& ⟶\mathcal{P}(\mathcal{K}\mathcal{G})\\ n& ⟼\{(n,p,o)\mid \mathrm{\exists }p\in \mathcal{R},\mathrm{\exists }o\in \mathcal{E}\cup \mathcal{L},\text{ such that }(n,p,o)\in \mathcal{K}\mathcal{G}\}\end{array}$$

Definition 6 (Node Expansion)

Expanding a node $n$ means retrieving its ingoing and outgoing triples.

Building on these preliminary concepts, we now formalize the event-centric subgraph retrieval task and describe our pruned best-first search algorithm to tackle it.

3.1.2. Task and Method Overview

We formalize the event-centric subgraph retrieval task and present the framework used to address it. Our method is a pruned best-first search that iteratively expands a local subgraph by exploring the most promising candidate nodes while discarding other ones. This section first introduces the task formulation and algorithm definition, followed by a step-by-step breakdown in pseudo-code and an illustration of the traversal process.

Definition 7 (Event-Centric Subgraph Retrieval Task)

Given a knowledge graph $\mathcal{K}\mathcal{G}=\{(s,p,o)\mid s\in \mathcal{E},o\in \mathcal{E}\cup \mathcal{L},p\in \mathcal{R}\}$ and a starting event node $n_{start}$ , the goal of the event-centric subgraph retrieval task is to extract a subgraph ${\mathcal{G}}^{\prime }\subseteq \mathcal{K}\mathcal{G}$ such that each triple $(s^{\prime },p^{\prime },o^{\prime })\in {\mathcal{G}}^{\mathrm{\prime }}$ satisfies the condition that either $s^{\mathrm{\prime }}$ or $o^{\mathrm{\prime }}$ is a sub-event of $s.$ ³ Formally:

$$\begin{array}{rl}retrieva{l}_{\mathcal{K}\mathcal{G}}:\mathcal{E}& ⟶\mathcal{P}(\mathcal{K}\mathcal{G})\\ n_{start}& ⟼\{(s^{\prime },p^{\prime },o^{\prime })\in \mathcal{K}\mathcal{G}|\text{subevent\_of}(s^{\prime },n_{\text{start}})\vee \text{subevent\_of}(o^{\prime },n_{\text{start}})\}\end{array}$$

Note that with this definition, $n_{start}$ will not be included in the extracted subgraph if it is not explicitly encoded as a sub-event of itself. However, $n_{start}$ is later re-integrated during the KG construction step (described in Section 3.2), and is therefore present as an event node in the final output KG. Furthermore, non-subevent relations such as preceding events are not included in the extracted event-centric subgraph from Definition 7, and are not treated as sub-events. Extending this approach to incorporate other relations, such as those defined in Allen’s interval algebra (Allen, 1983), is a promising direction for future work.

Definition 8 (Pruned Best-First Search Algorithm)

A pruned best-first search algorithm explores a graph by expanding the unvisited node with the highest score according to a predefined heuristic. During traversal, the algorithm prunes (i.e., excludes) nodes and edges of specific types, reducing the search space while focusing the exploration on the most promising parts of the graph.

We provide the pseudo-code for our subgraph extraction method in Algorithm 1, which implements a pruned best-first search in four main stages at each iteration of the search: nodes with the highest score are selected and expanded in the graph (Stage 1); event-centric filters prune certain nodes from the search space (Stage 2); the pending set and output subgraph are updated accordingly (Stage 3); and nodes in the pending set are scored and ranked to guide the next iteration (Stage 4). The $t{o}_{e}xtract$ parameter specifies the type of nodes to extract from the graph; while it is set to events in our experiments, it can be adapted to extract different node types depending on the dataset or use case. The set nodes, initialized in line 4, represents the priority queue of nodes to be expanded, drawn from the pending set $\mathcal{P}$ initialized in line 3.

To illustrate these stages more intuitively, Figure 3 shows how a single iteration of the graph search unfolds. ⁴ This visual aid complements the pseudo-code by providing a concrete example of node expansion, filtering, and scoring in context. In Stage 1, the highest-ranked nodes are expanded by retrieving their ingoing and outgoing neighbors. In the figure, dbr:French_Revolution is expanded. This leads to new, unvisited ingoing nodes like dbr:Insurrection_of_10_August_1792 or dbr:Storming_of_the_Bastille, and unvisited outgoing nodes like dbo:MilitaryConflict and dbr:Kingdom_of_France. Stage 2 applies the node filtering. For example, dbr:Kingdom_of_France is removed because it is a location node (WHERE), dbo:MilitaryConflict is discarded due to being reached via the rdf:type predicate (WHAT), and dbr:Jean-Jacques_Rousseau is excluded because he died before the French Revolution began (WHEN). These filters help focus the traversal on event nodes, which are more likely to lead to other relevant events, reducing noise during search. Importantly, some filtered nodes, typically people and locations, are re-integrated during the KG construction phase to ensure a complete and coherent event representation. Stage 3 updates the pending node set and the output subgraph with the remaining nodes. In the figure, dbr:Pierre_Douville, Storming_of_the_Bastille, and Insurrection_of_10_August_1792 are added to the pending nodes to possibly be expanded, and the triples connecting the two latter nodes to dbr:French_Revolution are added to the subgraph output. Lastly, in Stage 4, candidate nodes are grouped by patterns, and ranked using scoring metrics such as predicate frequency or entropy predicate frequency to guide the next iteration. In the figure, Storming_of_the_Bastille and Insurrection_of_10_August_1792 will be expanded at the next iteration.

Figure 3.

Description of One Iteration During the Informed Graph Traversal. The Type of Ranking Is Predicate-Object Frequency. The WHERE, WHAT, and WHEN Filters Are Activated (Formally Defined as $e_{f}ilte{r}_{\{dbo:Location\},\mathcal{D}\mathcal{B},rdf:type}$ , Where $\mathcal{D}\mathcal{B}$ Is the Set of Triples in DBpedia, $p_{f}ilte{r}_{rdf:type}$ and $t_{f}ilte{r}_{dbo:startDate,1789-05-05,dbo:endDate,1799-12-31}$ , Respectively).

The pseudo-algorithm and the visual overview highlight the key stages of our graph traversal process. We now formally define the event-centric filters (Section 3.1.3) and ranking mechanism (Section 3.1.4) that guide the subgraph extraction by pruning irrelevant nodes and prioritizing the most informative ones.

3.1.3. Event-Centric Filters

We define a set of generic filters to prune the search space during traversal, instantiated in our experiments as event-centric filters (see Section 4.1). While the filters are generic, our usage for the event-centric KGs follows the SEM ontology (Van Hage et al., 2011) and is aligned with its four core classes, as detailed in the introduction of Section 3.

The intuition behind these filters is to restrict the traversal to event-centric paths, that is, to nodes that are themselves events. This design helps prevent the search from drifting into semantically less relevant or noisy parts of the graph. For instance, expanding a person or location node may lead to biographical or geographic information that, while informative, does not contribute directly to the sub-event structure we aim to retrieve. Therefore, such entities are, when possible, not expanded further during traversal. However, they remain essential to the broader context of events and are reintegrated during the KG construction phase, which enriches the retrieved event-centric core with relevant contextual information such as people, places, and other linked entities.

In Figure 3 (Stage 2), the filters act dynamically, pruning newly visited nodes based on their type or connection. These filters could be implemented using SPARQL queries or graph navigational languages such as NautiLOD (Fionda et al., 2015), though such approaches lack the ability to rank patterns (see Section 3.1.4). Below, we formally define the filter mechanism.

Definition 9 (Event-Centric Filters)

We hereafter define three types of event-centric filters: predicate-based, entity-based and temporal-based. Each filter is a boolean function that enables to prune the search space in a knowledge graph $\mathcal{K}\mathcal{G}=\{(s,p,o)|s\in \mathcal{E},o\in \mathcal{E}\cup \mathcal{L},p\in \mathcal{R}\}$ .

Definition 9.1

Predicate-based filter.

Let ${\mathcal{R}}^{\prime }\subset \mathcal{R}$ and $(s,p,o)\in \mathcal{K}\mathcal{G}$ . The predicate-based filter discards $(s,p,o)$ from the search space if $p\in {\mathcal{R}}^{\prime }$ . It can be formally defined as follows:

$$\begin{array}{rl}{p}_{f}ilte{r}_{{\mathcal{R}}^{\prime }}:\mathcal{K}\mathcal{G}& ⟶\{0,1\}\\ (s,p,o)& ⟼\{\begin{array}{ll}1& \text{if}p\in {\mathcal{R}}^{\prime }\\ 0& \text{else}\end{array}\end{array}$$

• –

  WHAT-filter. For example, ${\mathcal{R}}^{\prime }=\{\text{rdf:type}\}$ .

Definition 9.2

Entity-based filter.

Let ${\mathcal{E}}^{\prime }\subset \mathcal{E}$ , $p\in \mathcal{R}$ , $s\in \mathcal{E}$ . The entity-based filter discards $s$ from the search space if $s$ is of any type in ${\mathcal{E}}^{\prime }$ . It can be formally defined as follows:

$$\begin{array}{rl}{e}_{f}ilte{r}_{{\mathcal{E}}^{\prime },\mathcal{K}\mathcal{G},p}:\mathcal{E}& ⟶\{0,1\}\\ s& ⟼\{\begin{array}{ll}1& \text{if}\mathrm{\exists }t\in {\mathcal{E}}^{\prime },\text{ such that }(s,p,t)\in \mathcal{K}\mathcal{G}\\ 0& \text{else}\end{array}\end{array}$$

• –

WHO-filter. For example, ${\mathcal{E}}^{\prime }=\{\text{dbo:Person}\}$ , $p=\text{rdf:type}$ .

–

WHERE-filter. For example, ${\mathcal{E}}^{\prime }=\{\text{dbo:Location}\}$ , $p=\text{rdf:type}$ .

Definition 9.3

Temporal-based filter.

Let ${\mathcal{L}}_{date}\subseteq \mathcal{L}$ be the subset of literals corresponding to dates. Let $(p_{start},p_{end})\in {\mathcal{R}}^2$ , $(t_{start},t_{end})\in {\mathcal{L}}_{date}^2$ . $p_{start}$ and $p_{end}$ are predicates denoting the start and end dates of an event, respectively, and $t_{start}$ and $t_{end}$ are literal timestamps. The temporal-based filter discards $s\in \mathcal{E}$ from the search space if it ends before $t_{start}$ or if it starts after $t_{end}$ . It can be formally defined as follows:

$$\begin{array}{rl}{t}_{f}ilte{r}_{p_{start},t_{start},p_{end},t_{end}}:\mathcal{E}& ⟶\{0,1\}\\ s& ⟼\{\begin{array}{ll}1& \text{if }\mathrm{\exists }{t}_1\in {\mathcal{L}}_{date},\text{ such that }(s,p_{start},t_1)\in \mathcal{K}\mathcal{G}\text{ and }{t}_1>t_{end}\\ & \text{or }\mathrm{\exists }{t}_2\in {\mathcal{L}}_{date},\text{ such that }(s,p_{end},t_2)\in \mathcal{K}\mathcal{G}\text{ and }{t}_2<t_{start}\\ 0& \text{otherwise}\end{array}\end{array}$$

• –

  WHEN-filter. For example, $p_{start}=\text{dbo:birthDate}$ , $p_{end}=\text{dbo:deathDate}$ , $t_{start}=\text{``1789-05-05,"}$

  $t_{end}=\text{``1799-12-31."}$

The above filters are parameters of the traversal, and can be activated on demand. In Figure 3, the filters we activated are WHAT, WHERE, and WHEN (formally defined as $e_{f}ilte{r}_{\{dbo:Location\},\mathcal{D}\mathcal{B},rdf:type}$ , $p_{f}ilte{r}_{rdf:type}$ , and $t_{f}ilte{r}_{dbo:startDate,1789-05-05,dbo:endDate,1799-12-31}$ respectively). For WHAT, dbo:MilitaryConflict is discarded from the search space, since it is the object of the triple (dbr:French_Revolution,rdf:type, dbo: MilitaryConflict). Regarding WHERE, Kingdom_of_France is discarded since it is of type dbo:Location. Lastly, Jean-Jacques_Rousseau is discarded because Rousseau died before the French Revolution started, hence applying the WHEN filter.

3.1.4. Ranking Mechanism

To prioritize the most relevant nodes for expansion, we implement a ranking mechanism that operates at the level of relation patterns. Rather than scoring individual nodes in isolation, our method groups nodes according to the structural and semantic patterns they instantiate in the graph. Each pattern is then evaluated and ranked based on its relevance to the current search context.

The ranking strategy combines two complementary components: a quantitative heuristic, which assigns a numerical score to each pattern, and a semantic preference function, which classifies patterns into semantically relevant versus less semantically relevant. The final score of a pattern integrates both aspects to reflect both contextual fit and semantic importance. Once the top-ranked pattern is selected, all nodes in the pending set that match this pattern are expanded. The process repeats until no relevant patterns or nodes remain, or until the maximum iteration number is reached. We now formally introduce the notion of relation patterns and node satisfaction, before detailing the scoring and preference mechanisms used to rank them. All the examples are taken from Figure 3.

Definition 10 (Relation Patterns and Node Satisfaction)

Let $\mathcal{K}\mathcal{G}=\{(s,p,o)|s\in \mathcal{E},o\in \mathcal{E}\cup \mathcal{L},p\in \mathcal{R}\}$ . We define the following relation patterns in $\mathcal{K}\mathcal{G}$ as Boolean functions. For each pattern defined below, we write that a node $n\in \mathcal{E}$ satisfies a pattern if the corresponding pattern function returns 1 for $n$ .

Definition 10.1

Single-step outgoing predicate pattern.

Let a predicate $p\in \mathcal{R}$ , we formally define $op{p}_{p,\mathcal{K}\mathcal{G}}$ as follows:

$$\begin{array}{rl}op{p}_{p,\mathcal{K}\mathcal{G}}:\mathcal{E}& ⟶\{0,1\}\\ n& ⟼\{\begin{array}{ll}1& \text{if }\mathrm{\exists }o\in \mathcal{E}\text{ such that }(n,p,o)\in \mathcal{K}\mathcal{G}\\ 0& \text{otherwise}\end{array}\end{array}$$

• –

  Example. We assume $\mathcal{K}\mathcal{G}=DBpedia$ and $p=\text{ {dbo:isPartOfMilitaryConflict}}$ .

  dbr:Storming_of_the_Bastille satisfies $op{p}_{p,\mathcal{K}\mathcal{G}}$ , since

  (dbr:Storming_of_the_Bastille, $p$ , dbr:French_Revolution) $\in \mathcal{K}\mathcal{G}$ .

Definition 10.2

Single-step ingoing predicate pattern

Let a predicate $p\in \mathcal{R}$ , we formally define $ip{p}_{p,\mathcal{K}\mathcal{G}}$ as follows:

$$\begin{array}{rl}ip{p}_{p,\mathcal{K}\mathcal{G}}:\mathcal{E}& ⟶\{0,1\}\\ n& ⟼\{\begin{array}{ll}1& \text{if }\mathrm{\exists }s\in \mathcal{E}\text{ such that }(s,p,n)\in \mathcal{K}\mathcal{G}\\ 0& \text{otherwise}\end{array}\end{array}$$

• –

  Example. We assume $\mathcal{K}\mathcal{G}=DBpedia$ and $p=\text{ {dbo:isPartOfMilitaryConflict}}$ .

  dbr:French_Revolution satisfies $ip{p}_{p,\mathcal{K}\mathcal{G}}$ , since

  (dbr:French_Revolution, $p$ , dbr:Storming_of_the_Bastille) $\in \mathcal{K}\mathcal{G}$ .

Definition 10.3

Single-step outgoing predicate-object pattern

Let a predicate $p\in \mathcal{R}$ and an entity $e\in \mathcal{E}$ , we formally define $opo{p}_{p,e,\mathcal{K}\mathcal{G}}$ as follows:

$$\begin{array}{rl}opo{p}_{p,e,\mathcal{K}\mathcal{G}}:\mathcal{E}& ⟶\{0,1\}\\ n& ⟼\{\begin{array}{ll}1& \text{if }(n,p,e)\in \mathcal{K}\mathcal{G}\\ 0& \text{otherwise}\end{array}\end{array}$$

• –

  Example. We assume $\mathcal{K}\mathcal{G}=DBpedia$ , $p=\text{ {dbo:isPartOfMilitaryConflict}}$ and

  $e=\text{ {dbr:Storming\_of\_the\_Bastille}}$ .

  dbr:French_Revolution satisfies $opo{p}_{p,e,\mathcal{K}\mathcal{G}}$ , since

  (dbr:French_Revolution, $p$ , dbr:Storming_of_the_Bastille) $\in \mathcal{K}\mathcal{G}$ .

Definition 10.4

Single-step ingoing predicate-object pattern

Let a predicate $p\in \mathcal{R}$ and an entity $e\in \mathcal{E}$ , we formally define $ipo{p}_{p,e,\mathcal{K}\mathcal{G}}$ as follows:

$$\begin{array}{rl}ipo{p}_{p,e,\mathcal{K}\mathcal{G}}:\mathcal{E}& ⟶\{0,1\}\\ n& ⟼\{\begin{array}{ll}1& \text{if }(e,p,n)\in \mathcal{K}\mathcal{G}\\ 0& \text{otherwise}\end{array}\end{array}$$

• –

  Example. We assume $\mathcal{K}\mathcal{G}=DBpedia$ , $p=\text{ {dbo:isPartOfMilitaryConflict}}$ and

  $e=\text{ {dbr:French\_Revolution}}$ .

  dbr:Storming_of_the_Bastille satisfies $ipo{p}_{p,e,\mathcal{K}\mathcal{G}}$ , since

  (dbr:French_Revolution, $p$ , dbr:Storming_of_the_Bastille) $\in \mathcal{K}\mathcal{G}$ .

Definition 11 (Scoring)

Let ${\mathcal{G}}^{\prime }$ a subset of $\mathcal{K}\mathcal{G}$ .

We first define scoring metrics for ingoing and outgoing predicate patterns. Let a predicate $p\in \mathcal{R}$ and the patterns $ip{p}_p$ and $op{p}_p$ from Definition 10.

–

Predicate frequency (pf). Edges with predicates that are often used in the dataset will be favored.

$$\begin{array}{r}pf(ip{p}_p)=|\{s\mid \mathrm{\exists }o\in \mathcal{E},\text{ such that }(s,p,o)\in {\mathcal{G}}^{\prime }\}|\end{array}$$

(1)

$$\begin{array}{r}pf(op{p}_p)=|\{o\mid \mathrm{\exists }s\in \mathcal{E},\text{ such that }(s,p,o)\in {\mathcal{G}}^{\prime }\}|\end{array}$$

(2)

–

Entropy predicate frequency (epf). Edges with the most informative predicates in the dataset will be favored. Let $pp\in \{ip{p}_p,op{p}_p\}.$

$$\begin{array}{r}epf(pp)=\{\begin{array}{ll}-\frac{pf(pp)}{|{\mathcal{G}}^{\prime }|}\times \log (\frac{pf(pp)}{|{\mathcal{G}}^{\prime }|})& \text{if }pf(pp)>0\\ 0& \text{otherwise}\end{array}\end{array}$$

(3)

–

Inverse predicate frequency (ipf). Edges with predicates that are rarely used in the dataset will be favored. Let $pp\in \{ip{p}_p,op{p}_p\}.$

$$\begin{array}{r}epf(pp)=\{\begin{array}{ll}-\frac{1}{pf(pp)}& \text{if }pf(pp)>0\\ 0& \text{otherwise}\end{array}\end{array}$$

(4)

Table 3.

Triples Considered for the Scoring Example. Only Unvisited Nodes Are Taken Into Account.

Subject	Predicate	Object
dbr:Pierre_Douville	dbo:battle	dbr:French_Revolution
dbr:Insurrection_of_10_August_1792	dbo:isPartOfMilitaryConflict	dbr:French_Revolution
dbr:Storming_of_the_Bastille	dbo:isPartOfMilitaryConflict	dbr:French_Revolution

We second define scoring metrics for ingoing and outgoing predicate-object patterns. Let $p$ , $p\in \mathcal{R}$ , $e$ , $e\in \mathcal{E}$ , and the patterns $ipo{p}_{p,e}$ and $opo{p}_{p,e}$ from Definition 10.

• –

Predicate-object frequency (pof). This is similar to pf, but this metrics also differentiates between the objects.

$$\begin{array}{r}pof(ipo{p}_{p,e})=|\{s\mid (s,p,e)\in {\mathcal{G}}^{\prime }\}|\end{array}$$

(5)

$$\begin{array}{r}pof(opo{p}_{p,e})=|\{o\mid (e,p,o)\in {\mathcal{G}}^{\prime }\}|\end{array}$$

(6)

–

Entropy predicate-object frequency (epof). This is similar to epf, but this metrics also differentiates between the objects. Let $pop\in \{ipo{p}_{p,e},opo{p}_{p,e}\}.$

$$\begin{array}{r}epof(pop)=\{\begin{array}{ll}-\frac{pof(pop)}{|{\mathcal{G}}^{\prime }|}\times \log (\frac{pof(pop)}{|{\mathcal{G}}^{\prime }|})& \text{if }pof(pop)>0\\ 0& \text{otherwise}\end{array}\end{array}$$

(7)

–

Inverse predicate-object frequency (ipof). This is similar to ipf, but this metrics also differentiates between the objects. Let $pop\in \{ipo{p}_{p,e},opo{p}_{p,e}\}.$

$$\begin{array}{r}ipof(pop)=\{\begin{array}{ll}\frac{1}{pof(pop)}& \text{if }pof(pop)>0\\ 0& \text{otherwise}\end{array}\end{array}$$

(8)

Let us consider the following triples from Table 3. We have $|{\mathcal{G}}^{\prime }|=3$ .

Since dbr:French_Revolution was already visited, we only consider the ingoing patterns. Given the above definitions, we have the followings scores:

• –

$pf(ip{p}_{\text{dbo:battle}})=1$

–

$pf(ip{p}_{\text{dbo:isPartOfMilitaryConflict}})=2$

–

$epf(ip{p}_{\text{dbo:battle}})=-\frac{pf(ip{p}_{\text{dbo:battle}})}{|{\mathcal{G}}^{\prime }|}\times \log (\frac{pf(ip{p}_{\text{dbo:battle}})}{|{\mathcal{G}}^{\prime }|})=-\frac{1}{3}\times \log \frac{1}{3}\approx 0.16$

–

$epf(ip{p}_{\text{dbo:isPartOfMilitaryConflict}})=-\frac{pf(ip{p}_{\text{dbo:isPartOfMilitaryConflict}})}{|{\mathcal{G}}^{\prime }|}\times \log (\frac{pf(ip{p}_{\text{dbo:isPartOfMilitaryConflict}})}{|{\mathcal{G}}^{\prime }|})=-\frac{2}{3}\times \log \frac{2}{3}\approx 0.12$

The scoring metric used in Figure 3 is pof. The score of the pattern $ipo{p}_{\text{dbo:isPartOfMilitaryConflict,dbr:French\_Revolution}}$ is 2 since there are two ingoing nodes of the dbr:French_Revolution that are connected to the latter with the predicate dbo:isPartOfMilitaryConflict. If the scoring metric was epof, the score would be $-\frac{2}{3}\times \log \frac{2}{3}\approx 0.12$ .

Definition 12 (Preference Function)

The preference function is a Boolean function that classifies a pattern as semantically relevant if it meets certain conditions. Let $\mathcal{K}\mathcal{G}=\{(s,p,o)|s\in \mathcal{E},o\in \mathcal{E}\cup \mathcal{L},p\in \mathcal{R}\}$ a KG. Let $d\in \mathcal{R}$ and $sc\in \mathcal{R}$ denoting predicates for domain and subclass information. Let $extrac{t}_{t}ype\in \mathcal{E}$ a type of events to retrieve. Let $p\in \mathcal{R}$ , $e\in \mathcal{E}$ , and a pattern $pp$ , $pp\in \{ip{p}_p,op{p}_p,ipo{p}_{p,e},opo{p}_{p,e}\}$ . We formally define as follows:

$$\begin{array}{rl}pre{f}_{f}p{p}_{d,sc,t_e}:\{ip{p}_p,op{p}_p,ipo{p}_{p,e},opo{p}_{p,e}\}& ⟶\{0,1\}\\ pp& ⟼\{\begin{array}{ll}1& \text{if }\mathrm{\exists }n\in \mathcal{E},\text{ such that }(p,d,n)\in \mathcal{K}\mathcal{G}\\ & \text{and}(n,sc,extrac{t}_{t}ype)\in \mathcal{K}\mathcal{G}\\ 0& \text{otherwise}\end{array}\end{array}$$

• –

  For example, $d=\text{rdfs:domain}$ , $sc=\text{rdfs:subClassOf}$ , $t_e=\text{dbo:Event}$ .

  The preference function prioritizes predicates with the highest scores from the $scoring$ step, favoring nodes with the correct types. We use the ontological equivalent predicates of rdfs:domain and rdfs:range. In DBpedia, we have (dbo:isPartOf MilitaryConflict,rdfs:domain,dbo:MilitaryConflict) and (dbo: MilitaryConflict, rdfs:subClassOf*, dbo:Event). Consequently, in (s,dbo:isPart OfMilitaryConflict,o), $s$ must be of type dbo:Event. With the preference function, the system prefers patterns with dbo:isPartOfMilitaryConflict over dbo:battle since the former has dbo:Military Conflict as its domain, a subclass of event type, while the latter lacks explicit information about its domain or range. In Figure 3, the preference function does not affect the selection of nodes to expand. Without the preference function, patterns are ranked in descending order of scores from the $scoring$ step.

  We have presented the event-centric subgraph extraction component of ChronoGrapher. We now present its event-centric KG population component.

  3.2. Event-Centric KG Population (RQ2)

  To build a comprehensive and fine-grained representation of events, ChronoGrapher incorporates a second component dedicated to constructing event-centric KGs. This process complements the subgraph extraction phase by enriching the retrieved events with contextual information. Such information may be explicitly encoded in the KG through IRIs or expressed in texts stored as literals.

  Algorithm 2 outlines the KG construction procedure. Starting from the events identified during the subgraph extraction step, the system applies two complementary triple enrichment strategies, one structure-based and one text-based, to build the event-centric KG:

5. Discussion

In this section, we reflect on the design choices, assumptions, and limitations of our approach. We begin by discussing the role of EventKG as the ground truth (Section 5.1) with an example. We then consider the methodological scope of our framework and motivate our design decisions, particularly the choice of a rule-based approach over learning-based alternatives (Section 5.2). Following this, we explore the generalisability of ChronoGrapher: both to new datasets (Section 5.3.1) and to different types of events beyond the historical domain we primarily focus on (Section 5.3.2). Lastly, we reflect on the potential uses of the event-centric KG produced by ChronoGrapher, and the kinds of usage and applications it supports (Section 5.4).

5.1. EventKG as the Ground Truth

As many parts of our evaluation rely on EventKG as a reference, we conducted a qualitative comparison on a few subevents of the French Revolution between subgraphs extracted by ChronoGrapher and their counterparts in EventKG. Our goal was to better understand the complementarity between the two systems.

Figure 6 provides a visual comparison between the outputs of EventKG and ChronoGrapher. In the top part of the figure, we observe that ChronoGrapher does not retrieve dbr:Flight_to_Varennes and dbr:Tennis_Court_Oath that are present in EventKG. Upon inspection, we found that these events are not explicitly typed as dbo:Event in DBpedia, which prevents ChronoGrapher from including them during traversal. Despite these omissions, ChronoGrapher also uncovers relevant sub-events absent from EventKG. For instance, it successfully identifies dbr:Battle_of_Amsteg and dbr:Invasion_of_Guadeloupe_(1794) as sub-events of the French Revolution, which arguably should be considered part of the historical narrative. In the middle part of Figure 6, we show that both EventKG and ChronoGrapher include temporal and spatial information. However, as illustrated in the bottom section of the figure, ChronoGrapher provides a more complete representation, offering additional sub-event links and richer actor associations.

Figure 6.

Comparison Between EventKG and the Output of ChronoGrapher With Two Events.

5.2. Methodological Scope

Our methodology adopts a heuristic, modular approach that prioritizes semantic transparency and temporal control in the construction of event-centric KGs. This design decision is motivated by the requirements of understanding and reasoning tasks, where explainability and domain alignment are essential. While basic in form, the approach performs effectively, as demonstrated in both automatic and user-based evaluations. Moreover, the focus of this work lies not in proposing a novel learning algorithm, but in defining a clear and extensible pipeline for event-centric KG construction and use. By anchoring event representation in a semantically coherent and temporally aware framework, we provide a reliable foundation for downstream learning-based methods, such as embedding models or graph neural networks, that could build upon the structured graphs produced. We are currently working on identifying the best syntactic representations to use to train embeddings for event-centric KGs. We believe this balance of simplicity, effectiveness, and extensibility offers practical value for real-world applications while supporting future integration with more complex models.

5.3. Generalisibility of ChronoGrapher

We discuss the generalisability of ChronoGrapher, both in terms of its adaptability to different datasets (Section 5.3.1) and its applicability to diverse types of events (Section 5.3.2).

5.3.1. Generalisibility to Other Datasets

ChronoGrapher is flexible and could be applied to other types of nodes or datasets, including those using the PROV vocabulary, which could also yield event-centric graphs. As a reminder, it consists of two components: (1) a pruned, semantically informed best-first search, and (2) a KG constructor. The search component is highly configurable through a lightweight configuration file. ²⁰ and supports various traversal strategies, such as

–

Semantically informed or random walks, with or without ground truths.

–

Target-based walks in the graph.

This is illustrated in our open-source implementation. ²¹ The search is also not bound to focus on events only, but can be configured to focus on any type of nodes, such as people or places. Lastly, the search can be run on any KG that is accessible through an HDT dump or a SPARQL endpoint. The constructor is adaptable, provided that predicate labels are retrievable (e.g., via SPARQL).

Furthermore, while ChronoGrapher does not currently implement incremental updates, its design allows for a practical workaround. In dynamic settings (e.g., live sports events), one could extract only the newly added parts of the dataset—centered, for instance, around new event nodes—and rerun ChronoGrapher on these subgraphs. This avoids reconstructing the full event-centric KG from scratch and enables more efficient updates.

5.3.2. Generalisibility to Other Event Types

While our evaluation primarily focuses on historical conflict events, we also explored the applicability of our approach to other domains, notably political and sports events. These types of events often differ structurally from historical ones in KGs: political events (e.g., elections) and sports events (e.g., Olympic competitions) tend to be organized as lists of sub-events (disciplines, rounds, or contests) within a broader event. Moreover, the semantic richness in these domains is often limited, with many relationships captured through generic predicates such as dbo:wikiPageWikiLink, which lack fine-grained semantics.

To assess performance in this context, we conducted additional experiments using DBpedia, incorporating dbo:wikiPageWikiLink as an accepted relation for traversal. Out of 42 political events and 982 sports events, 5% and 48%, respectively, received an F1 score of zero, with average F1 scores of 56.5% for political events and 22.5% for sports events (considering only one iteration to reduce noise from the dbo:wikiPageWikiLink links). These lower performances reveal structural and semantic limitations in the current DBpedia encoding of such events. For instance, we observe that some relevant nodes lack explicit rdf:type information. These insights highlight important directions for future work, including better category integration, improved type inference, and more precise handling of weakly typed links in domain-specific event graphs.

5.4. Usage of the Event-Centric KG

In this work, ChronoGrapher was designed to support a wide variety of question types by focusing on events, people, locations, frame-based relationships, and causal interactions. The event-centric KGs can still capture a rich set of relationships between entities and events. This approach allows us to answer questions ranging from straightforward fact retrieval (e.g., Who was involved? or Where did the event take place?) to more complex reasoning questions (e.g., What caused this event? or What were the consequences?).

However, we acknowledge that the types of questions are inherently constrained by the content it contains. As is the case with any knowledge-based task, the quality and scope of the questions answered are determined by the data represented in the KG. This limitation is a natural consequence of working with structured data, where the knowledge captured reflects the domain’s scope and the granularity of its representation. Furthermore, ChronoGrapher’s design aligns with the broader goal of narrative construction, which aims to facilitate understanding and reasoning about events within a narrative context. In our previous work, we identified specific requirements for narrative structures that inform the development of such knowledge graphs, ensuring that Chronographer can address a variety of questions within its scope and purpose (Blin et al., 2024).

Adapting ChronoGrapher to a new dataset requires some familiarity with the target KG’s ontology, particularly to identify predicates analogous to those in the SEM ontology (e.g., for time, location, or actor roles). While this setup currently requires manual configuration, we envision an interface that could assist non-expert users. Such an interface could suggest relevant predicates based on common usage in the dataset and help define event-centric filters through guided forms or templates. In practice, applying ChronoGrapher to new domains may also involve collaboration with a domain curator or a developer familiar with the schema. These additions would help extend ChronoGrapher’s applicability beyond users familiar with coding.

6. Conclusion

We address the challenge of automatically constructing event-centric KGs from generic ones. We present ChronoGrapher that extracts event-centric subgraphs from generic KGs, and builds event-centric KGs. To extract event-centric subgraphs (RQ1), ChronoGrapher contains a pruned, semantically informed, best-first search traversal integrating event-centric filters to prune the search space and a ranking step for node prioritization, yielding F1 scores of 0.78 and 0.68 for DBpedia and Wikidata. To generate event-centric KGs (RQ2), ChronoGrapher combines a structured triple enrichment based on IRIs and a textual triple enrichments based on abstracts encoded a literals in KGs, achieving F1 scores of 0.67 and 0.76 for DBpedia and Wikidata, and information extraction from text. To evaluate whether integrating event-centric KGs enhances the performance of LLMs compared to using LLMs alone (RQ3), we conduct first experiments comparing different prompts on an event-centric QA setting, and show that prompts enriched with event-centric KG triples give more factual answers while maintaining succinctness (2.95 vs. 1.11 and 2.24).

Future work will focus on improving ChronoGrapher in a number of directions, including expanding the search method to reach more sub-events using, for example, EventKG for additional type information; expanding the event-centric KG population beyond EventKG to tackle data noise and incompleteness; improving the modeling of complex entities; considering novel ontologies and vocabulary for the event representation (e.g., RDF-star); and use more sophisticated RAG-based methods for a larger user study. We also plan to work on additional quantitative and automatic metrics for a better evaluation of the event-centric KGs.

Supplemental Material Statement: Source code for our system, the baselines we (re-)implemented and the experiments are available on Github. ²² The source code contains the predicate labels that were used to generate the event-centric KG (Section 3.2), pointers to download the datasets and more generic statistics on events and their sub-events (Section 4.1), the 12 events for parameter selection (Section 4.2.1), additional results on experiments on the end-to-end system combining the event extraction and the graph generation and the manual annotations for the causation frames (Section 4.2.3), and all code, prompts and data linked to the user study (Section 4.3).