LLM4VKG: Leveraging Large Language Models for Virtual Knowledge Graph Construction

1 Introduction

Data integration and access to legacy data sources using enduser-oriented languages are increasingly challenging. Among various integration approaches, Virtual Knowledge Graphs (VKGs) have gained significant traction, particularly when integrating data from relational databases (DBs) [Xiao et al., 2019]. VKGs replace the rigid structure of traditional tables with a flexible graph model that incorporates domain knowledge while ensuring real-time access to fresh, accurate information. Accessing the data through a VKG can significantly improve question answering accuracy on enterprise databases [Sequeda et al., 2023]. A VKG specification comprises three main components [Calvanese et al., 2023]: (a) data sources, storing the actual data; (b) a domain ontology, capturing the relevant concepts, relations, and constraints of the domain; (c) a set of mappings, linking the data sources to the domain ontology.

As a running example (see Figure 1), suppose that we are working with a database for supply chain management, including three interconnected tables, and aim to publish the data as a Knowledge Graph (KG) following the schema.org ontology. To achieve this, we first analyze whether the tables and columns in the database schema align with classes or properties defined in the ontology. The analysis reveals that tables Provider and Product can be matched to classes sc:Vendor and sc:Product. The table Provider-Product is matched to the object property sc:seller, and the columns Provider.Tag and Product.Desc are matched to the data property sc:name. Then, based on these alignments, we construct a set of mappings that define the transformation rules from the data source to a KG following the schema.org ontology. The developed VKG can be queried using the SPARQL language, and the triples can be materialized for further use.

Manually constructing mappings is a resource-intensive task that requires considerable human effort, time, domain expertise, and technical skills. Additionally, in real-world scenarios of VKG construction, the ontology is often incomplete and must be augmented based on the database schema and data. Recently, several works have been developed for automating or semi-automatic VKG mapping bootstrapping, such as IncMap [Pinkel et al., 2013], BootOX [Jim´enez-Ruiz et al., 2015] and ontop [Calvanese et al., 2017]. To evaluate the effect of VKG mapping bootstrapping approaches, Pinkel et al. [2018] introduced a benchmark, RODI, suggesting that those approaches can cope with relatively simple mapping challenges but perform poorly on advanced challenges related to real-world problems.

The emergence of large language models (LLMs) [OpenAI, 2024b; OpenAI, 2024a; Anthropic, 2024; DeepSeekAI, 2024] represents a promising avenue for addressing these challenges [Chen, 2024; Azaria et al., 2024]. LLMs, with their ability to process and generate contextually relevant text based on learned patterns in language, can assist in interpreting complex relationships between the ontology and the database schema, potentially improving the process of VKG construction.

In this paper, we propose LLM4VKG, a framework to leverage LLMs for VKG construction. The approach leverages LLMs to emulate human decision-making in tasks like attribute naming and concept matching and is guided by formally grounded mapping patterns [Calvanese et al., 2023] to build robust, practical ontology structures. These patterns distill best practices for mapping and ontology design. Moreover, to streamline the evaluation process, we develop a system, based on RODI [Pinkel et al., 2018], to create and evaluate the quality of the generated ontology and mappings.

Our experimental evaluation shows that LLM4VKG outperforms BootOX, the current SOTA method, across all scenarios with an average improvement of +17% in F1-score. Notably, in the "Conference - adjusted naming" scenario, LLM4VKG achieved an absolute improvement of +39%. Surprisingly, LLM4VKG closely matched the performance of the SOTA even with 25% of the ontology vocabulary removed, with an average F1-score of 0.46. These findings highlight the robustness and effectiveness of LLM4VKG in handling incomplete ontologies and complex mapping tasks.

In summary, (1) we propose LLM4VKG, the first framework for VKG construction leveraging LLMs and mapping patterns to complete ontologies and bootstrap mappings automatically; (2) in LLM4VKG, we design an alignment strategy that leverages the capabilities of LLMs for language understanding and uncertain decision-making to solve problems - attribute naming and concept matching - that are challenging for traditional rule-based methods; (3) we implement the proposed methodology and conduct experiments using variations of the RODI benchmark to validate the effectiveness of LLM4VKG. All code and datasets associated with this work are publicly available. 1

2 RelatedWork

2.1 Mapping Bootstrapping Systems

Over the past two decades, numerous methods have been developed to create mappings from databases. These methods vary by purpose (e.g., VKGs, data integration, ontology learning, DB schema validation via reasoning), the languages used (e.g., OWL profiles, RDFS, R2RML, or custom mapping languages), and the degree of automation [Calvanese et al., 2023; Mosca et al., 2023; Pinkel et al., 2018; Mogotlane and Dombeu, 2016; Sequeda and Miranker, 2015]. Here, we focus on actual implementations, specifically on the most relevant (semi-)automated tools for bootstrapping VKGs starting from a relational database.

1 https://github.com/HomuraT/LLM4VKG

Ontop [Calvanese et al., 2017] automates the generation of R2RML [Das et al., 2012] mappings, ensuring that the RDF graph largely conforms to the Direct Mapping recommendation (with minor exceptions, e.g., duplicate row handling [Calvanese et al., 2023]). Similarly, D2RQ [Bizer and Seaborne, 2004] employs reverse engineering to identify many-to-many relationships, translates foreign keys into object properties, and utilizes a custom mapping language.

MIRROR [de Medeiros et al., 2015] detects class hierarchies and many-to-many relationships, which are not directly expressible in relational schemas, enriching R2RML mappings. BootOX [Jim´enez-Ruiz et al., 2015] supports specifying OWL profiles, designing complex R2RML mappings with selection and join operators, recognizing class and property hierarchies, and aligning to target ontologies using LogMap [Jim´enez-Ruiz and Grau, 2011].

COMA++ [Aumueller et al., 2005] matches schemas in heterogeneous formats by unifying them into a common model and applying diverse matching techniques. IncMap [Pinkel et al., 2013] represents ontologies and schemas as graphs, computes ranked correspondence using lexical and structural similarities, and generates semi-automatic mappings with user approval. Karma [Gupta et al., 2012], a leading relational-to-ontology mapping tool, supports data extraction from various sources, cleaning, normalization, mapping to a target vocabulary, multi-source integration, and publishing in formats like RDF and CSV.

2.2 LLMs for Ontology Engineering

LLMs are transforming ontology engineering by enabling semantic-driven alignment and automated learning, significantly reducing manual curation while preserving domain fidelity across tasks.

Ontology Alignment Recent LLM-driven approaches demonstrate significant advances in ontology alignment. OLALA [Hertling and Paulheim, 2023] leverages opensource LLMs with zero-shot/few-shot prompting to achieve supervised-level performance on OAEI benchmarks using minimal training data. LLMs4OM [Giglou et al., 2024b] employs multi-representation prompting strategies for cross-domain ontology matching, outperforming traditional systems through context-aware retrieval modules. While OWL2Vec4OA [Teymurova et al., 2024] integrates LLMaugmented embeddings to refine structural alignment, all methods highlight LLMs' capability to reduce dependency on manual annotations and domain-specific constraints.

Ontology Learning LLM-based approaches are advancing ontology learning through diverse methodologies. LLMs4OL [Giglou et al., 2024a] demonstrates LLMs' partial efficacy in concept extraction tasks but highlights the necessity of fine-tuning for complex reasoning scenarios. Kommineni et al. [2024] establishes a semi-automated LLMRAG pipeline that reduces expert dependency in ontology construction while retaining human validation mechanisms. Specialized applications like Li et al. [2024] show LLMs' ability to generate educational ontologies from unstructured materials, enhancing downstream analytics through structured knowledge integration. For systematic learning, Lo et al. [2024] proposes an end-to-end LLM framework with adaptive regularization, outperforming subtask-based approaches in cross-domain ontology generation. These works collectively emphasize LLMs' role in balancing automation with domain-specific knowledge refinement.

3 Preliminaries

This section introduces the key concepts, definitions, and notations used in this work, including VKGs, mapping patterns, and the task definition.

3.1 Virtual Knowledge Graph

In this work, tuples are denoted by the bold font.

A VKG specification is a triple (T ,M,Σ), where T denotes an ontology (sometimes called TBox), M denotes a set of mappings, and Σ denotes a DB schema.

The schema Σ consists of a collection of table schemata in the form T(x1, . . . , xn), denoting a table T of attributes x1, . . . , xn, and a set of database constraints, in this work consisting of primary and foreign keys. With a slight abuse of notation, we write e ∈ Σ to indicate that e is a schema element, i.e., a table T or an attribute xi. We use notation Q(x) to denote a SQL query Q of answer attributes x. Given a database instance D of Σ, the evaluation Q(x)D of Q(x) over D is a set (ignoring duplicates) of answers (x ↦→ o) mapping attributes in x to values in D.

An ontology T is a set of axioms in some Description Logic (DL) language (usually DL-LiteR [Poggi et al., 2008], the mathematical underpinning of OWL 2 QL [Motik et al., 2012]). Axioms are expressed in terms of three pairwisedisjoint sets NC, NP, and ND denoting respectively class names, object property names, and data property names. Without loss of generality, we assume these three sets to contain only class and property names actually occurring in T .

A Knowledge Base (KB) is a pair (T ,A), where T is an ontology and A is a KG (sometimes called ABox). As custom in the DL literature, we assume A to be a set of unary and binary first-order atoms (intuitively, each atom corresponds to an RDF triple). In VKGs, A is not materialized, but provided indirectly by means of mappings.

A mapping m ∈ M is a pair of the form (s:Q(x), t:L) where the expression s:Q(x), called source, specifies a SQL query Q(x) over Σ and of answer attributes x, and expression t:L, called target, specifies a set L of first-order atoms. Atoms in L can be of the form C(t1(x1)), p(t1(x1), t2(x2)), or d(t1(x1), t2(x2)), where C ∈ NC, p ∈ NP, d ∈ ND, and t1(x1) and t2(x2) are first-order terms called templates.

For example, the following is a mapping using the (concrete) syntax of the Ontop VKG system [Calvanese et al., 2017] for C(t1(x1)). Q(x) is "SELECT ID FROM Provider", L(t(x)) is "data:vendor-{ID} a sc:Vendor", and x is (ID).

Example mapping 1: source SELECT ID FROM Provider

target data:vendor-{ID} a sc:Vendor .

Moreover, the following is another example for p(t1(x1), t2(x2)), where x1 and x2 are (ProviderID) and (ProductID) respectively.

Example mapping 2: source SELECT ProviderID, ProductID FROM Provider-Product target data:product-{ProductID} sc:seller data:vendor-{ProviderID}.

Given a set M and a database instance D, the virtual ABox MD exposed by D through M is the set:

where L[x ↦→ o] denotes the ground atom obtained after replacing attributes in x with their corresponding values in o. For instance, given an atom C(t(x1, x2)) and an answer ((x1, x2) ↦→ (o1, o2)), C(t(x1, x2))[(x1, x2) ↦→ (o1, o2)] denotes the ground atom C(t(o1, o2)).

Assuming the SQL query from Example 1 retrieves the solution mappings (ID ↦→ 1) and (ID ↦→ 2), the resulting RDF graph will be as follows:

data:vendor-1 a sc:Vendor . data:vendor-2 a sc:Vendor .

3.2 Mapping Patterns

Calvanese et al. [2023] analyzed many common scenarios of VKGs, and summarized the results as mapping patterns. These mapping patterns encapsulate a distilled set of best practices for creating mappings and designing ontology structures. We adopt four of the most common schema-driven patterns: (1) Schema Entity (SE), (2) Schema Relationship (SR), (3) Schema Relationship with Merging (SRm), and (4) Schema Hierarchy (SH). The schema components of these mapping patterns are illustrated in Figure 2.

For each schema structure in Figure 2, mapping patterns specify corresponding mapping and ontological axioms. For example, the mapping corresponding to SR is:

Example in Figure 1 can be seen as an instantiation of pattern SR, which is identical to Example mapping 2, where CE is sc:Vendor, CF is sc:Product, and pR is sc:seller.

3.3 Task Definition

The VKG construction task can be seen as a function, which takes a DB schema Σ and an initial ontology T0 as inputs, and produces a VKG specification P = (T ,M, Σ) with T0 ⊆ T , such that T captures the domain of interest, andMcorrectly establishes the relation between T and Σ. Typically, the quality of P needs to be assessed by either human experts or benchmarks, e.g., by verifying that queries answerable in the source database remain answerable in the VKG.

4 Methodology

In this work, we introduce LLM4VKG, an LLM-based framework designed to support VKG construction by automating tasks that typically require human judgment, such as concept matching and naming. Furthermore, we utilize several mapping patterns to refine and guide the VKG construction process, ensuring a well-structured output.

The overall framework of LLM4VKG is illustrated in Figure 3. The framework comprises two main steps: (1) Mapping Pattern Recognition, which extracts mapping pattern instances from the DB schema using SPARQL queries, and (2) Ontology Completion & Mapping Bootstrapping, which leverages LLMs and mapping pattern instances to complete the input ontology and generate mappings.

4.1 Mapping Pattern Recognition

To recognize the occurrences of mapping patterns in a given database schema Σ, we first convert Σ into a DB graph GΣ in a straightforward way and then, for each mapping pattern, we design a dedicated SPARQL query to match the corresponding graph pattern in GΣ.

Due to space constraints, we skip the details of the definition of GΣ, which is provided in Appendix A. Instead, for our running example in Figure 1, we visualize the DB graph in Figure 4. Then, we utilize SPARQL queries to encode the structures depicted in Figure 2. An example query for the SR pattern is:

SELECT DISTINCT ?T_E ?K_E ?K_RE ?T_R ?K_RF ?K_F ?T_F { ?T_E :hasPrimaryKeyColumn ?K_E . ?T_F :hasPrimaryKeyColumn ?K_F . ?T_R :hasPrimaryKeyColumn ?K_RE, ?K_RF . ?K_RE :foreignKeyReferences ?K_E . ?K_RF :foreignKeyReferences ?K_F . }

Note that this query deals with the case in which both TE and TF have primary keys of single columns, but can be easily generalized to keys with multiple columns. Finally, these SPARQL queries are executed on GΣ to derive the recognized mapping pattern instances.

4.2 LLMModules

In LLM4VKG, as depicted in Figure 3, the key component is "Element Level DB-to-Ontology Alignment", which attempts to match a given DB element to an ontology element. If no suitable match is found, it generates a new ontology element representing the DB element. It consists of three sequential modules 2 to leverage (possibly different) LLMs:

2 The detailed prompts for the modules are in Appendix B.

• Retriever takes an element of the schema (e.g., Provider for a table name, Provider.Tag for a column name) and a set of ontology elements Eon ⊆ NC∪NP∪ND as inputs. This module uses a pre-trained sentence similarity language model 3 MR to retrieve top-n candidate elements E′on , where n is a hyperparameter. The process is expressed as: E′on = RetrievernMR (edb, Eon).
• Similar to Retriever, Matcher takes a DB schema element edb and a set of ontology elements Eon as inputs. However, Matcher uses a generative language model 4 MM to generate a pair (d, em on ) where d is a label denoting the matching degree (with possible values High, Medium, or Low) and em on is an element fromEon matched to edb. When d is Low, emon is a null value, indicating that no element in Eon can be matched. The process is expressed as: (d, em on ) = MatcherMM(edb, Eon).
• Namer takes as inputs an element e1 ∈ Σ and optionally e2 ∈ Σ∪NC∪NP∪ND, and uses a generative language model MN to generate a class or property name according to the inputs. The generation uses the ontology as the context to make sure the names are meaningful. When only e1 is provided, Namer generates a fresh class or property name in the ontology based on the name of e1. If two elements are provided and e2 ∈ NC ∪ NP ∪ ND, Namer generates a fresh sub class or property of e2, and names it based on the name of e1; if e2 ∈ Σ, Namer generates a fresh object property and names it according to the pair (e1, e2). The process is expressed as: NamerMN(e1, e2).

Element Level DB-to-Ontology Alignment Given a DB schema element edb and a set of ontology elements Eon, we first try to match edb to Eon directly, using Retriever and Matcher: (d, em on ) = MatcherMM(edb, RetrievernMR (edb, Eon)). If d is High, em on will be the matched ontology element. Otherwise, Namer will be used to generate a new element (a class or property) of the ontology and name it based on edb:

In the last case, Namer generates a name as an object property based on the pair (e1db , e2db ), which will be used to deal with the mapping patterns SR (edb = TR) and SRm (edb = KEF ), and for both patterns e1db = TE, e2db = TF . For example, in Figure 1, edb is Provider-Product, e1db is Provider, and e2db is Product.

4.3 Ontology Completion &Mapping Bootstrapping

Now we present how to perform ontology completion and mapping bootstrapping using the above LLM modules over the mapping pattern instances. To avoid potential overlaps in mapping patterns, we process them in the specific sequence of SH, SR, SRm, and SE.

3 See sentence similarity models in this URL: https: //huggingface.co/models?pipeline tag=sentence-similarity

4 See generative models in this URL: https://huggingface.co/ models?pipeline tag=text-generation

SH This mapping pattern describes a hierarchical relationship between two classes. Following the pattern, TE and TF are matched to class names:

and a sub-class axiom CF ⊑ CE is added to the ontology. Note that no mappings are generated for this pattern.

SR This mapping pattern describes an object property from TE to TF, via TR. Following the pattern, TR is matched to an object property name:

and mappings are generated as follows:

where the name of the topmost ancestor of CE or CF is used as the template for tCE or tCF . For example, if CE is Student and its topmost ancestor is Person, KRE is sid, then tCE takes the form :Person/{sid}.

SRm This mapping pattern describes an object property from TE to TF, via KEF. Therefore, KEF is matched to an object property name:

If KEF consists of multiple columns, the names of these columns are concatenated using the word "and" (e.g., ID and Tag) to preserve their joint semantic significance. This unified string will serve as one DB schema element during the matching process. Mappings are generated as follows:

SE This mapping pattern specifies the correspondence between a table representing an entity 5 , characterized by a primary identifier and its attributes, and a class in the ontology with associated data properties.

If TE or an attribute a ∈ K ∪ A corresponds to an object property, the corresponding table and column are excluded from the process. Let AD denote the set of columns that do not match the object properties. Then, TE is matched to a class name, and each a ∈ AD is matched to a data property name:

Mappings are generated as follows:

5 Experimental Setups

Datasets We evaluate LLM4VKG on RODI [Pinkel et al., 2018] and RODI-T (x%), a variant of RODI in which x% of the ontology vocabulary is removed from the ontology starting from the leaf nodes. A RODI sample comprises three main elements: a database schema, a golden ontology, and a set of query pairs. Each query pair includes an SQL query and a SPARQL query, both of which are formulated to answer the same question. The output of the SQL query is treated as the label, whereas the output of the SPARQL query, based on the golden ontology, is regarded as the prediction. The domain and statistical details of the RODI dataset are presented in Table 1.

5 As in Entity-Relationship [Chen, 1976] diagrams.

Evaluation Process Some mapping generation systems produce mappings and an ontology based solely on the DB schema, leading to a vocabulary that differs from the golden ontology in RODI. To evaluate the quality of the VKG, ontology matching between the generated ontology and the RODI golden ontology is necessary. The evaluation includes the following steps: (1) Match the ontology generated by the VKG construction system to the golden ontology in the sample using LogMap [Jim´enez-Ruiz and Grau, 2011], and add the matching names (i.e., names only, without structure) from the golden ontology as equivalent classes or properties in the generated ontology. (2) Construct the VKG based on the database schema, the generated ontology, and mappings. (3) Compare the results of each query pair of the SQL query and the corresponding SPARQL query.

Metrics To measure the quality of generated mappings automatically, we follow Pinkel et al. [2018] and use the F1 metric computed by comparing the reference set (by SQL query) and test set (by SPARQL query). Let ref be the results from the SQL query, and res be the results from the SPARQL query, then the precision P = 1- |res\ref| |res| , the recall R = 1 - |ref\res| |ref| and F1 = 2×P×R P+R , where ref \ res denotes the elements in ref but not in res (and vice-versa).

Comparative Baselines We consider baselines from two categories: (1) Traditional mapping generation systems, including state-of-the-art systems like BootOX and IncMap, as well as those used in the RODI paper [Pinkel et al., 2018] (Tradition); and (2) direct application of LLMs for mapping generation, provided the ontology and database schema (Vanilla LLM).

• Tradition: (a) COMA [Aumueller et al., 2005], IncMap [Pinkel et al., 2013], and BootOX [Jim´enez-Ruiz et al., 2015] leverage both DB schema and Ontology. (b) D2RQ [Bizer and Seaborne, 2004], MIRROR [de Medeiros et al., 2015], and ontop [Calvanese et al., 2017] rely solely on DB schema.
• Vanilla LLM: o1 [OpenAI, 2024b], GPT-4o [OpenAI, 2024a], and DeepSeek-V3 [DeepSeek-AI, 2024]. Note that the generated mappings often contain errors that we fix through manual verification and correction (See Appendix C for details).

Implementation Details In this study, we leverage the VKG system Ontop [Calvanese et al., 2017] 6 to initialize the generated VKG based on a database connection, an ontology, and a set of mappings. For Retriever, we use bge-m3 [Chen et al., 2024] as the backbone model. For Matcher and Namer, we incorporate GPT-4o, GPT-4o-mini [OpenAI, 2024a], and Qwen2.5-7b [Qwen, 2024] as backbone models, representing various levels of performance across LLMs.

6 Results &Analysis

Results on RODI To evaluate the effectiveness of LLM4VKG, we conduct experiments using the scenarios of RODI, where the model takes the golden ontology as input, treats it as incomplete, and actively completes it. The results are summarized in Table 2 and Table 3.

6 https://ontop-vkg.org/

Table 2 reports that LLM4VKG outperforms traditional methods in all scenarios, achieving SOTA performance. The most significant improvement is observed in the scenario "Conference - adjusted naming", which achieves an absolute increase of +39%.

Furthermore, the results presented in Table 3 indicate that, modulo manual verification and correction, both o1 and DeepSeek-V3 achieve performance levels comparable to the SOTA mapping generation systems BootOX and IncMap. These findings highlight the potential of using LLMs directly to produce effective mappings.

Finally, LLM4VKG achieves substantial improvements over baseline methods, even when employing Qwen2.7-7b, a small-scale open-source LLM, as its backbone model. Specifically, compared to BootOX, LLM4VKG achieves improvements of +17%, +14%, and +8% in average F1 scores on GPT-4o, GPT-4o-mini, and Qwen2.5-7b, respectively.

Results on RODI-T(x%) Figure 5 shows that LLM4VKG achieves an average F1 score of 0.46 even with 25% of the vocabulary of the ontology removed, closely matching the performance of BootOX. This highlights the ability of LLM4VKG to infer naming rules and reconstruct missing ontology parts from existing elements. As more vocabulary is removed, performance declines partly because ontology alignment during evaluation may incorrectly flag correctly structured outputs if they don't precisely match the reference ontology. Consequently, the final performance also depends on the alignment method used. Nonetheless, LLM4VKG remains robust with partial vocabularies, demonstrating its effectiveness in handling incomplete ontologies.

Ablation Experiments To evaluate the contribution of individual components to the performance of LLM4VKG, we perform ablation experiments and present the results in Table 4: (1) -Matcher disables the Matcher component and directly selects the top-1 result from the Retriever as the matched key, assigning a matching degree of High as the matched output; (2) -SH, -SR, -SRm, and -SE indicate the removal of the corresponding mapping pattern handling processes during the mapping generation process. The results indicate that removing the Matcher component (-Matcher) decreases the average F1 score from 0.65 to 0.53. This reduction reflects that relying only on text similarity is insufficient for accurately mapping the database to the ontology, emphasizing the need for LLMs' reasoning capabilities. Similarly, eliminating the SE component (-SE) results in a significant drop to an average F1 score of 0.16, highlighting its essential role in the mapping process. Other components, such as SH, SR, and SRm, also contribute to performance, with their removal leading to moderate decreases in the average F1 score. These ablation results underscore the necessity of each component in maintaining the robustness and performance of LLM4VKG.

Fine-Grained Analysis for Query Types Table 5 presents the F1 score of LLM4VKG and baseline models across different query types. Overall, LLM4VKG consistently achieves a higher F1 score than BootOX across all query types, highlighting its effectiveness in managing diverse and intricate ontology queries. Among the three query types (C, D, O), object property queries (O) are the most challenging because multiple tables and columns are involved. LLM4VKG significantly outperforms BootOX, the best system, in this category (0.59 vs. 0.05), demonstrating its superior ability to handle better on relationships between different classes.

Additionally, while BootOX performs well on 1:1 mappings (0.82) but fails on n:1 mappings (0.00), LLM4VKG achieves 0.93 for 1:1 and 0.36 for n:1, showcasing its capability to manage more complex mappings.

RODI-T Error Analysis Figure 6 shows that as more vocabulary is removed in RODI-T(x%), the F1 score for classes (C), data properties (D), and object properties (O) decreases. The decline is smallest for classes, followed by data properties, with object properties experiencing the most significant drop. This is because classes and data properties involve fewer elements, making it easier to generate names that are similar to those in the golden ontology. In contrast, object properties are more complex, involving multiple tables and columns, which makes it harder to reproduce the exact properties in the golden ontology and leads to more errors.

7 Conclusion &FutureWork

In this work, we propose LLM4VKG, a framework that leverages LLMs for VKG construction. LLM4VKG automatically builds mappings and enriches the initial ontology based on mapping patterns extracted from the DB schema. Additionally, we developed an automated evaluation framework to simplify the assessment process. Our experiments demonstrate that LLM4VKG is robust and efficient in handling incomplete ontologies and complex mapping tasks. In future work, we aim to (1) expand the framework with additional mapping patterns; (2) in addition to the DB schema, utilize the statistics of the data in the DB to enhance ontology construction; and (3) develop a more comprehensive dataset based on RODI to further improve and validate our approach.

Acknowledgments

This work is partially supported by National Nature Science Foundation of China under No. 62476058, by HEU project CyclOps (GA n. 101135513), by the Province of Bolzano and FWF through project OnTeGra (DOI 10.55776/PIN8884924), by the Province of Bolzano and EU through projects ERDF-FESR 1078 CRIMA, and ERDFFESR 1047 AI-Lab, by MUR through PRIN project 2022XERWK9 S-PIC4CHU, and by the EU and MUR through PNRR project PE0000013-FAIR. We thank the Big Data Computing Center of Southeast University for providing the facility support on the numerical calculations in this paper. This work has been carried out while Marco Di Panfilo was enrolled in the Italian National Doctorate on Artificial Intelligence run by Sapienza University of Rome in collaboration with Free University of Bozen-Bolzano.

Contribution Statement

†Guohui Xiao and Lin Ren contribute equally to this work. ∗Corresponding author: guohui.xiao@seu.edu.cn.