Knowledge Graph Lakehouse: A Cloud-Native Architecture for Managing Enterprise Knowledge Graphs at Scale

Knowledge Graph Lakehouse: A Cloud-Native Architecture for Managing Enterprise Knowledge Graphs at Scale B. Ahmada,∗ , C. G. Schuetza and L. Bozzatob a Institute of Business Informatics – Data & Knowledge Engineering, Johannes Kepler University Linz, Altenberger Str. 69, 4040 Linz, Austria

arXiv:2611.04899v1 [cs.DB] 3 Nov 2026

b Dipartimento di Scienze Teoriche e Applicate, Università degli Studi dell’Insubria, Via O. Rossi 9, 21100 Varese, Italy

ARTICLE INFO

ABSTRACT

Keywords: Knowledge Graph Management Contextualized Knowledge Graphs Data Lakehouse Knowledge Graph OLAP Scalable Data Management

Modern data architectures for integrating heterogeneous data sources to discover actionable knowledge include the data warehouse, the data lake, and the data lakehouse, which combines the flexibility of the data lake with the structured data management capabilities of the data warehouse through metadata, indexes, and caching. Enterprise knowledge graphs (KGs) offer an alternative approach to such integration for the purposes of data analysis, but handling them at scale must address the Three Vs of big data: volume, velocity, and variety. Contextualized KGs (CKGs) meet part of that challenge by enriching facts with contextual information, yet many applications require only a contextspecific subset of that knowledge. We propose the Knowledge Graph Lakehouse (KG Lakehouse), a cloud-native microservice architecture that adapts the data lakehouse paradigm for management of CKGs at scale. The KG Lakehouse indexes incoming source documents along configurable context dimensions and stores these documents in a data lake, from which application-specific CKGs are constructed on demand instead of maintaining a single, monolithic KG. We realize the proposed architecture as a proof of concept, with independently deployable services built from established cloud technology; context dimensions and format-specific document handling enter as configuration, leaving the architecture independent of the application domain. We evaluate the implemented system in experiments on a distributed cluster deployment.

1. Introduction Modern data architectures for integrating heterogeneous data sources to discover actionable knowledge include the data warehouse, the data lake, and the data lakehouse (see [37] for an overview). A data warehouse stores structured data that is clean and consistent [62, p. 63], optimized for recurring analytical tasks, with analytical results typically summarized in reports or dashboards [62, p. 625]. A data lake retains raw or minimally processed data to support flexible exploratory analysis and future analytical use cases [62, p. 624]. Although flexible, the data lake’s schema-on-read approach requires complex cleaning and transformation before analysis [62, p. 625], increasing processing overhead and complicating data management for large datasets. The data lakehouse [14] combines the flexibility of the data lake with the structured data management capabilities of the data warehouse by leveraging metadata, indexes, and caching to support complex data analysis while providing storage efficiency and query flexibility. Enterprise knowledge graphs have been proposed as an alternative approach to integrating heterogeneous data sources; see [55] for one such proposal. A knowledge graph (KG) comprises facts about real-world entities and their relationships. KGs have been described as “large networks of entities, their semantic types, properties, and relationships” [41], “a set of interconnected typed entities and their attributes“ [35, p. 1] with possibly arbitrary relationships [49]. Apart from the instance-level facts, or assertional ∗ Corresponding author

ahmad@dke.uni-linz.ac.at (B. Ahmad)

knowledge (ABox) [49], a KG also often comprises terminological or ontological knowledge (TBox) representing “the vocabulary used in the knowledge graph” [35, p. 2] and enabling ontological reasoning over the facts [19]. Unlike open KGs, an enterprise KG is “typically internal to a company and applied for commercial use-cases” [38, p. 71:4], containing relevant knowledge for an organization [19]. Due to their versatility, enterprise KGs “are a natural data model for data integration” [55, p. 10]. By combining assertional and ontological knowledge, enterprise KGs capture both data and their semantics, making it easier for data consumers to discover actionable knowledge [55]. Effective deployment of enterprise KGs relies on a KG management system (KGMS), which not only provides ontological reasoning capabilities but also supports large-scale data management and analytical tasks [19]. The knowledge represented in enterprise KGs expands and evolves over time, incorporating information from various structured and unstructured sources and existing at multiple levels of granularity and abstraction [48]. Data sources continuously provide large volumes of heterogeneous information, often at high velocity, that must be integrated into the enterprise KG. The KGMS must therefore be able to handle the Three Vs of big data [43]: volume, velocity, and variety. At the conceptual level, contextualized KGs [56, 21] provide a model for managing heterogeneous and evolving knowledge by enriching facts with contextual information. In a contextualized KG (CKG), facts are typically organized into subgraphs, each corresponding to a distinct context. To represent CKGs, the Knowledge Graph OLAP (KGOLAP) model [52] employs a multidimensional context

ORCID (s): 0000-0001-9610-1516 (B. Ahmad); 0000-0002-0955-8647

(C.G. Schuetz); 0000-0003-1757-9859 (L. Bozzato)

B. Ahmad et al.

Page 1 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale Knowledge Graph Cache Transient Contextualized Knowledge Graphs

Document Stream Ingestion

Contextual Operations and Knowledge Graph Transformations

Contextual Indexing

Reporting

Data Mining Multidimensional Context Assignment Ingestion Tier

On-Demand Knowledge Graph Construction

Data Lake Tier

Reasoning Knowledge Graph Tier

OLAP Tier

Frontend Tier

Figure 1: Conceptual overview of the KG Lakehouse

model with hierarchically organized dimensions. The dimensions capture different contextual characteristics, e.g., geographic scope, temporal applicability, and topic. The hierarchical organization of the dimensions supports the representation of contexts at different levels of granularity (e.g., sector and country for geographic scope, and day and month for temporal applicability). Dedicated operations, adapted to KGs from traditional online analytical processing (OLAP), enable the navigation and combination of contexts as well as the transformation of the graph structure as required for specific analytical tasks. At the architectural level, a cloud-native microservice architecture provides the modularity, elasticity, and scalability required to manage CKGs at scale. Different services can be independently developed, deployed, and horizontally scaled according to workload requirements. New services can be introduced to integrate additional data sources without affecting existing components. A microservice architecture may further leverage the contextual partitioning of knowledge in CKGs to enable parallel processing of independent contexts for improved performance. Even with CKGs and a cloud-native microservice architecture, maintaining a single, monolithic enterprise KG at scale remains challenging and introduces overhead that many applications do not require. A KG typically covers a variety of topics rather than focusing exclusively on a single aspect of the real world [49]. For specific tasks, however, only a subset of the knowledge represented in an enterprise KG may be relevant, since “most people do not care about all entities that exist in the world, but rather a small fraction or subset that is personally relevant to them” [48, p. 43]. For example, in air traffic management, which serves as a motivating use case and setting of the running example throughout this paper, a KG may represent knowledge about the air traffic network, including infrastructure, airspace, operational events, weather conditions, and flight plans [53]. A pilot preparing for a flight from Munich to Vienna only requires knowledge of weather conditions and operational events, such as airspace closures and operational restrictions of navigation aids, that are relevant to the airspace sectors along the planned route on the day of the flight, rather than B. Ahmad et al.

knowledge about the entire European air traffic network [54]. An air traffic controller, on the other hand, requires the same contextual knowledge, together with the flight plans as well as positions of aircraft operating in the supervised airspace sector and its adjacent sectors during a specific period of responsibility. Hence, maintaining a single, monolithic KG is both impractical and unnecessary for many applications, which instead require only context-specific subsets of the available knowledge. We propose the Knowledge Graph Lakehouse (KG Lakehouse), a cloud-native architecture that adapts the data lakehouse paradigm [14] for CKG management. Figure 1 provides a conceptual overview of the proposed architecture. Documents of various types continuously arrive from different sources in a data stream. During ingestion, the documents are analyzed and indexed along configurable context dimensions (e.g., location, time, and topic) before being stored in the data lake. Instead of maintaining a single, monolithic KG, the KG Lakehouse maintains a contextual index of source documents from which application-specific CKGs are dynamically constructed as required by the analytical tasks. In addition to contextual indexing, the KG Lakehouse maintains a cache of previously built CKGs to reduce the overhead of repeated construction. Contextual operations, which allow for selecting and merging contexts, and transformation operations facilitate adaptation of CKGs to the requirements of specific frontend applications, including reporting, data mining, and rule-based reasoning. The proposed architecture is independent of any particular application domain. The context dimensions are configurable, the format-specific analysis of documents is modular. We illustrate and motivate the proposed architecture on the case of air traffic management, which serves as the setting for our running example and evaluation. We stress, though, that the implementation can also be configured for other application domains. The main contributions of this paper are as follows. – Architecture. We specify the KG Lakehouse, a cloudnative architecture for CKG management that exploits the context-specific, multi-perspective nature of knowledge to Page 2 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

construct tailored CKGs on demand instead of maintaining a single, monolithic KG. We formalize the architecture in terms of the KG-OLAP model. The KG-OLAP model defines a cube as a mapping from contexts to knowledge modules. The KG Lakehouse defines that mapping over the indexed source documents, so that constructing a CKG on demand computes, for the requested contexts, the same modules that a KG-OLAP cube materialized in advance from the same documents would hold. – Implementation. We realize the architecture as a proof of concept, implemented as a set of independently deployable services built from established cloud technologies and operated on a container platform. The implementation demonstrates feasibility of the architecture. The modular design makes the implementation independent of the application domain: the context dimensions and the format-specific handling of documents are supplied as configuration, so that serving another domain is a matter of declaration rather than of reworking the services. The source code and the deployment configuration are openly available [4]. – Evaluation. We evaluate the implemented system in five experiments on a distributed cluster deployment, which test the system along the Three Vs of big data. The experiments show that ingestion and indexing keep pace with arriving documents, that the constructed CKGs pass independent correctness checks at every level of the context hierarchies, and that the cost of constructing a CKG follows the scope of the CKG rather than the size of the corpus. A further experiment compares on-demand construction with a cube that is materialized in advance, in run time and in memory consumption, for the same requested knowledge. The experimental setup, the scripts, and the measured data are openly available [3]. Related work focuses on different aspects along the big data analysis pipeline, including graph storage layouts over data lakes, building graphs on streaming data, or distributed and parallel query processing, which serve an already existing graph. Federated and virtual knowledge graphs avoid maintenance of a permanent copy but answer each query by delegating the query to remote endpoints or to (relational) sources linked by a mapping. The KG Lakehouse, however, records the contexts that the content of each raw document is valid in or relevant for. Once a request for a KG specifies the required contexts, the KG Lakehouse retrieves the documents relevant for the contexts and lifts knowledge from those documents. The remainder of this paper is organized as follows. Section 2 presents a use case from Air Traffic Management serving as a running example. Section 3 revisits the multidimensional context model of KG-OLAP for the representation of CKGs. Section 4 describes and formalizes the proposed architecture. Section 5 presents a proof-ofconcept implementation. Section 6 reports the results of the experimental evaluation. Section 7 reviews related work. Section 8 concludes the paper. B. Ahmad et al.

2. Use Case: Air Traffic Management We demonstrate the KG Lakehouse using the case of air traffic management (ATM), where the knowledge required by different stakeholders for different tasks is inherently context-specific [53], must be delivered under time-critical conditions, and relies on information sources exhibiting the Three Vs of big data. To ensure safe and efficient air traffic operations, various stakeholders, including pilots and air traffic controllers, require the right information for the right context at the right time. This information originates from a large number of highly heterogeneous sources describing different aspects of the air traffic network, producing large volumes of data that are continuously updated. Different information service providers distribute ATM information through the System Wide Information Management (SWIM) platform [30]. Permanent and temporary updates on infrastructure and airspace are published by air navigation service providers (ANSPs), superseding baseline information and previously disseminated updates. For example, a navigation aid may become temporarily unavailable, resulting in a change of its operational status for a specific period, or its assigned frequency may change permanently. Construction work near an airport’s runway may constitute a potential operational hazard. Meteorological service providers publish regular weather observations and forecasts, as well as updates on adverse weather conditions. For example, an aerodrome reports multiple weather observations per day, and thunderstorms are significant weather events of interest for air traffic operations. Flight plans are submitted and updated throughout their life cycle, depending on weather conditions and traffic demand. Other information services provide aircraft positions derived from broadcasts sent via Automatic Dependent Surveillance–Broadcast (ADS-B), resulting in a continuous stream of surveillance information. ATM information is exchanged between services and applications following various standardized exchange models. The Aeronautical Information Exchange Model (AIXM) [31] represents information about airport and navigation infrastructure, airspace, and operational events, which are commonly disseminated through Notices to Airmen (NOTAMs). The ICAO Meteorological Information Exchange Model (IWXXM) [68] represents meteorological observations and forecasts, which are disseminated through Meteorological Aerodrome Reports (METARs), Terminal Aerodrome Forecasts (TAFs), and Significant Meteorological Information (SIGMET) messages. The Flight Information Exchange Model (FIXM) [32] represents flight plans, including planned flight trajectories. In addition, aircraft continuously broadcast their positions using Automatic Dependent Surveillance–Broadcast (ADS-B), providing information about their actual trajectories. These messages are commonly encoded as XML or JSON documents. KGs may serve as an integration layer for the diverse ATM information exchanged over SWIM. An ATM KG may comprise the knowledge about the world as relevant for air traffic operations. For example, in the AISA [5] and Page 3 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

AWARE [15] projects, which investigate the integration of AI capabilities into the controllers’ ATM software, a KG serves as an integrated data layer. The information required for various tasks, e.g., supervising a particular airspace sector or conducing a particular flight, and subtasks, e.g., predicting trajectories of individual aircraft or predicting flight delay, can be extracted from the ATM KG. In the European air traffic network, tens of thousands of flights are conducted every day [29], connecting thousands of aerodromes of different sizes and traversing a large number of airspace sectors. A single, monolithic ATM KG representing the operational environment relevant for air traffic operations across Europe may therefore grow to a substantial size. The continuous arrival of updates from heterogeneous sources makes maintaining the ATM KG up to date challenging, particularly given the time-critical nature of ATM information, where stakeholders require relevant information immediately. Many ATM applications do not require the entire ATM KG simultaneously, making the maintenance of a single, monolithic ATM KG unnecessary for many use cases. For example, a pilot briefing for a specific flight only requires the subset of knowledge about infrastructure, airspace, and weather relevant to that flight [60]. Similarly, the training and application of machine learning models typically require only task-specific subsets of knowledge. For example, flightdelay prediction models are often trained for individual aerodromes [16].

3. Multidimensional Context Model For the representation of CKGs, we adopt the KGOLAP framework [52]. The KG-OLAP framework organizes knowledge within a multidimensional space of contexts—a contextual (hyper-)cube comprising multiple cells, with each cell representing a context. The KG-OLAP model, which is based on description logic, distinguishes two layers: the upper layer, which defines the multidimensional schema of the cube and the context-independent knowledge, and the lower layer, which contains the knowledge associated with the individual cells. In this section, we revisit the multidimensional model of the KG-OLAP framework [52], which serves as the basis for the formalization of our notion of CKGs and their derivation from ingested documents. For reference, Table 1 gives an overview of the notation elements used in the formalization throughout this work. A cube vocabulary Ω = (NRΩ , NCΩ , NIΩ ) consists of atomic roles NRΩ , concepts NCΩ , and individuals NIΩ . The cube vocabulary also defines a set of dimensions 𝐷 ⊆ NRΩ and levels 𝐿 ⊆ NIΩ . For each dimension 𝐴 ∈ 𝐷, the members 𝐷𝐴 ⊆ NIΩ are partially ordered by ≺𝐴 in a tree hierarchy with a unique root 𝑎𝑙𝑙𝐴 . A mapping 𝑙𝑒𝑣 ∶ 𝐷𝐴 → 𝐿𝐴 assigns members to levels, which are themselves ordered by ≺𝐿 . In the following we will also use ⪯𝐴 and ⪯𝐿 to denote 𝐴 𝐴 the non-strict variant of the ≺𝐴 and ≺𝐿 relations. 𝐴

B. Ahmad et al.

Table 1 Overview of the notation used in the formalization Symbol

Meaning

Ω, Σ Σ Σ 𝐷, 𝐹 𝐷𝐴 , 𝐿𝐴

Cube and object vocabularies Object language over Σ Global TBox in Σ Sets of dimensions and cell names Dimension members and levels for dimension 𝐴, with 𝑙𝑒𝑣 ∶ 𝐷𝐴 → 𝐿𝐴 Member and level ordering relations Multidimensional space of dimensional vectors Dimensional vector (coordinates) in 𝔇Ω Bijective mapping from coordinates to cells 𝐹 Coverage relation between vectors/cells cells-to-module mapping Upper layer: coverage, cell-to-module mapping , and global TBox Σ Local knowledge module (ABox) of cell 𝑐 KG-OLAP cube ⟨𝔊, 𝐾𝐹 ⟩ Set of ingested documents Multidimensional index, Idx ⊆ 𝐹 × 𝐷𝑜𝑐 Extraction function: document to raw data items Context assignment: raw data item to a set of dimensional vectors, 𝜅 ∶  → 2𝔇Ω Set of raw data items Semantic lifting: raw data item to assertions Raw data items associated with cell 𝑐 Scope vector and level assignment of a KG specification Coordinate coarsening to the levels of 𝐥 TBox-extended module, 𝑀𝑐 = 𝐾𝑐 ∪ Σ

≺𝐴 , ≺𝐿𝐴 𝔇Ω 𝐝 𝖼𝗇(𝐝) ⪯  𝔊 𝐾𝑐 𝔎 𝐷𝑜𝑐 Idx 𝜙 𝜅  𝜆𝑆,Σ 𝑅𝐷𝑐 𝐞, 𝐥 𝜌𝐥 𝑀𝑐

Cells of the cube are identified by their coordinates in the multidimensional space: the coordinates of a cell for all the dimensions are represented as a dimensional vector. Formally, with |𝐷| = 𝑘, we define a dimensional vector as the set 𝐝 = {𝐴1 ∶= 𝑑1 , … , 𝐴𝑘 ∶= 𝑑𝑘 } where every 𝑑𝑗 ∈ 𝐷𝐴𝑗 , with 1 ≤ 𝑗 ≤ 𝑘. The value given by 𝐝 to the dimension 𝐴 is denoted with 𝑑𝐴 . Definition 1 (Multidimensional space and cells). The multidimensional space 𝔇Ω is the set of all dimensional vectors 𝐝 = {𝐴1 ∶= 𝑑1 , … , 𝐴𝑘 ∶= 𝑑𝑘 } for dimensions 𝐴1 … 𝐴𝑘 ∈ 𝐷. The set of cell names 𝐹 ⊆ NIΩ provides unique identifiers for these coordinates via a bijective function 𝖼𝗇 ∶ 𝔇Ω → 𝐹 ; we denote by 𝖼𝗇− the inverse of 𝖼𝗇. Example 1 (Multidimensional space and cells). Figure 2 shows a KG-OLAP cube for the ATM use case of Section 2 with dimensions 𝐷 = {𝖳𝗂𝗆𝖾, 𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇, 𝖳𝗈𝗉𝗂𝖼}. The example simplifies the ATM cube schema of the implementation (Section 5) to three-level hierarchies with generic level and member names. In the 𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 dimension, the members 𝖶𝗂𝖾𝗇-𝖭 and 𝖶𝗂𝖾𝗇-𝖤 at level 𝖲𝖾𝖼𝗍𝗈𝗋 roll up to 𝖫𝖮𝖵𝖵, the Austrian flight information region, at level 𝖥𝖨𝖱, and further to the root member 𝖠𝗅𝗅-𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇: 𝖶𝗂𝖾𝗇-𝖭 ≺𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 𝖫𝖮𝖵𝖵 ≺𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 Page 4 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

𝖠𝗅𝗅-𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇. Likewise, the days 𝟤𝟦-𝖠𝗎𝗀 and 𝟤𝟧-𝖠𝗎𝗀 at level 𝖣𝖺𝗒 roll up to 𝖠𝗎𝗀 at level 𝖬𝗈𝗇𝗍𝗁 and then to 𝖠𝗅𝗅-𝖳𝗂𝗆𝖾, and the topics 𝖠𝗂𝗋𝗉𝗈𝗋𝗍 and 𝖭𝖺𝗏𝖺𝗂𝖽 at level 𝖤𝗅𝖾𝗆𝖾𝗇𝗍 roll up to 𝖨𝗇𝖿 𝗋𝖺𝗌𝗍𝗋𝗎𝖼𝗍𝗎𝗋𝖾 and then to 𝖠𝗅𝗅-𝖳𝗈𝗉𝗂𝖼. The dimensional vector 𝐝1 = {𝖳𝗂𝗆𝖾 ∶= 𝟤𝟧-𝖠𝗎𝗀, 𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 ∶= 𝖶𝗂𝖾𝗇-𝖭, 𝖳𝗈𝗉𝗂𝖼 ∶= 𝖠𝗂𝗋𝗉𝗈𝗋𝗍} identifies the cell 𝑐1 = 𝖼𝗇(𝐝1 ), shown at the front left of the figure. The vector 𝐝2 = {𝖳𝗂𝗆𝖾 ∶= 𝟤𝟧-𝖠𝗎𝗀, 𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 ∶= 𝖫𝖮𝖵𝖵, 𝖳𝗈𝗉𝗂𝖼 ∶= 𝖨𝗇𝖿 𝗋𝖺𝗌𝗍𝗋𝗎𝖼𝗍𝗎𝗋𝖾} identifies the covering cell 𝑐2 = 𝖼𝗇(𝐝2 ), and the vector of root members {𝖳𝗂𝗆𝖾 ∶= 𝖠𝗅𝗅-𝖳𝗂𝗆𝖾, 𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 ∶= 𝖠𝗅𝗅-𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇, 𝖳𝗈𝗉𝗂𝖼 ∶= 𝖠𝗅𝗅-𝖳𝗈𝗉𝗂𝖼} identifies the most general cell 𝑐⊤ . ◊

c⊤ VOR-DME

FMD

rdf:type

rdf:type

rdf:type FRE

VIE

servedBy

LNZ

servedBy

Airport

rdf:type

c2 servedBy

FRE

VIE

avail

CLOSED

OPEN

D ay g

status

113.5 MHz

INTERRUPT

Navaid

c4

FMD freq

ug -A

25 Wien-N

Wien-E

Sector

e

m Ti

B. Ahmad et al.

g Au

– the lower layer is defined by 𝐾𝐹 = {𝐾𝑐 }𝑐∈𝐹 , where every 𝐾𝑐 ⊆ Σ is a local assertional (ABox) knowledge module for a cell name 𝑐 ∈ 𝐹 .

Au

– the upper layer 𝔊 = ⟨⪯, , Σ ⟩ consists of the coverage relation ⪯, induced by the member orderings ⪯𝐴 for all 𝐴 ∈ 𝐷 and the cell association mapping 𝖼𝗇, a mapping  ∶ 𝐹 → 𝐾𝐹 that assigns to each cell name 𝑐 ∈ 𝐹 its corresponding knowledge module 𝐾𝑐 and a global terminological (TBox) component Σ ⊆ Σ expressing cell-independent axioms;

lAl

such that:

24

𝔎 = ⟨𝔊, 𝐾𝐹 ⟩

FRE

e

Definition 3 (KG-OLAP cube). A KG-OLAP cube 𝔎 over a cube vocabulary Ω and an object vocabulary Σ is a structure

h

The knowledge represented in each cell is then expressed in a language Σ , called the object language, which in turn is based on an object vocabulary Σ = (NRΣ , NCΣ , NIΣ ). We provide a simplified definition of KG-OLAP cube from [52], showing a clearer association of cells to their object knowledge contents:

t on

Example 2 (Context coverage). Continuing Example 1, 𝐝1 ⪯ 𝐝2 holds because 𝟤𝟧-𝖠𝗎𝗀 ⪯𝖳𝗂𝗆𝖾 𝟤𝟧-𝖠𝗎𝗀, 𝖶𝗂𝖾𝗇-𝖭 ⪯𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 𝖫𝖮𝖵𝖵, and 𝖠𝗂𝗋𝗉𝗈𝗋𝗍 ⪯𝖳𝗈𝗉𝗂𝖼 𝖨𝗇𝖿 𝗋𝖺𝗌𝗍𝗋𝗎𝖼𝗍𝗎𝗋𝖾. The cell 𝑐2 therefore covers 𝑐1 —and, by the same argument, all four sectorlevel cells of the 𝟤𝟧-𝖠𝗎𝗀 slice in Figure 2; every cell of the cube is covered by 𝑐⊤ . In contrast, the vector 𝐝3 = {𝖳𝗂𝗆𝖾 ∶= 𝟤𝟦-𝖠𝗎𝗀, 𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 ∶= 𝖶𝗂𝖾𝗇-𝖭, 𝖳𝗈𝗉𝗂𝖼 ∶= 𝖠𝗂𝗋𝗉𝗈𝗋𝗍} is not covered by 𝐝2 , because 𝟤𝟦-𝖠𝗎𝗀 𝖳𝗂𝗆𝖾 𝟤𝟧-𝖠𝗎𝗀: knowledge about the previous day lies outside the scope of 𝑐2 . ◊

M

As for the member orderings, we write 𝐝 ≺ 𝐞, and correspondingly 𝑐1 ≺ 𝑐2 , for the strict variant of the relation (i.e., if the two compared elements are distinct).

im l-T Al

Definition 2 (Context coverage). For two vectors 𝐝, 𝐞 ∈ 𝔇Ω , 𝐝 ⪯ 𝐞 holds if 𝑑𝐴 ⪯𝐴 𝑒𝐴 for every dimension 𝐴 ∈ 𝐷. For the corresponding cells 𝑐1 = 𝖼𝗇(𝐝) and 𝑐2 = 𝖼𝗇(𝐞), we write 𝑐1 ⪯ 𝑐2 to indicate that 𝑐1 is more specific than 𝑐2 (and we say that 𝑐2 covers 𝑐1 ).

All-Topic

c3

VIE

avail

All-Topic

c1

LNZ

Airport

The coverage relation ⪯ represents a hierarchical organization of cells: the relation on cells is induced by the member orderings ⪯𝐴 .

Topic

LNZ

Infrastructure

Element

flightsReroutedTo

LOVV

FIR

All-Location

All-Location

Figure 2: KG-OLAP cube for the ATM running example

Note that, with respect to the original definition of KGOLAP cube, the current definition highlights the contextual structure in 𝔊 (now defined in terms of coverage relations and module mapping) and considers the more specific case in which cells are associated with a single module containing ABox axioms. Figure 2 illustrates these notions with a cube from the ATM use case of Section 2: three dimensions with three-level hierarchies, four sector-level cells, and two covering contexts. Examples 1–4 explain the cube. Example 3 (KG-OLAP cube). The cube of Figure 2 assigns to the cell 𝑐1 of Example 1 the local knowledge module 𝐾𝑐1 = {𝖺𝗏𝖺𝗂𝗅(𝖫𝖭𝖹, 𝖢𝖫𝖮𝖲𝖤𝖣)}, recording the closure of Linz airport (𝖫𝖭𝖹) on 25 August in sector Wien-N. The sibling cells of the same slice record that Vienna airport (𝖵𝖨𝖤) remains open, 𝖺𝗏𝖺𝗂𝗅(𝖵𝖨𝖤, 𝖮𝖯𝖤𝖭), that the navigation aid 𝖥𝖱𝖤 transmits on 𝖿 𝗋𝖾𝗊(𝖥𝖱𝖤, “113.5 MHz”), and that the navigation aid 𝖥𝖬𝖣 is out of service, 𝗌𝗍𝖺𝗍𝗎𝗌(𝖥𝖬𝖣, 𝖨𝖭𝖳𝖤𝖱𝖱𝖴𝖯𝖳). The covering cell 𝑐2 holds knowledge that pertains to the infrastructure of the entire flight information region on that day rather than to a single sector. Flights bound for the closed airport are rerouted, and 𝖵𝖨𝖤 is temporarily served by 𝖥𝖱𝖤 while 𝖥𝖬𝖣 is interrupted: 𝐾𝑐2 = {𝖿 𝗅𝗂𝗀𝗁𝗍𝗌𝖱𝖾𝗋𝗈𝗎𝗍𝖾𝖽𝖳𝗈(𝖫𝖭𝖹, 𝖵𝖨𝖤), 𝗌𝖾𝗋𝗏𝖾𝖽𝖡𝗒(𝖵𝖨𝖤, 𝖥𝖱𝖤)}. The most general cell holds reference knowledge: 𝐾𝑐⊤ = {𝖠𝗂𝗋𝗉𝗈𝗋𝗍(𝖫𝖭𝖹), 𝖠𝗂𝗋𝗉𝗈𝗋𝗍(𝖵𝖨𝖤), 𝖵𝖮𝖱-𝖣𝖬𝖤(𝖥𝖱𝖤), 𝖵𝖮𝖱-𝖣𝖬𝖤(𝖥𝖬𝖣), Page 5 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

𝗌𝖾𝗋𝗏𝖾𝖽𝖡𝗒(𝖫𝖭𝖹, 𝖥𝖱𝖤), 𝗌𝖾𝗋𝗏𝖾𝖽𝖡𝗒(𝖵𝖨𝖤, 𝖥𝖬𝖣)}. The global TBox Σ , shared by all cells, may state, for example, that flights are rerouted only between airports: ∃𝖿 𝗅𝗂𝗀𝗁𝗍𝗌𝖱𝖾𝗋𝗈𝗎𝗍𝖾𝖽𝖳𝗈.⊤ ⊑ 𝖠𝗂𝗋𝗉𝗈𝗋𝗍, ⊤ ⊑ ∀𝖿 𝗅𝗂𝗀𝗁𝗍𝗌𝖱𝖾𝗋𝗈𝗎𝗍𝖾𝖽𝖳𝗈.𝖠𝗂𝗋𝗉𝗈𝗋𝗍.

closed airport whose flights are rerouted to the airport 𝖵𝖨𝖤— although no single module asserts all of these facts together. Propagation follows the coverage relation only: for instance, the frequency of 𝖥𝖱𝖤, asserted in the sibling cell for topic 𝖭𝖺𝗏𝖺𝗂𝖽, is not visible in 𝑐1 . ◊ Section 4 builds on this formal definition and describes the KG Lakehouse architecture tier by tier.

◊ We can formalize the DL semantics of this structure (and thus, its intended reading) by adapting the definitions of interpretation and model from the original KG-OLAP formalization [52]. Definition 4 (Interpretation). An interpretation for ⟨Ω, Σ⟩ is a structure ℑ = ⟨, ⟩ such that: (i).  is a DL interpretation of Ω ∪ Σ; (ii). for every 𝑐 ∈ 𝐹 , (𝑐) is a DL interpretation over Σ such that Δ(𝑐) = Δ and, for 𝑎 ∈ NIΣ , 𝑎(𝑐) = 𝑎 . Definition 5 (KG-OLAP cube model). An interpretation ℑ = ⟨, ⟩ is a KG-OLAP cube model of a cube 𝔎 iff the following conditions hold: (i). for 𝛼 ∈ Σ ,  ⊧ 𝛼 (satisfaction of global TBox); (ii). for every 𝑐 ∈ 𝐹 , (𝑐) ⊧ 𝐾𝑐 (satisfaction of local ABoxes); (iii). for 𝛼 ∈ Σ and 𝑐 ∈ 𝐹 , (𝑐) ⊧ 𝛼 (local satisfaction of TBox axioms); (iv). if 𝑐1 , 𝑐2 ∈ 𝐹 with 𝑐1 ≺ 𝑐2 in 𝔊 and (𝑐2 ) = 𝐾𝑐2 , then (𝑐1 ) ⊧ 𝐾𝑐2 (propagation of knowledge modules). We note that, considering the restricted definition of cube provided above, this definition of the semantics is also simplified with respect to the more general one provided in [52] (e.g., we associate only a module for each cell and we do not consider context classes). The KG-OLAP cube separates context-specific assertional knowledge (local modules 𝐾𝑐 ) from global terminological knowledge Σ . This separation enables reasoning across contexts while preserving the multidimensional structure of the data. The local knowledge modules 𝐾𝑐 are expressed in an object language Σ : in the original formulation of the KG-OLAP framework [52], the object language is the -RL description logic [21] over the vocabulary Σ. By the definition of the semantics, note that the KGOLAP model also supports knowledge propagation: if 𝑐1 ⪯ 𝑐2 , the assertions in the more general context 𝑐2 are inherited by the more specific context 𝑐1 . Knowledge propagation enables reasoning across different levels of granularity of the knowledge. Example 4 (Knowledge propagation). In the cube of Figure 2, 𝑐1 ⪯ 𝑐2 ⪯ 𝑐⊤ , and thus every cube model satisfies 𝐾𝑐2 and 𝐾𝑐⊤ also at 𝑐1 . Within 𝑐1 , the local closure assertion therefore combines with the inherited knowledge: 𝖫𝖭𝖹 is a B. Ahmad et al.

4. Architecture The KG Lakehouse manages contextualized knowledge graphs under the Three Vs of big data [43]: volume, velocity, and variety. Data arrive continuously, in the form of documents of heterogeneous formats, accumulating to a volume that exceeds what any individual analytical task typically draws on: a task often needs only the knowledge relevant for the context, not the entire enterprise KG. From this observation, two requirements follow. Documents must be ingested as they arrive, before the tasks that will use the documents are known, meaning that the ingestion of a document cannot wait for the task using the document. Ultimately, a query must be answered for the knowledge relevant for the contexts of interest for a particular task, the knowledge extracted from the documents available at query time, and recently arriving documents are not withheld from the answer because the system must wait for a monolithic KG to be rebuilt. The KG Lakehouse architecture meets adapts and extends the data lakehouse paradigm [14] for the management of CKGs. A data lakehouse retains raw data while imposing the management structure of a data warehouse: metadata, indexes, and caching. Similarly, the KG Lakehouse retains the arriving documents unchanged and imposes a contextual index: each document is recorded under the contexts which the document’s contents are valid for. When a query names the required contexts, the KG comprising the knowledge for those contexts is constructed on demand from the indexed documents rather than extracted from a materialized monolithic KG. Where a data lake defers interpretation of the documents to the moment of reading (schema on read), the KG Lakehouse determines the context on arrival while deferring interpretation to the query. Constructed KGs may be cached for reuse, but what the system holds durably is the documents and the index. The multidimensional context model of Section 3 supplies the structure for the constructed KGs. Dimensions with hierarchically organized members span the space of contexts, each context is a cell of the cube and carries its own local knowledge module, and the coverage relation orders contexts from the specific to the general. The index associates documents with cells, construction realizes the mapping from cells to modules, and the contextual operations are defined over the same notions. Figure 1 shows the resulting organization: five tiers, ordered along the path from an arriving document to a delivered CKG. The first two tiers handle the incoming

Page 6 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

documents, the remaining three tiers handle the work related to processing a query. – The Ingestion tier receives documents of heterogeneous formats and determines the contexts which the documents’ contents are valid for. – The Data Lake tier retains the documents and maintains the contextual index that records association between documents and contexts. – The Knowledge Graph tier constructs, for the contexts a query addresses, the local knowledge modules those contexts hold. – The OLAP tier selects and combines contexts, and renders the resulting cube into the representation that the query requested. – The Frontend tier receives queries and delivers the constructed CKG to the applications that consume the CKG, among them applications for reporting, data mining, and rule-based reasoning. The decomposition into tiers allows for the modularity, elasticity, and scalability required of a cloud-native architecture able to manage CKGs at scale. Each tier is delimited by what it commits to, that is, by what it undertakes to provide the other tiers, and not by the data it holds. Of the five, only the Data Lake Tier holds data durably, and it too is delimited by its commitment rather than by that holding: the tiers divide the work; they do not layer the storage. The other tiers depend on that commitment alone, and not on how a tier meets it, so a tier can be extended, or realized by other means, without disturbing them. Because the durable state is the documents and the index, constructing a graph carries no state of its own, and the capacity devoted to construction can therefore grow and shrink with demand. The index decouples the two sides of the path, so the capacity for ingesting documents and the capacity for answering queries are adjusted independently. Contexts partition the knowledge, and the work for distinct contexts is independent, which allows parallel processing of the contexts a query addresses. The proposed KG Lakehouse architecture is independent of the application domain. Domain-specific differences in the data are configurable parameters, including the cube schema, the dimensions, levels, and member hierarchies a client registers (Section 4.5), a content analyzer per source format on the arrival side to determine relevant contexts from the documents (Section 4.1), and a semantic-lifting function per source format on the query side (Section 4.3) to convert the raw documents into knowledge statements. The tiers themselves are defined over the multidimensional context model. Another source format is accommodated by an additional analyzer and lifter, and another domain by an additional cube schema. Air traffic management is the setting of the running example and of the evaluation, but the architecture is not limited to that domain. B. Ahmad et al.

Each of the following subsections presents and formalizes a particular tier of the architecture. How a running system can be built based on this architecture is the subject of Section 5.

4.1. Ingestion Tier The Ingestion Tier receives arriving documents and extracts the contextual metadata that assigns their content to the contexts in which it is valid. The ingestion tier derives no knowledge and builds no graph. Ingestion records the assignment of document to contexts, and defers the extraction of knowledge, the question what the content means; the interpretation happens at query time (Section 4.3). The work done when a document arrives is therefore independent of how the data will later be queried. A document is stored unchanged and remains the authoritative source of its own content. The analysis is separated from storage, so the rate at which documents arrive does not constrain the rate at which the data can be analyzed, and analysis capacity can be raised independently of the ingestion (Section 6). Analysis is format-specific. A content analyzer reads documents of one source format, so a further format is accommodated by a further analyzer rather than by a change to the tier. We illustrate the approach with an AIXM content analyzer, which processes documents describing events in the air traffic management (ATM) network. The extracted metadata describes the context in which the data is valid and is multidimensional, typically comprising temporal, spatial, and thematic dimensions, the thematic dimension covering topics such as airspace closures or navigation aid restrictions. Each dimension is organized hierarchically (e.g., day, month, and year). A document may hold several raw data items, and the analyzer treats each of them separately. Definition 6 (Raw data item). Let  denote the set of raw data items encoded in various formats (e.g., XML, JSON, CSV) from a set  of source-format schemas, such as the XML schema of AIXM. Example 5 (Raw data item). Consider the following simplified AIXM XML fragment describing the closure of Linz airport in the scenario of Figure 2: <AirportHeliport> <timeSlice> <validTime>25-Aug</validTime> <designator>LNZ</designator> <availability>CLOSED</availability> </timeSlice> </AirportHeliport>

This XML fragment corresponds to a raw data item 𝑥1 ∈  extracted from an ingested AIXM document 𝑑𝑜𝑐1 . ◊ Definition 7 (Extraction of raw data items from documents). Let 𝐷𝑜𝑐 denote the set of ingested documents. An extraction function 𝜙 ∶ 𝐷𝑜𝑐 → 2 Page 7 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

maps each document to a finite set of raw data items. Each raw data item 𝑥 ∈  represents a logical unit of information extracted from a document. Each raw data item 𝑥 ∈  is processed by a content analyzer, which extracts the dimensional vectors that position the item within the multidimensional space. Definition 8 (Context assignment). The mapping of raw data items to sets of points in the multidimensional space is defined by a function 𝜅 ∶  → 2𝔇Ω , which extracts a set of dimensional vectors 𝜅(𝑥) from a raw data item 𝑥. Each vector 𝐝 ∈ 𝜅(𝑥) defines a cell 𝖼𝗇(𝐝) to which the item is assigned; an item whose validity spans several members of a dimension yields one vector per covered member—one item, many cells. Example 6 (Context assignment). For the raw data item 𝑥1 ∈ 𝜙(𝑑𝑜𝑐1 ) of Example 5, the content analyzer reads three values from the fragment. The valid time 𝟤𝟧-𝖠𝗎𝗀 gives the day, the aerodrome designator 𝖫𝖭𝖹 gives the sector 𝖶𝗂𝖾𝗇-𝖭, and the element type AirportHeliport gives the topic 𝖠𝗂𝗋𝗉𝗈𝗋𝗍. The closure is valid on a single day, so 𝜅(𝑥1 ) contains exactly one dimensional vector, the 𝐝1 of Example 1. The item is thus assigned to the cell 𝑐1 = 𝖼𝗇(𝐝1 ) of Figure 2. ◊ The extracted contexts populate the contextual index of Section 4.2, which associates each document with its cells, so that construction reads only the documents of the queried cells rather than the whole corpus.

4.2. Data Lake Tier The Data Lake Tier manages the storage and contextual indexing of the ingested documents. This tier distinguishes between the physical storage of raw documents and the logical representation of raw data items extracted from these documents. This separation lets document storage and the index scale independently, and keeps the index small relative to the corpus (Section 6), so that a context lookup never scans the documents. The contextual index captures the association between cells and documents based on the contexts of the raw data items contained in the documents. Definition 9 (Contextual index). Let 𝜙 and 𝜅 be the extraction and context assignment functions of Section 4.1, and 𝖼𝗇 the mapping from coordinates to cells of Section 3. The contextual index is then defined as a relation Idx ⊆ 𝐹 × 𝐷𝑜𝑐 such that: (𝑐, 𝑑𝑜𝑐) ∈ Idx ⟺ ∃𝑥 ∈ 𝜙(𝑑𝑜𝑐), ∃𝐝 ∈ 𝜅(𝑥) ∶ 𝖼𝗇(𝐝) = 𝑐.

B. Ahmad et al.

Context assignment is performed at the level of raw data items, while the index is maintained at the level of documents. Since a document may contain multiple data items associated with different contexts, and each item may be assigned to multiple cells, a document may be linked to multiple cells. The index therefore captures a coarse-grained association between documents and contexts, while finegrained associations are recovered at query time. Example 7 (Contextual index). Consider the document 𝑑𝑜𝑐1 of Examples 5 and 6, with 𝜙(𝑑𝑜𝑐1 ) = {𝑥1 }, and a second AIXM document 𝑑𝑜𝑐2 with two raw data items, 𝜙(𝑑𝑜𝑐2 ) = {𝑥2 , 𝑥3 }: 𝑥2 reports the interruption of the navigation aid 𝖥𝖬𝖣 and 𝑥3 reports that Vienna airport remains open, both on 𝟤𝟧-𝖠𝗎𝗀 (Figure 2). Context assignment places 𝑥2 in the cell 𝑐4 , whose coordinates differ from 𝐝1 in 𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 ∶= 𝖶𝗂𝖾𝗇-𝖤 and 𝖳𝗈𝗉𝗂𝖼 ∶= 𝖭𝖺𝗏𝖺𝗂𝖽, and 𝑥3 in the cell 𝑐3 , differing from 𝐝1 only in 𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 ∶= 𝖶𝗂𝖾𝗇-𝖤. Restricted to these two documents, the contextual index is Idx = {(𝑐1 , 𝑑𝑜𝑐1 ), (𝑐4 , 𝑑𝑜𝑐2 ), (𝑐3 , 𝑑𝑜𝑐2 )} ∶ the document 𝑑𝑜𝑐2 is linked to two cells because its items belong to different contexts. ◊ Persisting the relation Idx materializes the association between cells and documents, and thereby separates a document’s physical location in storage from its logical positions in the KG-OLAP cube. At query time, the set 𝑅𝐷𝑐 of relevant raw data items for a context 𝑐 is derived by retrieving all documents associated with 𝑐 and extracting their raw data items again with 𝜙: ⋃ 𝜙(𝑑𝑜𝑐), 𝑅𝐷𝑐 = {𝑑𝑜𝑐∈𝐷𝑜𝑐 ∣ (𝑐,𝑑𝑜𝑐)∈Idx}

where 𝜙(𝑑𝑜𝑐) denotes the set of raw data items contained in document 𝑑𝑜𝑐. Retrieval therefore reads only the documents of the queried cells, and recovers their items by applying 𝜙 again rather than by storing the items themselves.

4.3. Knowledge Graph Tier The Knowledge Graph Tier is responsible for the transition from indexed raw data to a structured, contextualized knowledge graph. Rather than building graphs when documents arrive, it constructs local knowledge modules on demand, when a query names the contexts it needs. A constructed graph is not part of the durable state of the system. It is delivered to the client that requested it, while the documents and the index remain what the system maintains. Constructed modules may be retained for reuse (Section 4.3.4), without becoming authoritative. The Knowledge Graph Tier performs two functions. Resolution extracts the scope and the level assignment from a KG specification, and retrieves the documents that the index associates with the selected cells (Section 4.4), yielding the raw data items 𝑅𝐷𝑐 . Construction lifts those items into logical assertions and aggregates them into the local knowledge modules of the cube. Page 8 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

4.3.1. Cube Construction The construction process retrieves relevant raw data items for specific contexts on demand, based on a userdefined KG specification, and constructs a contextualized knowledge graph (CKG) in the form of a KG-OLAP cube. Construction begins with a KG specification. This specification defines the applicability of the desired CKG along the dimensions of the cube schema, in the ATM use case, its temporal, spatial, and thematic scope. Definition 10 (KG specification). A KG specification names a cube schema and assigns to each dimension 𝐴 ∈ 𝐷 at most one member 𝑒𝐴 ∈ 𝐷𝐴 , at any level of the dimension’s hierarchy, and optionally a target level 𝑙𝐴 ∈ 𝐿𝐴 . From the specification we extract the scope vector 𝐞 ∈ 𝔇Ω , obtained by completing the named members with the root 𝑎𝑙𝑙𝐴 of every unconstrained dimension, and the level assignment 𝐥. The scope 𝐞 and the level assignment 𝐥 are the parameters of the contextual operations, which define from them the cells of the result and the granularity at which their knowledge is delivered (Section 4.4). Whether reasoning is applied and in which representation the result is rendered accompany the specification but do not affect context selection. For example, a request for 𝖠𝗂𝗋𝗉𝗈𝗋𝗍𝖧𝖾𝗅𝗂𝗉𝗈𝗋𝗍 data for Austrian airspace during January 2018 constrains the time dimension to the member 𝖩𝖺𝗇𝗎𝖺𝗋𝗒 𝟤𝟢𝟣𝟪 at the month level (its ancestor, the year 2018, follows from the hierarchy), the location to the 𝖠𝗎𝗌𝗍𝗋𝗂𝖺 member at the territory level, and the topic to the 𝖠𝗂𝗋𝗉𝗈𝗋𝗍𝖧𝖾𝗅𝗂𝗉𝗈𝗋𝗍 member at the category level. Resolution parses the specification into the scope 𝐞 and the level assignment 𝐥. For each selected cell it then retrieves the identifiers of the documents that Idx associates with that cell. The raw data items associated with a context 𝑐 ∈ 𝐹 form the set 𝑅𝐷𝑐 introduced in Section 4.2, i.e., the items extracted by 𝜙 from the documents that the index Idx associates with 𝑐. The selected cells are not only those the scope covers. They include the covering contexts (e.g., national regulations) whose knowledge the covered cells inherit through the context coverage relation (⪯). Each selected cell, covered or covering, enters the construction with its own set 𝑅𝐷𝑐 . The covering modules reach the cells they cover only at delivery, through knowledge propagation (Section 4.4). Propagation never adds items to 𝑅𝐷𝑐 . The corresponding documents are retrieved from the lake and their content is extracted by 𝜙, obtaining the raw data items. Semantic lifting 𝜆 (Definition 11) turns each item into logical assertions, which are aggregated into the local knowledge modules 𝐾𝑐 (Definition 12). This design instantiates the formal KG-OLAP model [52] by materializing local knowledge modules from indexed data, where hierarchical dimensions ensure the correctness of OLAP operations. This process avoids full knowledge graph materialization by constructing only the contextrelevant fragments required for a given query.

B. Ahmad et al.

4.3.2. Extraction of Assertional Knowledge The transition from indexed raw data to formal graph assertions is performed by resolving the index Idx and applying semantic lifting to the raw data items derived from the indexed documents. Semantic lifting refers to the transformation of raw data items into a formal, machine-interpretable representation by mapping them to logical assertions defined over a given vocabulary. Let Idx ⊆ 𝐹 ×𝐷𝑜𝑐 denote the contextual index produced during ingestion. For a specific cell 𝑐 ∈ 𝐹 , the associated set of raw data items 𝑅𝐷𝑐 is used as input for semantic lifting. Definition 11 (Semantic lifting). A semantic lifting function 𝜆,Σ transforms each raw data item of format  into a set of logical assertions of the object language Σ 𝜆,Σ ∶  → 2Σ In the following, we write 𝜆 for 𝜆,Σ whenever the parameters are understood. Example 8 (Semantic lifting). Consider the cube of Figure 2 and the two ingested AIXM documents of Example 7: 𝑑𝑜𝑐1 , whose raw data item 𝑥1 states that Linz airport is closed on 25 August, and 𝑑𝑜𝑐2 , whose item 𝑥2 states that the navigation aid 𝖥𝖬𝖣 is out of service on the same day. Semantic lifting translates each item’s content to ABox assertions in the object language of the cube: 𝜆(𝑥1 ) = {𝖺𝗏𝖺𝗂𝗅(𝖫𝖭𝖹, 𝖢𝖫𝖮𝖲𝖤𝖣)}, 𝜆(𝑥2 ) = {𝗌𝗍𝖺𝗍𝗎𝗌(𝖥𝖬𝖣, 𝖨𝖭𝖳𝖤𝖱𝖱𝖴𝖯𝖳)}. The lifting 𝜆 operates on the content of an item alone. The cube plays no role in the transformation, and each item lifts to the same assertions under whichever cell it is indexed. The association with contexts is established separately, by the contextual index Idx: during ingestion, the time, location, and topic extracted from the same content yielded (𝑐1 , 𝑑𝑜𝑐1 ) ∈ Idx for the cell 𝑐1 of Example 1 and (𝑐4 , 𝑑𝑜𝑐2 ) ∈ Idx for the sibling cell 𝑐4 with 𝖳𝗈𝗉𝗂𝖼 ∶= 𝖭𝖺𝗏𝖺𝗂𝖽. Resolving the index at query time gives 𝑅𝐷𝑐1 = 𝜙(𝑑𝑜𝑐1 ) = {𝑥1 }, and aggregation yields the local module 𝐾𝑐1 = 𝜆(𝑥1 ) = {𝖺𝗏𝖺𝗂𝗅(𝖫𝖭𝖹, 𝖢𝖫𝖮𝖲𝖤𝖣)} of Example 3. ◊ Definition 12 (Knowledge Module Construction). The local knowledge module 𝐾𝑐 for a cell 𝑐 ∈ 𝐹 is defined as: ⋃ 𝐾𝑐 = 𝜆(𝑥) 𝑥∈𝑅𝐷𝑐

that is, the union of the assertion sets lifted from the raw data items associated with the cell 𝑐. The resulting KG-OLAP cube is the collection of the pairs ⟨𝑐, 𝐾𝑐 ⟩ for the selected cells, representing the assertional base (ABox) of the knowledge graph. Example 9 (Knowledge module construction). Continuing Example 8, suppose a third AIXM document 𝑑𝑜𝑐3 ∈ 𝐷𝑜𝑐 announces the operational consequences of the closure for Page 9 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

the entire flight information region and contains two raw data items, 𝜙(𝑑𝑜𝑐3 ) = {𝑥4 , 𝑥5 }: 𝑥4 states that flights bound for Linz are rerouted to Vienna, and 𝑥5 states that 𝖵𝖨𝖤 is temporarily served by the navigation aid 𝖥𝖱𝖤. Ingestion indexed the document under the cell 𝑐2 of Example 1, that is, (𝑐2 , 𝑑𝑜𝑐3 ) ∈ Idx, and thus 𝑅𝐷𝑐2 = 𝜙(𝑑𝑜𝑐3 ) = {𝑥4 , 𝑥5 }. The local knowledge module aggregates the lifted fragments of both items, 𝐾𝑐2 = 𝜆(𝑥4 ) ∪ 𝜆(𝑥5 ), yielding exactly the module 𝐾𝑐2 of Example 3.

◊

4.3.3. Integration of Terminological Knowledge While 𝐾𝑐 captures the assertional knowledge (ABox) derived from raw data for a specific context, the global TBox Σ governs the interpretation of the knowledge, the terminological component of the upper layer 𝔊 (Section 3). Shared across all cells, the TBox comprises, for example, axioms of domain-specific ontologies. By the cube-model semantics, the axioms of Σ hold in every cell. Reasoning within a cell therefore evaluates the extended module 𝑀𝑐 = 𝐾𝑐 ∪ Σ . When a cell is delivered with its inherited knowledge, the propagated module 𝐾𝑐⪯ (Section 4.4) takes the place of 𝐾𝑐 . Construction itself never materializes Σ into the modules. 𝐾𝑐 remains purely assertional, and the TBox enters only when reasoning is requested. The extended module provides the logical basis for inferring implicit knowledge within each context.

4.3.4. Caching On-demand construction concentrates its cost in semantic lifting, and successive queries overlap. Two analyses of the same region or period address many of the same cells. The system therefore caches constructed knowledge modules. The unit of caching is the formal unit of the model. An entry is a pair ⟨𝑐, 𝐾𝑐 ⟩, the constructed module of a single cell, serialized in one of the output representations and keyed by the cell identifier 𝖼𝗇(𝐝) that the contextual index also uses. The cache is thus a partial materialization of the cube mapping  ∶ 𝐹 → 𝐾𝐹 (see Section 3), covering the recently queried cells. Correctness follows from the shape of the construction ⋃ function. By definition, 𝐾𝑐 = 𝑥∈𝑅𝐷𝑐 𝜆(𝑥), hence the module is determined solely by the raw data items 𝑅𝐷𝑐 , which the index determines, and by the lifting 𝜆, which depends only on the content of each item, never on the query. Construction is therefore deterministic, and a cache hit is indistinguishable from a fresh construction. The cache can save time but cannot change a result. The same determinism yields a precise validity condition: an entry ⟨𝑐, 𝐾𝑐 ⟩ remains correct exactly as long as the index restricted to 𝑐 is unchanged. The condition is stable because stored documents are immutable. The store keeps each document exactly as it arrived, so the index is the only input to construction that B. Ahmad et al.

changes, and the index changes only through the ingestion pipeline. An invalidation mechanism enforces the validity condition with information the ingestion pipeline already possesses. Indexing a document computes the set of cells the 𝑅𝐷𝑐 of which the document extends, by the same manyto-many document–context assignment that fills the index. The pipeline announces precisely these cell identifiers, and the affected modules in the cache are discarded. Invalidation is exact: an arriving document removes the modules from the cache that document invalidates, and no others. Since a module can always be reconstructed from the indexed documents, a failing cache costs time, but never correctness. Caching at cell granularity, rather than at the granularity of query results, allows cached modules to feed the contextual operations of the OLAP Tier (Section 4.4). The delivered modules are unions of local knowledge modules. Coverage extends a cell by its covering cells, and roll-up merges the cells that coarsen to the same coordinates. A union assembled from cached modules is identical to one assembled from freshly constructed modules. Consequently, two queries need not coincide to share work. Any overlap in cells is reused, whatever their scopes or target granularities.

4.4. OLAP Tier The OLAP Tier operates on the contextualized knowledge graph as a multidimensional cube. Whereas the Knowledge Graph Tier constructs the local knowledge modules 𝐾𝑐 , the OLAP Tier determines which cells a query addresses and at which granularity their knowledge is delivered, and renders the result in a representation suited to the consuming application. It comprises two functions. The contextual operations select and combine cells. Slice and dice selects the cells the requested scope addresses, and roll-up merges the modules of covered cells into coarser contexts. The knowledge graph transformation then serializes the resulting cube as RDF quads, as a labeled property graph, or as a GraphFrame for distributed processing. The following subsections formalize both.

4.4.1. Contextual Operations Contextual operations manipulate the cube at the level of its cells, leaving the contents of the local knowledge modules unchanged. Slice and dice restricts the multidimensional space to the cells whose coordinates are comparable with the requested coordinates in every dimension. These are the cells the scope covers, together with the cells coarser in at least one dimension whose knowledge they inherit. Roll-up coarsens the granularity by mapping each covered cell to its ancestor at the target level and merging the modules of cells that collapse to the same coordinates, the union variant of the KG-OLAP merge operation [52]. In the KG Lakehouse, these operations are not applied to a standing cube. The system plans them over the contextual index and constructs the merged modules directly. The KG specification introduced in Section 4.3 supplies the two parameters of these operations: the requested coordinates (the scope) and, optionally, a target Page 10 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

level per dimension. Throughout, we identify a cube with its cell-to-module mapping. Definition 13 (Slice and dice). Let 𝐞 ∈ 𝔇Ω be the requested scope. Slice and dice restricts the cube  to the cells whose coordinates are comparable with the scope in every dimension, 𝐹𝐞 = {𝖼𝗇(𝐝) ∣ 𝐝 ∈ 𝔇Ω , ∀𝐴 ∈ 𝐷 ∶ 𝑑𝐴 ⪯𝐴 𝑒𝐴 or 𝑒𝐴 ⪯𝐴 𝑑𝐴 } yielding a new cube, the subcube |𝐹𝐞 ∶ 𝐹𝐞 → 2Σ , which assigns to each cell 𝑐 ∈ 𝐹𝐞 its local knowledge module 𝐾𝑐 . Comparability is checked per dimension, not on the dimensional vectors as wholes. 𝐹𝐞 therefore contains, besides the cells that the scope covers (𝑐 ⪯ 𝖼𝗇(𝐞)), every cell that is coarser than the scope in at least one dimension, including a cell coarser in one dimension and finer in another, which covers part of the scope without being comparable with the scope vector itself. Dropping such a cell would cut the covered cells off from knowledge they inherit. By knowledge propagation (Section 3), a cell inherits the assertions of every cell covering it. Because the dimension hierarchies are trees, every cell covering a cell of 𝐹𝐞 lies itself in 𝐹𝐞 . The subcube is closed under coverage, so the restriction loses no inherited knowledge. The module delivered for a covered cell extends its local module with the inherited assertions. Definition 14 (Propagated knowledge module). For a cell 𝑐 ∈ 𝐹 , the propagated knowledge module is ⋃ 𝐾𝑐 ′ , 𝐾𝑐⪯ = {𝑐 ′ ∈𝐹 ∣ 𝑐⪯𝑐 ′ }

the union of the local module of 𝑐 with the local modules of all cells covering 𝑐. Roll-up is guided by the level assignment 𝐥 of the KG specification (Section 4.3). Its definition rests on two auxiliary notions. Definition 15 (Ancestor at a level). For a member 𝑑𝐴 ∈ 𝐷𝐴 and a level 𝑙𝐴 ∈ 𝐿𝐴 , the ancestor of 𝑑𝐴 at 𝑙𝐴 is { 𝑒𝐴 if 𝑑𝐴 ⪯𝐴 𝑒𝐴 and 𝑙𝑒𝑣(𝑒𝐴 ) = 𝑙𝐴 , 𝑎𝑛𝑐𝑙𝐴 (𝑑𝐴 ) = 𝑑𝐴 if no such 𝑒𝐴 exists. The ancestor is unique because ≺𝐴 orders 𝐷𝐴 in a tree. Definition 16 (Coordinate coarsening). Given a level assignment 𝐥, the coordinate coarsening 𝜌𝐥 ∶ 𝔇Ω → 𝔇Ω applies the ancestor per dimension: 𝜌𝐥 (𝐝) = {𝐴 ∶= 𝑎𝑛𝑐𝑙𝐴 (𝑑𝐴 ) ∣ 𝐴 ∈ 𝐷}. Definition 17 (Roll-up). Given the subcube |𝐹𝐞 and a level assignment 𝐥, the roll-up is the cube  ′ ∶ 𝐹 ′ → 2Σ such that: – 𝐹 ′ = { 𝖼𝗇(𝜌𝐥 (𝖼𝗇− (𝑐))) ∣ 𝑐 ∈ 𝐹𝐞 , 𝑐 ⪯ 𝖼𝗇(𝐞) } (the coarsened cells); B. Ahmad et al.

– for each 𝑐 ′ ∈ 𝐹 ′ , the merged module is ⋃ 𝐾𝑐′′ = 𝐾𝑐⪯ , 𝑐 ∈ 𝑆𝑐 ′

where 𝑆𝑐 ′ = {𝑐 ∈ 𝐹𝐞 ∣ 𝑐 ⪯ 𝖼𝗇(𝐞) ∧ 𝜌𝐥 (𝖼𝗇− (𝑐)) = 𝖼𝗇− (𝑐 ′ )} is the set of covered cells that coarsen to 𝑐 ′ . The covering cells of 𝐹𝐞 contribute to the merged modules through the propagated modules 𝐾𝑐⪯ rather than as targets of their own. The contextual operations leave the terminological component unchanged, and the coverage relation restricts to the retained cells (for roll-up, the relation induced on the coarsened cells), so each result is again a cube ⟨𝔊′ , 𝐾𝐹 ′ ⟩ in the sense of Section 3. Both operations therefore compose, and the knowledge graph transformation (Section 4.4.2) consumes their result uniformly. Example 10 (Roll-up). In the cube of Figure 2, consider the two airport cells of the 𝟤𝟧-𝖠𝗎𝗀 slice: the cell 𝑐1 of Example 1, with 𝐾𝑐1 = {𝖺𝗏𝖺𝗂𝗅(𝖫𝖭𝖹, 𝖢𝖫𝖮𝖲𝖤𝖣)}, and its sibling 𝑐3 , whose coordinates differ from 𝐝1 only in 𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 ∶= 𝖶𝗂𝖾𝗇-𝖤, with 𝐾𝑐3 = {𝖺𝗏𝖺𝗂𝗅(𝖵𝖨𝖤, 𝖮𝖯𝖤𝖭)} (Example 3). Rolling up the 𝖫𝗈𝖼𝖺𝗍𝗂𝗈𝗇 dimension to level 𝖥𝖨𝖱 replaces both location coordinates by their ancestor 𝖫𝖮𝖵𝖵: the two cells collapse into a single target cell 𝑐 ′ , whose merged module unites their propagated modules, 𝐾𝑐′′ = 𝐾𝑐⪯ ∪ 𝐾𝑐⪯ . 1

3

The local contributions deliver the availability of both airports at FIR granularity; through the propagated modules, 𝑐 ′ also carries the knowledge inherited from the covering cells 𝑐2 and 𝑐⊤ of Example 3, such as the rerouting of flights from the closed 𝖫𝖭𝖹 to 𝖵𝖨𝖤. ◊ The KG Lakehouse does not first build the cube at source granularity and then merge the cells. Rather, the KG Lakehouse computes each source cell’s final coordinates up front and constructs the merged modules directly from the raw data items (Section 4.3). At the assertional level, the two orders coincide: merging the constructed modules equals constructing one module from the merged raw data items. Proposition 1 (Construction-time merge). For every target cell 𝑐 ′ , ⋃ ⋃ ⋃ 𝐾𝑐 = 𝜆(𝑥), 𝑅𝐷𝑆𝑐 ′ = 𝑅𝐷𝑐 , 𝑐 ∈ 𝑆𝑐 ′

𝑥 ∈ 𝑅𝐷𝑆 ′ 𝑐

𝑐 ∈ 𝑆𝑐 ′

that is, merging the constructed modules of the collapsing cells equals constructing one module from their combined raw data items. ⋃ Proof. Immediate from 𝐾𝑐 = 𝑥∈𝑅𝐷𝑐 𝜆(𝑥) (Section 4.3) and the associativity, commutativity, and idempotence of set union. The proposition makes no use of how 𝑆𝑐 ′ arises; it holds for every set of cells. The proposition, therefore, extends from the local to the propagated modules that roll-up delivers, by applying it to the coverage closure of the collapsing cells. Page 11 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

Proposition 2 (Construction-time merge with propagation). Let 𝑆𝑐⪯′ = { 𝑐 ′′ ∈ 𝐹 ∣ 𝑐 ⪯ 𝑐 ′′ for some 𝑐 ∈ 𝑆𝑐 ′ } be the coverage closure of 𝑆𝑐 ′ . For every target cell 𝑐 ′ , ⋃ ⋃ ⋃ 𝐾𝑐′′ = 𝐾𝑐⪯ = 𝐾𝑐 ′′ = 𝜆(𝑥), 𝑐 ∈ 𝑆𝑐 ′

𝑐 ′′ ∈ 𝑆 ⪯′ 𝑐

𝑥 ∈ 𝑅𝐷𝑆 ⪯

𝑐′

that is, the rolled-up module, inherited knowledge included, equals one construction from the combined raw data items of the collapsing cells and of every cell covering them. Proof. The second equality unfolds the propagated modules into local modules over the closure; the third applies Proposition 1 to 𝑆𝑐⪯′ . Because 𝐹𝐞 is closed under coverage, 𝑆𝑐⪯′ lies within the sliced subcube. Resolution already returns every cell the closure needs, and the construction path draws the raw data items of the covering cells alongside those of the covered ones. Two consequences follow. First, the system may compute each source cell’s final coordinates before any module exists and lift each raw data item exactly once into its merged target. No intermediate cube is built, merged, and discarded. Second, a merged module assembled from the cached modules of individual cells is identical to one constructed afresh, which is the composition half of the cache’s correctness argument (Section 4.3). Both identities concern asserted statements. When reasoning is requested, the derived knowledge is computed over the extended modules 𝑀𝑐⪯ = 𝐾𝑐⪯ ∪Σ (Section 4.3) and kept separate from the asserted modules.

4.4.2. Knowledge Graph Transformation The constructed cube is a set of pairs ⟨𝑐, 𝐾𝑐 ⟩, a logical object that consuming applications cannot process directly. The latter two flatten the modules into a single graph suited to whole-scope analytics. The three transformations are invoked in the same way. Each consumes the same stream of constructed statements and differs only in what it emits.

RDF quads. The quad representation is the canonical one, since it loses nothing of the cube. Each cell 𝑐 is identified by a context resource, and the assertions of 𝐾𝑐 occupy a named graph associated with that resource, its asserted module. Metadata statements record the structure. Each context declares its asserted module. When reasoning is requested, the derived assertions occupy a second, separate module, linked to the context and to the asserted module from which it was derived. Coverage between contexts is likewise stated explicitly. The vocabulary for this metadata is that of the CKR reference implementation [56, 22], so the output can be loaded by tooling built for contextualized knowledge repositories and for KG-OLAP [52].

Labeled property graph. The system maps statements onto nodes, edges, and properties by three rules of the kind established for RDF to property graphs [8]: a typing statement sets the label of the subject’s node; a statement B. Ahmad et al.

with a literal object becomes a property of the subject’s node; and a statement connecting two resources becomes an edge between their nodes. Labels, property keys, and edge labels are each the final segment of the corresponding identifier. Nodes are identified by resource identifier. A node without a typing statement carries a generic label. The namedgraph tags are not carried over. The modules of the selected cells merge into one property graph, in which the context resources and their metadata appear as ordinary nodes and edges.

GraphFrame. The GraphFrame representation applies the rules of the labeled property graph, but emits the result as two tables, one of nodes and one of edges, serialized so that a Spark session can load them directly and reconstruct a GraphFrame. This representation targets construction results too large for a single client, where the consumer is a compute cluster.

4.5. Frontend Tier The Frontend Tier receives KG specifications and delivers the constructed cubes. The tier adds no knowledge processing of its own. The OLAP Tier already delivers the cube in standard representations (Section 4.4), so the frontend’s task is access rather than translation. Any tool that reads those representations becomes, in effect, a frontend of the KG Lakehouse. The Frontend tier exposes a single entry point, and that entry point serves both directions of use. A client registers a cube schema and submits documents for ingestion. To query, it submits a KG specification and receives the constructed CKG as a stream, in the representation the specification names. Interactive use is not a separate path. An interactive client holds no data and carries no logic of its own, and reaches the system through the same entry point as any program. Nothing about that entry point is specific to the KG Lakehouse, so any programming environment can act as a client. The frontend ends where standard representations begin. Established ecosystems carry the analytics from there. The quad representation feeds standard Semantic Web tooling. For a pre-flight briefing, a specification names one route and one day. The returned cube loads into a triple store, and briefing rules query with SPARQL exactly the knowledge in scope, the runway closures and weather warnings along that route. Such rule-based briefing generation is established practice [60, 54]. The property-graph representation feeds graph databases and their analytics. Examples are a controller-support view of one region during the validity of a significant-weather message, and conflict detection that joins traffic with contextual knowledge [65]. The GraphFrame representation feeds cluster analytics. A specification wide enough for a season of flights yields the input for distributed feature extraction in trajectory prediction [34]. Finally, the consumer need not be a person or a batch job at all. For example, adaptive ATM software can maintain its situational picture by continuously requesting small, current Page 12 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

Ingestion Gateway

Ingestion Task

Ingestion Worker

Queue

Context Entries

Contextual Index

Transient CKGs

Graph Constructor

Documents

Document Content Analyzer

Document

Semantic Lifters

Document

Inference Engine Cache

Document Store

Ingestion Tier

Data Lake Tier

Knowledge Graph Tier Cells to Build

Web Console CKG Specification CKG Specification

Data flow Control flow

CKG

CKG

Query Gateway

Contextual Operations CKG Specification

CKG

CKG

Graph Transformations

Application

Frontend Tier

OLAP Tier

Figure 3: High-level architecture of the KG Lakehouse implementation

CKGs [1]. On-demand construction makes that pattern affordable, because the cost of each request depends on the scope of the query rather than the size of the corpus.

5. Implementation The proof-of-concept implementation of the KG Lakehouse demonstrates that the architecture of Section 4, with its commitments to on-demand construction and to domain independence, is realizable with established cloud technology, and serves as the instrument of the evaluation in Section 6. Figure 3 shows the components of the implementation and their interactions. The remainder of this section explains how each component is realized, and why. The implementation consists of five independently deployable services, three format engines, and the libraries they share, written in Java and deployed as container images on Kubernetes [42]. The source code, the deployment configuration, and a set of small worked examples are openly available [4].

Services and communication. Five services divide the work: a client-facing gateway, the Ingestion Service, the Query Service, the Graph Service, and the optional Inference Service. The gateway realizes the logical entry points of the architecture in one service, reached over HTTP. It receives documents on behalf of the Ingestion Tier (Section 4.1) and serves as the Query Gateway, the entry point of the Frontend Tier (Section 4.5). The proof of concept also ships the Web Console, an ordinary client of that entry point, which presents a returned cube as an interactive graph, a table, a cube view, or the raw serialization, and offers operational B. Ahmad et al.

views of query history, performance, and service health. The services are stateless and share no database, so each scales horizontally on its own bottleneck. They communicate in two ways only. Data ingestion is decoupled asynchronously using a message queue (Apache Kafka [61, 58]). The queue buffers bursts of arriving documents, while a pool of consumers processes the backlog. Indexing throughput therefore scales by adding consumers, without modifying other components. Conversely, query construction is coupled synchronously via remote procedure calls [36]. Since queries are interactive and latency-sensitive, the query execution path streams results to the user as they are generated. The split reflects the different cost profiles of the two workloads.

Storage. The storage architecture consists of three data stores, each selected for its access pattern and isolated behind a narrow interface. First, an object store (MinIO [45]) retains raw documents exactly as they arrive, serving as the authoritative copy of the raw data. Second, the contextual index resides in a wide-column store (Apache Cassandra [9]). Its partitioned key-value model matches the index’s access pattern. Selection needs a single lookup per dimension member followed by an intersection, without joins or scans. Its horizontal scalability accommodates the index’s growth. Third, an in-memory store (Redis [51]) holds constructed knowledge modules. It is the shared level of a two-level cache. In front of it, each Graph Service replica keeps a bounded inprocess cache, which spares a repeated request its network round trip, while the shared store lets every replica reuse a module another has constructed. Two safeguards bound

Page 13 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale Ingestion Gateway Client

Document Store

Contextual Index

Queue

Ingestion Worker

Content Analyzer

Upload document Upload document (e.g., AIXM, (e.g., AIXM, IWXXM) IWXXM) Select format Select format engine engine (by document (by document format) format)

Store document Store document Record document Record document details details Publish ingestion Publish ingestion task task (document reference, (document reference, chosen chosen engine) engine) Accepted (document Accepted (document reference) reference) Deliver ingestion Deliver ingestion task task Fetch document Fetch document Analyze content Analyze content Dimensional coordinates Dimensional coordinates (e.g., time, (e.g., time, location) location) Record hierarchies, Record hierarchies, contexts, contexts, document-context links document-context links

Figure 4: Sequence diagram of document ingestion and indexing

what a fault in the cache can cost. Each entry expires after a fixed time, so an entry that an invalidation announcement failed to evict cannot outlive that bound, and a request the shared store cannot serve falls back to construction from the documents. Clients never query these stores directly. The stores are reached only through the system’s services.

Ingestion. Two steps take a document through the ingestion pipeline (Figure 4). First, the gateway accepts an uploaded document, persists it unchanged to the object store, and publishes an ingestion task to the message queue. Acceptance is thus decoupled from indexing, and the client request returns immediately. Next, an ingestion worker consumes the task, retrieves the document, and passes it to the formatspecific content analyzer. The analyzer answers a single question: which contexts does this document discuss? The worker then records this response in the index, capturing the member hierarchies of each dimension, the contexts as hashed coordinates, and the links mapping each context back to its source documents. The pipeline produces no graph statements at this stage. The pipeline’s entire output is metadata.

Contextual index. Three tables carry the contextual index: hierarchies, contexts, and documents. Figure 5 traces an example document (aixm_01.xml) through those tables. Per dimension, the hierarchies table records the member chains that occur in the data. A member chain is a root-to-leaf path through the dimension’s hierarchy, e.g., the year 2018, the first month of year, and the first day of month in the

B. Ahmad et al.

time dimension, or the Austrian territory, the LOVV flight information region, and the LOWW aerdrome in the location dimension. The identifier of a member chain is its hash; the hash is the key of the hierarchies table. For each member chain, the hierarchies table stores the set of contexts where the chain occurs. The hierarchies table is partitioned by dimension, so resolving one dimension of a query scope costs a single partition lookup. The contexts table names the cells. A cell’s identifier is derived from the hash of its coordinates, the combination of one chain per dimension, so two documents that concern the same coordinates meet in the same cell without coordination among ingestion workers. The documents table links each cell to the stored documents behind it, together with the format engine that lifts them. The documents table is partitioned by cell, so collecting a cell’s documents is again a single lookup. These three lookups— of member, cell, and documents—are the entire read path of selection. The index resolves a scope without a join or a scan. Context assignment is computed at the granularity of individual data items, since a single document can span multiple contexts, but the index records are linked at the granularity of documents. This asymmetry shapes both the index and the construction path. Consequently, the index grows with the number of documents—context links rather than with the volume of document content—and remains a small fraction of the size of the corpus (Section 6). This space efficiency comes at a read-time cost. The construction path must parse every document that is loaded a second time, to recover the document’s data items. The trade-off is Page 14 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale Hierarchies

Document (e.g., AIXM) <AIXMBasicMessage>

schema_id

dimension

hierarchy_hash

members

<AirportHeliport> <designator>LOWW

Analyze content

<timeSlice>

context_ids

… atm

time

80224

{year: 2018, month: 01, day: 01}

{55464}

atm

location

77469

{territory: Austria, fir: LOVV, location: LOWW}

{55464}

atm

topic

49768

{category: AirportHeliport, family: …, feature: …}

{55464}

2018-01-01T00:00:00Z ...

Resolve contexts

Upsert hierarchy rows

Contexts schema_id

context_id

hierarchy_map …

Upsert context row atm

55464

{time: 80224, location: 77469, topic: 49768}

Data flow

Documents

Upsert document link Process flow schema_id

context_id

stored_name

engine_id

… atm

55464

aixm_01.xml

AIXM

Figure 5: Contextual indexing by example

nonetheless favorable. Content extraction runs lazily, only for the cells a query targets, while the index, the only structure that must span the entire corpus, stays compact.

Construction. A KG specification drives construction in two stages (Figure 6): planning by the Query Service and module construction by the Graph Service. The Query Service parses the specification into one coordinate per dimension and, optionally, a target roll-up level per dimension. The Query Service resolves the scope against the index in both directions: the cells at or beneath the requested coordinates, and the coarser cells covering them, whose knowledge propagates downward (Section 4.4). The Query Service then computes each cell’s final coordinates under the roll-up. A cell’s identity is the hash of its coordinates, so cells that roll up to the same coordinates collapse into one. The merge needs no bookkeeping beyond the hash. The service issues one construction request per source cell, which can be processed in parallel. For each source cell with a construction request, the Graph Service loads the cell’s documents, runs the format’s semantic lifter, and streams the resulting statements back, tagged with the cell’s final context. Repeated requests are answered from the cache. Lifting depends only on the document, which the query never reaches, so construction is deterministic, and the cache can only save time, never change a result. The streamed statements pass through a duplicate filter, keyed by a hash of each statement’s content, which makes the answer a set, independent of the order in which cells complete. A specification selects one of three output models, produced by interchangeable graph builders behind a single lifting step. RDF quads [24] feed triple stores such as Fuseki [11]. A labeled property graph feeds graph databases such as Neo4j [47]. A GraphFrame [26] serialization feeds Spark for distributed processing.

B. Ahmad et al.

Format engines. All format knowledge lives in engines, one per source format, each contributing exactly two functions: a content analyzer used at write time and a semantic lifter used at read time (Figure 7). The proof of concept comes with three engines: for AIXM [31], IWXXM [68], and FIXM [32]. No service has the engines hard-wired in the source code; the engines are discovered at run time. Supporting a further format is the work of writing an analyzer and a lifter for the format. Consequently, moving to another domain is a change of configuration, plus engines for its formats where none exist. No assumptions from the aeronautical domain are compiled into the services or the stores. The cube schema, with its dimensions, levels, and member hierarchies, is declared as configuration and registered by a client (Section 4.5), so the aeronautical character of the proof of concept rests on that declaration and on its three engines alone. The system’s understanding of a format is therefore applied when a document is read, not when the document is stored, which is the schema-on-read nature of the lakehouse [14].

Reasoning. Ontological reasoning is optional and isolated in the Inference Service. When a KG specification explicitly requests reasoning, the constructed module of each cell is passed to a rule engine (Apache Jena [12]), together with the terminological knowledge, to infer additional statements. These derived statements are returned in a separate module, so they never mix with the asserted facts. The terminology of the proof of concept is deliberately modest, a subclass hierarchy derived from the levels of the cube schema, and the reasoner is a standard RDFS or OWL profile. Because the service receives a constructed module and returns derived statements, a richer ontology or a more capable reasoner can take their place without changing the construction path. Factoring reasoning out of the construction path keeps that path free of reasoning’s overhead and allows this computationally demanding step to scale independently. Page 15 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale Query Gateway

Contextual Operations

Contextual Index

Graph Constructor

Cache

Document Store

Inference (optional)

Client

KG specification: KG specification: SELECT ... SELECT ... [ROLLUP [ROLLUP ON ON ...] ...] Forward KG Forward KG specification specification Parse coordinates Parse coordinates and rollup and rollup levels levels

Resolve cells Resolve cells beneath the beneath the scope scope Resolve cells Resolve cells covering the covering the scope scope Compute each Compute each cell's cell's final coordinate final coordinate

[per source [per source cell, cell, batched] batched]

loop

Build cell Build cell module module (statements (statements tagged with tagged with the the final final context) context)

Look up Look up built module built module [cache miss] [cache miss]

alt

Documents for Documents for context context Fetch documents Fetch documents Semantic lifting Semantic lifting (independent of (independent of the the query) query)

Store Store built module built module Statements, tagged Statements, tagged by by context context [reasoning requested] [reasoning requested]

opt

Infer knowledge Infer knowledge Inferred module Inferred module (kept (kept separate separate from asserted from asserted module) module) Add membership Add membership and and metadata metadata statements; deduplicate statements; deduplicate

KG-OLAP cube KG-OLAP cube KG-OLAP cube: KG-OLAP cube: N-Quads N-Quads // Property Graph Property Graph // GraphFrame GraphFrame Figure 6: Sequence diagram of on-demand knowledge graph construction

Observability. The implementation doubles as the instru-

Model and realization. Each construct of the formal

ment of the evaluation. Every stage publishes named measurements: scope-resolution time, per-cell construction time, merge time, cache hits and misses, output size. A request also carries an identifier across service boundaries, so a single query can be followed end to end. Section 6 reports exactly these measurements, read from the running system.

model has a concrete counterpart in the implementation. Table 2 pairs each construct from Section 3 and the architectural tiers with the realizing mechanism in the proof-ofconcept implementation.

B. Ahmad et al.

Page 16 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale Table 2 The formal model and its realization in the implementation Formal construct

Realization

Cube schema Ω Extraction 𝜙 and context assignment 𝜅 Cell name 𝖼𝗇(𝐝) Contextual index Idx Coverage ⪯ Retrieval 𝑅𝐷𝑐 Semantic lifting 𝜆 Local module 𝐾𝑐 Roll-up (merge) Reasoning over a module

declarative configuration of dimensions; member hierarchies recorded in index dedicated content analyzer per format called at write time hash of the dimensional coordinates hierarchies, contexts, and documents tables in the Index Store ancestry check over the member chains recorded in the index index lookup, then the data items are extracted again from each document dedicated semantic lifter per format called at read time statements produced for one cell in the requested representation coordinates coarsened before construction, so that equal cells merge optional Inference Service, returning a separate derived module per cell

at write time (for indexing)

«component» Ingestion Worker

«use» ContentAnalyzer

«component» Format Engine (e.g., AIXM)

at read time (for construction)

«component» Graph Constructor

«use» SemanticLifter

Figure 7: Component diagram of the format engine

6. Evaluation The evaluation asks whether the implemented artifact exhibits the properties the architecture was designed to deliver, under controlled and instrumented conditions. The evaluation comprises five experiments, E1–E5, each answering one question (Table 3), and stresses the system along the Three Vs of big data: volume, velocity, and variety [43]. This section reports the design and the principal results. The full protocols, per-axis tables, and figures, together with the deployment manifests, scripts, and measured data, are in the online repository [3].

6.1. Method and Datasets Correctness is established before performance is measured, and by independent means. Whether an operation returns the right result is decided by an oracle. The operands are loaded into a separate triple store, an Apache Jena TDB2 dataset served through Fuseki [11], and compared by the emptiness of their symmetric difference. The store plays no part in constructing the answers, so a fault in our own implementation cannot mask a mismatch. Performance is then measured on a distributed deployment of the system (the five services of Section 5 on a multi-node Kubernetes cluster), with every stage instrumented. The quantities reported below are read from the running system. All experiments draw on one deterministic synthetic dataset family, produced by the project’s data generator from a fixed, seeded aviation scenario [2], so every dataset is exactly reproducible and the correct context of every statement is known by construction. The datasets follow a one-factor-at-a-time design [46]. Each moves a single axis B. Ahmad et al.

off a fixed center (a country-scale geography, a thirty-day horizon, one thousand flights per simulated day, all three source formats, and all three dimensional hierarchies), holding the others fixed, so that an observed effect is attributable to one factor. The axes are geographic scope (one aerodrome to a continent), operational density (one hundred to ten thousand flights per day), and temporal horizon (one day to a year). The corpus spans roughly an order of magnitude in document count within one operational scenario. Variety is supplied by the three exchange standards of the use case (AIXM, IWXXM, and FIXM [31, 68, 32]), ingested and queried through the same plugin mechanism.

6.2. Results Together, the five experiments establish that on-demand construction returns the graphs the model prescribes, at a cost set by the scope of the query rather than the size of the corpus. Each experiment rests on the result before it. E1 shows that ingestion and indexing keep pace with arriving data, so that a query always reads a current index. E2 finds that the first stage of answering a query, resolving it to the contexts it names, costs according to the scope of the query rather than the size of the corpus, and that the index supporting it remains a small fraction of that corpus. E3 carries the same test to construction, which dominates the cost of a query, and finds construction unmoved by a growing corpus but responsive to a widening scope. E4 confirms that the graphs so constructed are correct at every hierarchy depth. E5 sets the two approaches side by side and measures what each costs to return the same knowledge modules, and what limits the scale of each.

E1: Ingestion and indexing. We examine whether the ingestion pipeline keeps pace with heterogeneous, highvelocity data at scale and how soon ingested documents become available to queries. The pipeline pays a constant per-document cost. As operational density rises a hundredfold, growing the corpus from 28 590 to 324 456 documents, the pipeline processes each document in an essentially constant 27–28 ms. Accumulating the three formats leaves that cost unchanged, so heterogeneity carries no per-document penalty. Throughput reflects the offered load rather than a Page 17 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale Table 3 The five experiments, the questions each answers, and the part of the system each evaluates Questions

Component evaluated

E1

– Does the ingestion pipeline keep pace with heterogeneous, highvelocity data at scale? – How soon are ingested documents available to queries?

Ingestion pipeline

E2

– Does the cost of context selection follow query scope rather than corpus size? – Is the index compact?

Contextual index

E3

– Does the cost of on-demand construction follow query scope rather than corpus size?

Construction path

E4

– Are the implemented contextual operations and graph transformations semantically correct over reconstructed graphs (at every hierarchy depth)?

Contextual operations and graph transformations

– What does each approach cost, in terms of run time and memory consumption, to return the knowledge modules for a queried context? – What limits the scale of each approach?

E5

4.12

Speed-up vs. one worker

4 3 2 1 0

2.00

ideal linear

1.00

1

2

Ingestion workers

4

Figure 8: E1, capacity axis: the indexing lag halves as the ingestion workers double.

Whole system vs. materialized baseline

index lookup that turns a declared scope into the set of matching contexts, before any graph is built. Constructing those contexts’ graphs is the subject of E3. The cost of resolving a query to its contexts follows the scope of the query, not the size of the corpus. As the matched context set widens from a single context to all 767, selection latency rises about fourfold, from 14.7 to 58 ms (Figure 9a), and for a fixed scope it does not rise at all as the document count grows elevenfold. The index is compact. It runs from 2.4 to 19.5 MB against a corpus of 263 MB to 1.81 GB, about one percent throughout (Figure 9b). Its structure (767 contexts) is invariant to volume. A query can therefore locate its slice quickly while the bulk of the data rests, untransformed, in low-cost storage.

E3: On-demand construction. We investigate whether ceiling, because the client drives ingestion at a fixed rate. Capacity is therefore read from the indexing lag, the interval from the acceptance of the last document of an offered batch until the whole batch is indexed and available to queries. The lag is the time the pipeline needs to drain its backlog, and it falls in proportion as workers are added: on the center corpus of 55 580 documents, from 1 607 seconds with one worker to 802 with two and 390 with four, a speed-up of 4.12 that is essentially linear (Figure 8). Notices carry a cost of their own, and it falls on the size of the index rather than on ingestion speed. A notice to airmen is valid over a span of days, about six on average, and the pipeline records one context for every day it covers, so 156 such documents expand to roughly 941 index entries.

E2: Contextual indexing. We measure the cost of context selection and the size of the index that supports it. Selection is only the first stage of answering a query, the B. Ahmad et al.

the cost of constructing a requested CKG follows the scope of the query or the size of the corpus, varying each in turn. At a fixed query scope, one region, construction builds the same graph (188 contexts, 56 474 quads) and takes essentially the same time (2 086, 1 993, and 2 016 ms; a largest-to-smallest ratio of 1.05) as the surrounding corpus grows from 28 590 to 324 456 documents (Figure 10). The identical quad count across corpus sizes shows the mechanism. The same scope resolves to the same contexts and does the same work, and the eleven-times larger corpus contributes nothing to the cost. Conversely, at a fixed corpus, construction grows with the requested scope, from 63 ms for a single-leaf query of 425 quads to 7.9 s for a territory-wide query of 227 039 quads (Figure 11). Cost depends on the scope of the query, not the size of the corpus. The marginal cost per context is steady. Beyond the smallest scope, construction takes 10– 11 ms per context (188 contexts in about 2 s; 767 contexts in 7.9 s) at a throughput near 28 000 quads per second on

Page 18 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

60 40

35

20

15

0

Location leaf (1 context)

Territory (767 contexts)

1.5 0.9%

1.0

4 000

0.9%

1 899

2 000 0

63

Location leaf

Region

Territory

Query scope

Figure 11: E3, selectivity axis: at a fixed corpus, construction latency (median of three repeats) grows with the requested scope. The whole-space query is omitted, since it resolves to the same 767 contexts as the territory scope and costs the same.

1.1%

0.5 0.0

28 590

55 580

Corpus size (documents)

324 456

Figure 9: E2: (a) selection latency (median of three repeats) rises about fourfold while the matched context set widens 767fold; (b) the index stays near one percent of the corpus as the document count grows elevenfold. The whole-space query duplicates the territory scope and is omitted.

2 500

Construction latency, median (ms)

6 000

(b)

2.0

Index size / corpus size (%)

Region (192 contexts)

7 873

8 000

58

Construction latency, median (ms)

Selection latency, median (ms)

(a)

2 000

2 086

1 993

2 016

Table 4 E4: All fourteen correctness checks pass against the independent oracle. A dash marks a property that cannot exist at that depth. Hierarchy depth Property

3

2

1

Slice containment Roll-up as union of covered cells Roll-up transitivity Dice commutativity Drill-down as inverse roll-up Covering delivery

✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ — ✓ ✓ ✓

✓ — — ✓ — ✓

1 500 1 000 500 0

28 590

55 580

Corpus size (documents)

324 456

Figure 10: E3, volume axis: at a fixed query scope, construction latency (median of three repeats) is flat as the document count grows elevenfold.

both axes, while the 63 ms single-leaf query reflects a fixed per-query floor.

property checks knowledge propagation. The knowledge of a context that covers cells inside the queried scope (coarser than the scope in one dimension and finer in another) must reach the answer. Because the corpus lies within one calendar month, constraining any slice by that month excludes nothing, so the constrained and unconstrained answers must coincide. A resolution that dropped such covering contexts would fail the equality. Fourteen checks apply across the three hierarchy depths (six at depth three, five at depth two, three at depth one), and all fourteen pass (Table 4). The number of applicable properties falls as the hierarchy flattens, exactly as the model requires: transitivity needs three levels, roll-up and drill-down two, while covering delivery applies at every depth. That is itself a check on the operations. The graphs that E3 builds cheaply are therefore also correct.

E4: Correctness of the KG-OLAP operations. We verify the contextual operations and graph transformations over reconstructed graphs, at every hierarchy depth. Correctness is checked through properties that must hold between two of the system’s own answers (slice containment, roll-up as the union of covered cells, roll-up transitivity, dice commutativity, drill-down as inverse roll-up, and covering delivery), each decided by the independent oracle on exact set comparison, with reasoning off, so that the checks isolate the operations themselves from inference. The covering-delivery B. Ahmad et al.

E5: On-demand construction versus monolithic materialization. We compare what the two approaches spend to serve the same task, returning the knowledge modules for a queried context. The baseline mirrors conventional practice: the corpus is mapped to RDF with a declarative mapping language (RML [27]), transformed into the full contextualized cube by a SPARQL query, and bulk-loaded into Apache Jena’s TDB2 store [12]. Both sides serve queries on identical commodity virtual machines. Table 5 states the comparison Page 19 of 25

Table 5 E5: the cost of first returning the knowledge modules for a queried context (256 aerodromes, 60 days). The materialized column includes the one-time cube build. Full tables in the appendix [3]. Materialized What is built?

On-demand

Peak memory Time

the whole cube (7.26 M quads) 46 GB ≈ 55 min

Grows with

the whole graph

Peak memory (GB)

50 40 30

materialized build on-demand construction

the queried context ≈ 1.4 GB tens of ms per context the queried scope

46 GB

104

3 272 s ( 55 min)

103 102

18 s

101 100

Materialized: rebuild the cube

On-demand: index the batch

Figure 13: E5: rebuilding the materialized cube against indexing on demand, measured as the time until queries can answer from a batch of 255 newly arrived documents (logarithmic scale)

33 GB to queries in about eighteen seconds, against the fifty-fiveminute rebuild the materialized cube requires to reflect the same change (Figure 13).

20 10 0

Time until new data can be queried (s, log scale)

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

1.4 GB

30 days, 256 aerodromes (4.50 M quads)

1.4 GB

Corpus

60 days, 256 aerodromes (7.26 M quads)

Figure 12: E5: the peak memory of the materialization build rises with the knowledge graph, while on-demand construction stays near 1.4 GB.

on the larger of E5’s two corpora, 256 aerodromes over sixty days. The thirty-day corpus supplies the scaling comparison below. To answer any query at all, the baseline first builds the whole cube of 7.26 million quads, peaking at 46 GB of memory over about fifty-five minutes. That peak exceeds the test machines, so the build was measured on a larger host. On-demand construction builds only the queried context, in tens of milliseconds per context and within about 1.4 GB. The costs differ in kind: one is a function of the whole knowledge graph, the other of the queried scope. Three consequences follow from the difference in kind between the two costs. The first consequence is feasibility. The memory of the whole-graph transformation rises with the graph, from 33 to 46 GB as the corpus doubles from thirty to sixty days (Figure 12), so the cube eventually cannot be built on any single machine, whereas on-demand construction has no whole-graph ceiling. The second consequence is wasted work. The materialized cube holds 40 511 contexts, of which a region-scoped query reads about four percent and an aerodrome-scoped query a single context. Materialization pays to build all of them. The third consequence is the lag before new data can be queried. Indexing makes a batch of 255 newly arrived documents available

B. Ahmad et al.

6.3. Discussion On-demand construction is a way to avoid maintaining a monolithic knowledge graph, not a more efficient way to build one. Some applications may genuinely require the entire graph to be materialized, including certain types of analytical questions, arbitrary cross-cutting queries, or a general-purpose SPARQL endpoint. For such applications, a materialized triple store remains the appropriate solution. Once the graph has been materialized, answering a query from it is a lookup, whereas on-demand construction must still build the requested modules. For that task the architecture offers no advantage. Instead, the proposed architecture’s contribution is orthogonal: The KG Lakehouse parallelizes scope-bounded construction, so that a query pays only for the knowledge modules of the contexts it names. Consequently, the architecture is intentionally optimized for on-demand construction rather than for materializing an entire KG. Materialization does not scale without bound. The hazards of maintaining a single, monolithic KG—namely the recognized cost of materializing an RDF graph, the need to arrange any partitioning before the data is loaded, and the maintenance risk of a store left effectively unmaintained— are laid out in Section 7. A materialized store is nonetheless simpler to operate than an on-demand pipeline. The advantage of on-demand construction increases as the corpus grows, its formats diversify, and its content changes, which are the conditions of the use case described in Section 2.

7. Related Work A KG integrates heterogeneous information with ontological knowledge, which makes them useful across information retrieval, question answering, social network analysis, deep learning, and analytics [72, 6]. The systems that manage them, however, are built around a standing graph, one that is assembled, loaded, and then queried. In the Page 20 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

following, we review related work on KG management systems, on cloud-native and lakehouse architectures, on graph storage and analytics, and on hybrid approaches, positioning the KG Lakehouse alongside each.

7.1. Knowledge Graph Management Systems A KGMS holds a graph and answers queries over it. Neo4j [47] does so for property graphs and Blazegraph [20] for RDF, offering traversal, pattern matching, and, in the RDF case, ontological inference. Where one machine no longer suffices, distributed engines such as Apache Spark GraphX [13] and managed services such as Amazon Neptune [7] spread the work over several nodes, combining partitioning with distributed query execution and, in places, inference [38]. These systems share one assumption. The graph exists before a query arrives, and the query reads what the store already holds. None of them derives a graph in response to the query that needs it, which is the capability the KG Lakehouse provides. A further limitation is one of scale. A materialized graph must be built and held in full before it can be queried, and the cost of that construction, in time, processor, and memory, is a recognized concern in its own right, with dedicated benchmarks now measuring it across construction tools [63]. Some stores do partition a graph across nodes [6, 69], but the division must be arranged before the data is loaded, and queries that cross partitions pay for the split. The Wikidata Query Service, the most prominent public knowledge graph deployment, ran on Blazegraph [20] as one unpartitioned graph of over sixteen billion statements. Reloading it from the data dumps takes one to two months, and it grows unstable near a size ceiling. In 2025 its operators divided it into separate endpoints, each queried on its own, to keep it operable [67], a difficulty compounded by Blazegraph itself having been effectively unmaintained since its developers were absorbed into Amazon Neptune [7]. Knowledge graph management systems remain well suited to serving a standing graph. They are not designed to avoid building the whole of it. The proposed KG Lakehouse avoids building the whole graph, not by materializing the monolith more efficiently (a task for which a purpose-built store remains appropriate) but by constructing only the contextualized subgraph a query requires.

7.2. Cloud-Native and Lakehouse Architectures Cloud-native design, with containers and independently deployable services, lets the parts of a system scale separately, and the lakehouse paradigm [14] keeps data in its native format until a query reads it (Section 1). Cloudnative design and the lakehouse paradigm combine naturally. Ingestion, indexing, and querying place different demands on a system, and each can be scaled on its own. The Databricks Lakehouse Platform [25] exemplifies this combination, integrating metadata management, caching, and indexing to support analytics across clouds, and Kona et al. [40] add semantic reasoning by combining Databricks with Stardog [59]. Both work over tabular data. The KG Lakehouse carries the lakehouse paradigm to heterogeneous B. Ahmad et al.

documents, from which it constructs contextualized KGs on demand.

7.3. Advancements in KG Storage and Analytics Two lines of work bring graphs closer to the data lake. GraphAr [44] defines a storage layout for labeled property graphs on Parquet files, so that neighbor retrieval and label filtering run directly over lake storage. Its concern is how a graph is laid out at rest, whereas the KG Lakehouse leaves the data unlifted until a query names the contexts it needs. Stream2Graph [17] builds graphs continuously from streaming data and updates them online. Both maintain a standing graph. Neither derives, per query, the contextual subgraph that an analytical task requires. Work on extraction is complementary rather than competing. Chen et al. [50] build knowledge graphs from unstructured text with deep active learning, which lowers the amount of labeled data required. A method of this kind could act as one more content analyzer in the ingestion pipeline, where extraction is a plug-in step. Several frameworks specifically address large-scale graph processing and analytics. Among the first was Graph OLAP [23], which associates graphs with dimensional attributes, yielding a cube whose cells contain graphs, and distinguishes informational roll-up, which overlays snapshots of a network, from topological roll-up, which merges nodes within one. Graph Cube [71] carries this view to warehousing multidimensional networks. In these frameworks, dimensional structure comes from the attributes of snapshots, nodes, and edges, the measures are aggregated graphs and numeric summaries over them, and the analyzed graph is presumed materialized. Contexts play no part. KGOLAP [52] instead attaches the dimensions to the knowledge itself, and the proposed method follows this route. KGOLAP, however, operates on a materialized cube, whose cells hold knowledge modules lifted and stored before any query arrives. The KG Lakehouse leaves the cube mapping unevaluated until a query names cells, so that roll-up aggregates the knowledge modules of contexts over graphs constructed on demand rather than held in a warehouse. P-OLAP [18] applies graph-OLAP principles to process execution data, scaling the computation with Hadoop and MapReduce [10]. Large-scale RDF processing has a stack of its own: SANSA [39] layers SPARQL evaluation, reasoning, and machine learning on Apache Spark, and Trinity [57] serves online and offline queries from distributed memory. Both operate on a dataset that has already been assembled and loaded, which is the step the KG Lakehouse defers to query time. SANSA and Trinity are nonetheless compatible with the KG Lakehouse. A constructed cube can be handed to either for downstream analysis, since the GraphFrame representation of Section 4.4 targets the same Spark ecosystem.

7.4. Hybrid and Domain-Specific Approaches A final group combines graph reasoning with big-data infrastructure. Wikibase [66] offers open-source infrastructure for managing pre-existing KGs but lacks support for generating task-specific contextualized KGs on demand. Federated SPARQL [28], linked data fragments [64], and Page 21 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

virtual KGs [70] also avoid holding one graph in one place, but they answer queries by delegating them to remote endpoints, to fragment servers, or to the relational sources behind a mapping. The KG Lakehouse instead builds the requested subgraph itself, from raw documents it has indexed by context, and so depends on neither pre-existing triple stores nor query federation. Gassauer-Fleissner et al. [33] pair a cloud-native platform with a graph database to detect financial crime, an example of the same pairing in a domain where the relevant subgraph is likewise a small part of the whole. Across these lines of work, the graph is stored, updated, or federated, but it is always there to be queried. The KG Lakehouse takes the opposite starting point. It keeps documents as they arrive, records the contexts in which their content is valid, and derives a knowledge graph only when a query names one. What that costs, and how it compares with building the graph in advance, is the subject of Section 6.

8. Conclusion This paper presented the Knowledge Graph Lakehouse, a cloud-native architecture that carries the lakehouse paradigm to the management of contextualized knowledge graphs. It is built for workloads whose scope is declared before any data is touched, for example a time window, a region, or a topic. For such workloads the system inverts the usual order of knowledge-graph management. Rather than materializing a standing graph and querying it, it stores raw documents as they arrive, indexes the contexts in which their content is valid, and constructs on demand exactly the contextualized knowledge graph a query names, never the whole of it. The architecture assigns the work to five tiers, grounded throughout in the KG-OLAP formalism. That grounding has practical consequences. Because a module is determined solely by the indexed raw data, construction is deterministic and merging commutes with construction. Caching therefore becomes a partial materialization of the cube mapping that can save time without changing a result. The architecture is realized as a proof of concept: five independently deployable services over an object store that keeps the raw documents, a wide-column store that holds the contextual index, a message queue that absorbs bursts of arriving documents, and an in-memory store the services share as a cache, all operated on a container platform. The realization keeps the domain out of the software. The cube schema, with its dimensions, levels, and member hierarchies, is declared as configuration, and every source format is served by its own content analyzer and semantic lifter, so the aeronautical character of the proof of concept rests on that declaration and those engines alone. The implementation is also the instrument of the evaluation, and it is openly available [4]. The evaluation supports the central proposition that construction cost depends on the scope of the query, not the size of the corpus. As the corpus grew from 28 590 to 324 456 documents, the ingestion pipeline processed each document at an essentially constant cost. At a fixed query B. Ahmad et al.

scope, construction returned the same graph in essentially the same time, with a largest-to-smallest ratio of 1.05 across an elevenfold corpus range. At a fixed corpus, cost rose with scope, from tens of milliseconds for a single-leaf query to seconds for a territory-wide query. A cube materialized in advance holds tens of thousands of contexts, of which a scoped query reads a few percent or less. That is work the KG Lakehouse never performs. Correctness was established independently of performance, by comparing reconstructed graphs against an independent oracle, a separate triple store, at every hierarchy depth. The KG Lakehouse suits workloads whose scope is declared in advance, where it builds no more of the graph than a query names. Arbitrary queries over a standing graph are better served by a materialized store. Several directions remain open. The lake is append-only. A correction arrives as a new document, and the assertions of both versions coexist in the affected modules. This is adequate for temporally versioned aeronautical data, where validity is part of the content. Retraction of a document, and of the knowledge lifted from it, remains future work. The formal treatment of the contextual operations is to be completed with the interplay of merging, propagation, and reasoning. Finally, the schema-on-read discipline leaves the system open to new data. Supporting a further source format, or another domain altogether, is the work of writing a content analyzer and a semantic lifter. Connecting the delivered representations to distributed knowledge-graph processing stacks is a natural continuation.

Acknowledgments This work was conducted as part of the AWARE project, which has received funding from the SESAR Joint Undertaking under grant agreement no. 101167442 within the European Union’s Horizon Europe research and innovation program. The views expressed in this work are those of the authors. Funded by the European Union

Declaration of generative AI and AI-assisted technologies in the manuscript preparation process During the preparation of this work the author(s) used Claude (Anthropic) and ChatGPT (OpenAI) in order to assist with language editing, grammar and spelling correction, and the rephrasing of selected passages to improve clarity and readability. All scientific ideas, methodology, experimental design, analysis, results, and conclusions were developed by the authors. The authors reviewed and edited all AI-assisted suggestions and take full responsibility for the content of this publication.

Page 22 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale

CRediT authorship contribution statement B. Ahmad: Conceptualization, Methodology, Formal analysis, Software, Investigation, Writing – original draft, Visualization. C. G. Schuetz: Conceptualization, Methodology, Supervision, Writing – review & editing. L. Bozzato: Formal analysis, Methodology, Writing – review & editing.

References [1] Ahmad, B., Schuetz, C.G., 2025. A cloud-native lakehouse architecture for using knowledge graphs in aeronautical information management, in: Proceedings of the SESAR Innovation Days (SIDs). doi:10.61009/SID.2025.1.39. [2] Ahmad, B., Schuetz, C.G., Bozzato, L., 2026a. ATM-GEN: a synthetic air traffic management data generator. Zenodo. doi:10.5281/ze nodo.21288733. version 1.0.0. [3] Ahmad, B., Schuetz, C.G., Bozzato, L., 2026b. Knowledge Graph Lakehouse — evaluation. Zenodo. doi:10.5281/zenodo.21395266. version 1.0.4. [4] Ahmad, B., Schuetz, C.G., Bozzato, L., 2026c. Knowledge Graph Lakehouse: a cloud-native data lakehouse for contextualised knowledge graphs. Zenodo. doi:10.5281/zenodo.21289343. version 1.0.4. [5] AISA Consortium, 2020. AISA: AI Situational Awareness Foundation for Advancing Automation. doi:10.3030/892618. funded by EU Horizon Europe / SESAR Joint Undertaking, grant no. 892618. [6] Ali, W., Saleem, M., Yao, B., Hogan, A., Ngomo, A.C.N., 2021. A survey of rdf stores & sparql engines for querying knowledge graphs. The VLDB Journal 31, 603–628. doi:10.1007/s00778-021-00711-3. [7] Amazon, 2025. Neptune. URL: https://aws.amazon.com/neptune/. accessed: 2025-05-13. [8] Angles, R., Thakkar, H., Tomaszuk, D., 2020. Mapping RDF databases to property graph databases. IEEE Access 8, 86091–86110. doi:10.1109/ACCESS.2020.2993117. [9] Apache Cassandra, 2023. Cassandra. https://cassandra.apache.org. Accessed: 2023-02-01. [10] Apache Hadop, 2025. Hadoop. https://hadoop.apache.org/. Accessed: 2025-12-01. [11] Apache Jena, 2024. Fuseki. URL: https://jena.apache.org/document ation/fuseki2/. accessed: 2024-12-16. [12] Apache Jena, 2026. Apache Jena. https://jena.apache.org. Accessed: 2026-07-31. [13] Apache Spark, 2025. GraphX. URL: https://spark.apache.org/gra phx/. accessed: 2025-05-13. [14] Armbrust, M., Zaharia, M., Ghodsi, A., Xin, R., 2021. Lakehouse: A new generation of open platforms that unify data warehousing and advanced analytics, in: 11th Conference on Innovative Data Systems Research, CIDR 2021. URL: http://cidrdb.org/cidr2021/papers/c idr2021_paper17.pdf. [15] AWARE Consortium, 2024. AWARE: Achieving Human–Machine Collaboration with Artificial Situational Awareness. doi:10.3030/10 1167442. funded by EU Horizon Europe / SESAR Joint Undertaking, grant no. 101167442. [16] Bardach, M., Gringinger, E., Schrefl, M., Schuetz, C.G., 2020. Predicting flight delay risk using a random forest classifier based on air traffic scenarios and environmental conditions, in: 2020 AIAA/IEEE 39th Digital Avionics Systems Conference (DASC). [17] Barry, M., Bifet, A., Chiky, R., El Jaouhari, S., Montiel, J., El Ouafi, A., Guerizec, E., 2022. Stream2graph: Dynamic knowledge graph for online learning applied in large-scale network, in: 2022 IEEE International Conference on Big Data (Big Data), pp. 2190–2197. doi:10.1109/BigData55660.2022.10020885. [18] Beheshti, A., Benatallah, B., Motahari Nezhad, H.R., 2015. Scalable graph-based olap analytics over process execution data. Distributed and Parallel Databases 34. doi:10.1007/s10619-014-7171-9. [19] Bellomarini, L., Gottlob, G., Pieris, A., Sallinger, E., 2017. Swift logic for big data and knowledge graphs, in: Sierra, C. (Ed.), Proceedings of the Twenty-Sixth International Joint Conference on Artificial

B. Ahmad et al.

Intelligence (IJCAI), pp. 2–10. doi:10.24963/IJCAI.2017/1. [20] Blazegraph, 2025. Blazegraph Database. URL: https://blazegraph .com/. accessed: 2025-05-13. [21] Bozzato, L., Eiter, T., Serafini, L., 2018. Enhancing context knowledge repositories with justifiable exceptions. Artif. Intell. 257, 72– 126. doi:10.1016/j.artint.2017.12.005. [22] Bozzato, L., Serafini, L., 2013. Materialization calculus for contexts in the semantic web. CEUR Workshop Proceedings 1014, 552–572. URL: https://ceur-ws.org/Vol-1014/paper_51.pdf. [23] Chen, C., Yan, X., Zhu, F., Han, J., Yu, P.S., 2009. Graph olap: a multi-dimensional framework for graph data analysis. Knowledge and Information Systems 21, 41–63. doi:10.1007/s10115-009-0228-9. [24] Cyganiak, R., Wood, D., Lanthaler, M., 2014. RDF 1.1 Concepts and Abstract Syntax. https://www.w3.org/TR/rdf11- concepts/. W3C Recommendation, 25 February 2014. [25] Databricks, 2023. The databricks lakehouse platform. URL: https: //www.databricks.com/product/data-lakehouse. accessed: 2023-0214. [26] Dave, A., Jindal, A., Li, L.E., Xin, R., Gonzalez, J., Zaharia, M., 2016. GraphFrames: An integrated API for mixing graph and relational queries, in: Proceedings of the Fourth International Workshop on Graph Data Management Experiences and Systems, ACM. doi:10 .1145/2960414.2960416. [27] Dimou, A., Vander Sande, M., Colpaert, P., Verborgh, R., Mannens, E., Van de Walle, R., 2014. RML: A generic language for integrated RDF mappings of heterogeneous data, in: Proceedings of the 7th Workshop on Linked Data on the Web (LDOW). URL: https: //ceur-ws.org/Vol-1184/ldow2014_paper_01.pdf. [28] Endris, K.M., Vidal, M.E., Graux, D., . Federated query processing, in: Janev, V., Graux, D., Jabeen, H., Sallinger, E. (Eds.), Knowledge Graphs and Big Data Processing. Springer International Publishing, pp. 73–86. doi:10.1007/978-3-030-53199-7_5. [29] EUROCONTROL, 2019. New traffic record set, 37,228 flights in one day. https://www.eurocontrol.int/news/new-traffic-record-set-372 28-flights-one-day. News item, 3 July 2019. Accessed: 2026-07-31. [30] EUROCONTROL, 2026. What is SWIM? https://reference.swim.a ero/what-is-swim.html. Accessed: 2026-07-31. [31] EUROCONTROL, Federal Aviation Administration (FAA), 2026a. Aeronautical Information Exchange Model (AIXM). https://www.ai xm.aero. Accessed: 2026-07-31. [32] EUROCONTROL, Federal Aviation Administration (FAA), 2026b. Flight Information Exchange Model. https://www.fixm.aero/. Accessed: 2026-07-31. [33] Gassauer-Fleissner, S., Shabat, Z.B., 2022. Financial Crime Discovery using Amazon EKS and Graph Databases. Technical Report. Amazon. URL: https://aws.amazon.com/blogs/architecture/fi nancial-crime-discovery-using-amazon-eks-and-graph-databases/. [34] Georgiou, H., Pelekis, N., Sideridis, S., Scarlatti, D., Theodoridis, Y., 2020. Semantic-aware aircraft trajectory prediction using flight plans. International Journal of Data Science and Analytics 9, 215– 228. doi:10.1007/s41060-019-00182-4. [35] Gómez-Pérez, J.M., Pan, J.Z., Vetere, G., Wu, H., 2017. Enterprise knowledge graph: An introduction, in: Pan, J.Z., Vetere, G., GómezPérez, J.M., Wu, H. (Eds.), Exploiting Linked Data and Knowledge Graphs in Large Organisations. Springer, pp. 1–14. doi:10.1007/97 8-3-319-45654-6_1. [36] gRPC, 2025. gRPC. https://grpc.io/. Accessed: 2025-12-01. [37] Harby, A.A., Zulkernine, F., 2022. From data warehouse to lakehouse: A comparative review, in: 2022 IEEE International Conference on Big Data, pp. 389–395. doi:10.1109/BigData55660.2022.10020719. [38] Hogan, A., Blomqvist, E., Cochez, M., D’amato, C., Melo, G.D., Gutierrez, C., Kirrane, S., Gayo, J.E.L., Navigli, R., Neumaier, S., Ngomo, A.C.N., Polleres, A., Rashid, S.M., Rula, A., Schmelzeisen, L., Sequeda, J., Staab, S., Zimmermann, A., 2021. Knowledge graphs. ACM Computing Surveys 54. doi:10.1145/3447772. [39] Janev, V., Graux, D., Jabeen, H., Sallinger, E., 2020. Knowledge Graphs and Big Data Processing. Springer. doi:10.1007/978- 3- 0 30-53199-7.

Page 23 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale [40] Kona, P., Wallace, A., 2022. Using a knowledge graph to power a semantic data layer for databricks. URL: https://www.databricks.com /blog/2022/06/17/using-a-knowledge-graph-to-power-a-semantic-d ata-layer-for-databricks.html. accessed: 2023-02-14.

[41] Krötzsch, M., Weikum, G., 2016. Web semantics: Science, services and agents on the world wide web. Journal of Web Semantics 37, 53–54. doi:10.1016/J.WEBSEM.2016.04.002. [42] Kubernetes, 2023. Kubernetes. https://kubernetes.io. Accessed: 2023-02-01. [43] Laney, D., 2001. 3D data management: Controlling data volume, velocity and variety. META Group Research Note 6. [44] Li, X., Zeng, W., Wang, Z., Zhu, D., Xu, J., Yu, W., Zhou, J., 2024. Graphar: An efficient storage scheme for graph data in data lakes. URL: https://arxiv.org/abs/2312.09577, doi:10.48550/arXiv.231 2.09577, arXiv:2312.09577. [45] MinIO, 2025. Minio – multi-cloud object storage. https://min.io/. Accessed: 2025-02-01. [46] Montgomery, D.C., 2019. Design and Analysis of Experiments. 10 ed., Wiley. [47] Neo4j, 2025. Neo4j. URL: https://neo4j.com/. accessed: 2025-0513. [48] Noy, N., Gao, Y., Jain, A., Narayanan, A., Patterson, A., Taylor, J., 2019. Industry-scale knowledge graphs: lessons and challenges. Communications of the ACM 62, 36–43. doi:10.1145/3331166. [49] Paulheim, H., 2017. Knowledge graph refinement: A survey of approaches and evaluation methods. Semantic Web 8, 489–508. doi:10.3233/SW-160218. [50] Pradhan, A., Todi, K.K., Selvarasu, A., Sanyal, A., 2020. Knowledge graph generation with deep active learning, in: 2020 International Joint Conference on Neural Networks (IJCNN), pp. 1–8. doi:10.1 109/IJCNN48605.2020.9207515. [51] Redis, 2025. Redis. https://redis.io/. Accessed: 2025-12-01. [52] Schuetz, C.G., Bozzato, L., Neumayr, B., Schrefl, M., Serafini, L., 2021. Knowledge graph OLAP. Semantic Web 12, 649–683. doi:10 .3233/SW-200419. [53] Schuetz, C.G., Neumayr, B., Schrefl, M., Gringinger, E., Vennesland, A., Wilson, S., 2018. The case for contextualized knowledge graphs in air traffic management, in: Capadisli, S., Cotton, F., GiménezGarcía, J.M., Haller, A., Kalampokis, E., Nguyen, V., Sheth, A.P., Troncy, R. (Eds.), Joint Proceedings of the International Workshops on Contextualized Knowledge Graphs, and Semantic Statistics colocated with 17th International Semantic Web Conference (ISWC 2018), CEUR-WS.org. URL: https://ceur- ws.org/Vol- 2317/arti cle-10.pdf. [54] Schuetz, C.G., Neumayr, B., Schrefl, M., Gringinger, E., Wilson, S., 2019. Semantics-based summarisation of atm information: Managing information overload in pilot briefings using semantic data containers. The Aeronautical Journal 123, 1639–1665. doi:10.1017/aer.2019.74. [55] Sequeda, J., Lassila, O., 2022. Designing and building enterprise knowledge graphs. Springer. doi:10.1007/978-3-031-01916-6. [56] Serafini, L., Homola, M., 2012. Contextualized knowledge repositories for the semantic web. Journal of Web Semantics 12-13, 64–87. doi:10.1016/j.websem.2011.12.003. reasoning with context in the Semantic Web. [57] Shao, B., Wang, H., Li, Y., 2013. Trinity: A distributed graph engine on a memory cloud, in: Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data, pp. 505–516. doi:10.1145/2463676.2467799. [58] Singh, A., Singh, V., Aggarwal, A., Aggarwal, S., 2022. Event driven architecture for message streaming data driven microservices systems residing in distributed version control system, in: 2022 International Conference on Innovations in Science and Technology for Sustainable Development (ICISTSD), pp. 308–312. doi:10.1109/ICISTSD55159.2 022.10010390. [59] Stardog, 2023. Stardog - the enterprise knowldge graph platform. URL: https://www.stardog.com/. accessed: 2023-02-14. [60] Steiner, D., Kovacic, I., Burgstaller, F., Schrefl, M., Friesacher, T., Gringinger, E., 2016. Semantic enrichment of DNOTAMs to reduce

B. Ahmad et al.

information overload in pilot briefings, in: 2016 Integrated Communications Navigation and Surveillance (ICNS), pp. 6B2–1–6B2–13. doi:10.1109/ICNSURV.2016.7486359. [61] The Apache Software Foundation, 2026. Apache kafka. https: //kafka.apache.org/. Accessed: 2026-07-15. [62] Vaisman, A.A., Zimányi, E., 2022. Data Warehouse Systems: Design and Implementation. 2 ed., Springer. doi:10.1007/978-3-662-65167-4. [63] Van Assche, D., Chaves-Fraga, D., Dimou, A., 2024. KROWN: A benchmark for RDF graph materialisation, in: The Semantic Web – ISWC 2024, Springer. pp. 20–39. doi:10.1007/978-3-031-77847-6_2. [64] Verborgh, R., Sande, M.V., Hartig, O., Meester, B.D., Vocht, L.D., Mannens, E., de Walle, R.V., 2014. Querying datasets on the web with high availability, in: Proceedings of the 13th International Semantic Web Conference (ISWC 2014), Springer. pp. 180–196. doi:10.1007/ 978-3-319-11964-9_12. [65] Vetter, C., Samardžić, K., Tukarić, I., Radišić, T., Häusler Hermann, R., 2024. Gaze analysis of air traffic contoller using AI-based conflict detection, in: 2024 AIAA DATC/IEEE 43rd Digital Avionics Systems Conference (DASC), pp. 1–10. doi:10.1109/DASC62030.2024.10749617. [66] Wikimedia Deutschland, 2024. Wikibase. https://wikiba.se/. Accessed: 15 March 2024. [67] Wikimedia Foundation, 2026. Wikidata Query Service: WDQS graph split. URL: https://www.wikidata.org/wiki/Wikidata:SPARQL_query_s ervice/WDQS_graph_split. accessed 2026; over 16 billion triples; full reload 1–2 months; graph split into two endpoints effective 9 May 2025. [68] World Meteorological Organization (WMO), 2023. Manual on Codes, Volume I.3 – International Codes Annex II to the WMO Technical Regulations, Part D – Representations derived from data models, WMO-No. 306. https://library.wmo.int/idurl/4/35769. [69] Wylot, M., Hauswirth, M., Cudré-Mauroux, P., Sakr, S., 2018. Rdf data storage and query processing schemes: A survey. ACM Computing Surveys (CSUR) 51, 1–36. doi:10.1145/3177850. [70] Xiao, G., Kontchakov, R., Calvanese, D., Compatangelo, E., Motik, B., 2019. Virtual knowledge graphs: An overview of systems and use cases. Data Intelligence 1, 201–223. doi:10.1162/dint\_a\_00012. [71] Zhao, P., Li, X., Xin, D., Han, J., 2011. Graph cube: on warehousing and olap multidimensional networks, in: Proceedings of the 2011 International Conference on Management of Data (SIGMOD). doi:10 .1145/1989323.1989413. [72] Zou, X., 2020. A survey on application of knowledge graph. Journal of Physics: Conference Series 1487, 012016. doi:10.1088/1742-6596/ 1487/1/012016.

Page 24 of 25

Knowledge Graph Lakehouse: Managing Enterprise Knowledge Graphs at Scale Bashar Ahmad is a researcher and lecturer at the Institute of Business Informatics – Data & Knowledge Engineering at Johannes Kepler University (JKU) Linz, Austria, where he is a doctoral candidate. He received his master’s degree in computer science and information engineering from National Chiao Tung University in Hsinchu, Taiwan, in 2004, and worked for more than seventeen years in industry as a software engineer and architect before joining JKU Linz. He is a member of the JKU team in the AWARE project on air traffic management, funded by the SESAR Joint Undertaking under Horizon Europe. His research interests include knowledge graph management, big data analytics, and applications of artificial intelligence.

Christoph G. Schuetz is associate professor at the Institute of Business Informatics – Data & Knowledge Engineering at Johannes Kepler University (JKU) Linz, Austria. He received his doctoral degree from JKU Linz in 2015. Since 2016, he has been serving as applicant and principal investigator on the JKU side in multiple international collaborative research projects on data management and decision support in air traffic management (ATM) in the Single European Sky ATM Research joint undertaking funded by EU’s Horizon frameworks. His research interests include data engineering and management, business analytics, and applications of artificial intelligence in various domains.

Loris Bozzato is a researcher at the Department of Theoretical and Applied Sciences (DiSTA) at the University of Insubria in Varese, Italy. He received his PhD in 2011 at University of Insubria and, from 2011 to 2024, was a researcher at Fondazione Bruno Kessler (FBK) in Trento, Italy. His research activity focuses on logic for artificial intelligence, with interest in knowledge representation and reasoning and semantic web technologies. He has coauthored more than 50 publications and is active in the KR and Semantic Web communities.

B. Ahmad et al.

Page 25 of 25

Related documents

• Horizontal Integration of Warfighter Intelligence Data: A Shared Semantic Resource for the Intelligence Community#768945
• Data Management and Sharing Plan for: DOGSLED: Data, Ontologies, and Graphs Supporting Learning and Enhanced Discovery#457935
• An infrastructure for the implementation of dynamic data warehouses#964187
• Knowledge management: a review of the field and of OR's contribution#290510
• Knowledge management in House of Graphs#998153