AutoG: Towards automatic graph construction from tabular data

8. I encourage the authors to use citations from published sources while in the current draft, several citations are from arXiv

Thanks for pointing this out. For papers that have a published proceeding version, we replaced their citations with the proceeding version.

9. Typos:

133: Treate 277: LLM generates / tends → LLMs generate / tend 282: single-steply

Thanks for pointing these out. We have revised all these problems.

10. In modelling the graph it seems that the nodes are just a set of types as . This definition does not seem standard for Heterogeneous graphs. There should be a set of nodes, each with a type (or a set of types) and a set of edges among the nodes.

Thanks for pointing this out. We have revised the definition accordingly (line 129).

Thanks for your time and efforts in reviewing.

1. The paper does not consider a rich database literature in mining functional dependencies [1,2] and data profiling [3] that automatically extracts dependencies among table columns. These methods can be used to generate more refined schemas that can solve some of the challenges expressed in Section 3.1. This method should be part of the experimental evaluation.

Thanks for the great suggestion. We have added the reference you mention in our revision.

In terms of evaluating these methods, it's true that they are very effective for those small-scale datasets like Movielens. However, when they are applied to larger datasets like Diginetica and AVS, it takes significantly long time to detect join discovery. That's because they detect join availability based on statistics and need to look at the whole column distribution. As a comparison, LLM-based methods build upon semantics and can detect based on few-shot samples and statistics.

Moreover, LLM and JTD (embedding-based) methods present both advantages:

• LLM-based methods are faster, and no need to set a threshold. However, its effectiveness drops with more tables and columns.
• JTD are effective despite the number of columns. However, threshold need to be set to distinguish joinable and non-joinable columns. In real industrial environment, first filtering possible pairs and then inputing into LLMs is a good practice.

[1] Madhavan, Jayant, Philip A. Bernstein, and Erhard Rahm. "Generic schema matching with cupid." vldb. Vol. 1. No. 2001. 2001.

[2] Zhang, M., Hadjieleftheriou, M., Ooi, B. C., Procopiuc, C. M., & Srivastava, D. (2011, June). Automatic discovery of attributes in relational databases. In Proceedings of the 2011 ACM SIGMOD International Conference on Management of data (pp. 109-120).

2. After having mined uniqueness constraints and functional dependency, one can apply conventional data normalization to further remedy the problems highlighted in challenges C2, and C3. From this standpoint, it is not clear why a mine-and-normal step would not solve most of the issues.

Thanks for the great question. We acknowledge that normalization is a closely related concept that is somewhat overlooked in the paper. After investigation, we think challenge 3 can actually be converted to challenge 2 after normalization. However, we want to emphasize the difference between our augmentation goal and normalization in RDB:

The goal of graph construction from relational data to graph is to find what kind of relational information is beneficial to the downstream task (new challenges 1, 2, 3, and 4). For example, the objective of challenge 2 is to consider whether the relationship induced by this categorical value is beneficial. This decision needs to consider the semantic relationship between this column and the corresponding downstream tasks and thus cannot be solved by normalization. A student has a category like AI, computer network, system, etc. From the normalization perspective, there is no need to create an augmented table. But from the graph construction perspective, such a student-subject-student relationship is beneficial for predictive tasks. As a comparison, the objective of normalization is to minimize data redundancy and improve data integrity. Despite the overlap, data normalization cannot fully solve the graph construction task. As discussed in [1], we think the limitation of our method is more that it can handle only simple cases (like when the relation is clear in datasets like MAG, and we also don't consider the case of fuzzy join). Such graph construction is quite challenging and has a long way to go in reality.

[1] Gan, Quan, et al. "Graph Machine Learning Meets Multi-Table Relational Data." Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining. 2024.

3. The benchmark only contains fairly small datasets with, at most 8 tables, for example, PTE has 38 tables (https://relational-data.org/dataset/PTE). There are also several datasets here: https://relational-data.org/

Thanks for mentioning these datasets. [1] has done a preliminary study on these datasets, and it shows several pitfalls of adopting these datasets for evaluating Text to graph construction

1. Many of these datasets are too easy and simple baselines can get very high performance metrics (100% accuracy or 0 regression loss) that can not well evaluate the effect of different methods.
2. The majority of the data predates the era of big data, with only 15 real-world datasets containing more than 10,000 labeled instances.
3. Some relations are degenerate and simple outer join and recover all information in the output big table. As a result, graph machine learning doesn't bring clear gain, which makes them not proper for a benchmark evaluating different graph construction methods.

To extend our methods to cases for a large number of tables and columns (which may even surpass the context length of LLMs, as join discovery will be difficult), we consider a variant combining JTD and LLM. We will first use JTD to filter a small number of similar columns and then let LLMs determine the threshold for joinable columns.

[1] Wang, Minjie, et al. "4DBInfer: A 4D Benchmarking Toolbox for Graph-Centric Predictive Modeling on Relational DBs." Advances in Neural Information Processing Systems 37 (2025).

4. Another challenge, not specifically addressed by the current paper, is missing values and NULL values. Can the proposed method cope with those? If not, why?

There's missing value and NULL value in the benchmark, for example, in the IEEE-CIS dataset. We address NULL values in two ways:

1. If this column is used as a numerical column, we directly fill it using the mean value.
2. If this column is used to augment a graph structure relationship (categorical value), this row can be viewed as a special edge type.

In general, our framework can support other missing value-handling methods since these lines of research are orthogonal.

5. Clarity: The paper is, in many parts hard to follow. Here are some examples

Figure 2: It is not clear what flexible design is and what the prompt looks like at least two columns as FK and no PK: provide an example chain of augmentation: please state what it is validation set performance: explain

Thank you for bringing these issues to our attention. We will provide clarifications here and revise the original paper accordingly.

1. Flexible Design: The term "flexible design" refers to modules within our framework that allow for multiple implementations. For instance, in prompt instruction, we can opt for an open-task design (where LLMs can generate any augmentation) or a closed-task design (where LLMs generate augmentations based on predefined actions, leading to improved effectiveness). Examples of prompts, showcasing the following key factors, are provided in Appendix D:

   • Background of the task
   • Statistics of the dataset
   • Description of actions
   • In-context demonstrations

2. Example: Consider the "Cites" table in the MAG dataset. Columns in this table are foreign keys referencing the "paperID" column in the "Papers" table. This establishes the (edge) citation relationship between the two papers.

3. Terminology: We acknowledge that the current name may be confusing. It simply denotes the series of augmentations generated by LLMs. We will revise this terminology to "a series of augmentations" for clarity.

4. Problem Setting: In this paper, we assume that graph construction methods have access to labeled training data. We can then partition the training data to create a validation set, allowing us to estimate the performance of trained models on the unseen test set, which is the ultimate goal.

5. 488: How does the method ensure that the test data is not included in the pre-training of the LLM? Do you have access to the training data?

That's a good question. This is a problem for those work using LLMs to simulate the work of data scientists. To address this, in section 5.3.3, we employ a synthetic dataset that is not present in the LLM's training data. The LLM demonstrates effectiveness on this dataset, suggesting its generalizability to most application scenarios.

7. The paper relies on LLMs that are subject to changes. Does it mean that one has to adapt the method to a different LLM every time?

That's a great question. From the experimental results, we find that newly released LLMs and more capable LLMs will achieve stronger performance on this task (Table 5) so there is no need to adapt to LLM updates.

Thanks for your time and efforts in reviewing.

1/2. My main concern is with the "metrics used in the proposed benchmark for evaluating the conversion of tabular data into graphs (T2G)." As stated in line 216, the authors use the performance of fixed GML models (RGCN, RGAT) trained on the generated graphs for quantitative evaluation. However, as a benchmark for T2G, it should be independent of specific downstream GML methods. Thus, the evaluation is limited to these two models and lacks generalizability to all GML models. Until it is demonstrated that the conclusions from RGCN and RGAT apply to all GML models, both the benchmark and the experimental findings in this paper remain constrained. Can you prove that the conclusions from RGCN and RGAT apply to all GML models?

That's a great question. We think the conclusions shown in our paper can extend to any GML models conducting early fusion [1], which refers to typical message-passing or self-attention-based models like RGCN, RGAT, and graph transformers. As evidence, the performance disparity shown in [1] among different "early fusion" models is very small.

[1] Wang, Minjie, et al. "4DBInfer: A 4D Benchmarking Toolbox for Graph-Centric Predictive Modeling on Relational DBs." Advances in Neural Information Processing Systems 37 (2025).

3. Have you considered proposing a better metric to evaluate the constructed graph itself? Furthermore, if the constructed graph is closely tied to specific downstream tasks, does that suggest that T2G might be more suitable as a data augmentation module to be explored with specific GML models, rather than as a standalone benchmark?

That's a good suggestion. We attempt some related graph properties to reflect the generated graph properties, such as the homophily ratio. However, as discussed in Section 4, we find that these metrics cannot well reflect the final goal, which is the downstream task performance. In this sense, we follow the philosohpy of [2], and adopt model as anchors to reflect the quality of constructed graphs.

We acknowledge that the constructed graph is tied to downstream tasks, and we think it's an important property of this benchmark. Unlike [1] which adopts the same graph for each downstream task, we find that adaptive graph construction is critical to good downstream task performance. As a result, we design our benchmark to be a data-centric benchmark and the core is to test different methods generating the data structure while different GML models are adopted as anchors to reflect the quality of graphs.

[1] Wang, Minjie, et al. "4DBInfer: A 4D Benchmarking Toolbox for Graph-Centric Predictive Modeling on Relational DBs." Advances in Neural Information Processing Systems 37 (2025).

[2] You, Jiaxuan, Zhitao Ying, and Jure Leskovec. "Design space for graph neural networks." Advances in Neural Information Processing Systems 33 (2020): 17009-17021.

Thank you for the feedback. First, we use the relational version of graph transformer (HGT) and PNA (R-PNA), and GNNs designed for homogeneous graphs perform consistently worse than those models designed for heterogeneous graphs [1]. The 12 GNNs in [2] are actually unified model architectures with varying hyperparameter settings designed to evaluate task similarity for homogeneous graphs. In contrast, our goal is to assess graph quality for heterogeneous graphs. To achieve this, we also perform a hyperparameter search to identify the best configuration, which should effectively reflect the quality of the graph.

[1] Lv, Qingsong, et al. "Are we really making much progress? revisiting, benchmarking and refining heterogeneous graph neural networks." Proceedings of the 27th ACM SIGKDD conference on knowledge discovery & data mining. 2021.

8. Much of the idea is clearly supported by argument, the choice of the oracle as a discriminator and the heuristics one gets out of that are rather arbitrary. It is not clear whether these are the best options. How do you know?

We appreciate your acknowledgment of the reasonableness of our design choices. Regarding the use of a GNN as an oracle, our primary goal is to assess the quality of the generated graphs. While oracles exist for generated molecular graphs, utilizing metrics like chemical properties [2], evaluating the quality of industrial graphs presents a more significant challenge. Therefore, we adopt the approach from [1], which employs a model as an anchor for quality determination. The underlying principle is that superior performance of the trained model on the visible validation set indicates a higher quality generated graph.

In the best-case scenario, given the vast search space of potential graph structures, definitively identifying the optimal graph is difficult. Consequently, to evaluate the effectiveness of our generated graph, we use the design from [3] as a benchmark. If our generated graph leads to improved performance on the downstream task, we consider it a successful design.

[1] You, Jiaxuan, Zhitao Ying, and Jure Leskovec. "Design space for graph neural networks." Advances in Neural Information Processing Systems 33 (2020): 17009-17021.

[2] Wang, Haorui, et al. "Efficient evolutionary search over chemical space with large language models." arXiv preprint arXiv:2406.16976 (2024).

[3] Wang, Minjie, et al. "4DBInfer: A 4D Benchmarking Toolbox for Graph-Centric Predictive Modeling on Relational DBs." Advances in Neural Information Processing Systems 37 (2025).

9.You only use RGCN and GAT, both of which are rather GNN based learning methods. Would you expect other methods to behave similarly? Why?

We expect other GML methods behave similarly. For example, [1] evaluates more GML models like graph transformer and PNA, and the conclusion is consistent for different GML models.

However, as shown in our experiment, there are some other possible model architectures like tabular models such as XGBoost and DeepFM, they can not enjoy the improvement brought by better graph design since they are graph-agnostic. For feature synthesis method like DFS, we also don't think the behavior will be similar, since they first conduct a feature synthesis based on relations, which is different from the parametric aggregation adopted in GNN-based and graph transformer-based models.

[1] Wang, Minjie, et al. "4DBInfer: A 4D Benchmarking Toolbox for Graph-Centric Predictive Modeling on Relational DBs." Advances in Neural Information Processing Systems 37 (2025).

Thanks for your time and efforts in reviewing.

1. It remains unclear how well this method performs on the long tail. The evaluation is averaging over many cases, but the results might be dwarfed by very common ones.

Thanks for the great question. The "long tail" node is usually defined as those nodes with lower degrees. We do a case study on the MAG dataset. We first split nodes into 5 bins according to their degrees.

We find that actually the boost brought by graph construction distributes across nodes with different degrees in a relatively uniform manner.

2. The paper only considers very well behaving rectangular tables (relational database style), with column names and all. Even the data types are given. There is also a lot of web tables around with large datasets available. One could certainly question whether te chosen setting is realistic, now.

Thanks for the great question. You make a good point that one property of LLM-based methods of automatic data engineering is the dependency of column semantics, which is also demonstrated in [1,2].

The current setting is inspired by [3], where we assume several tables are extracted from data lakes with missing or incomplete relations for downstream predictive tasks. One limitation of the selected dataset may be the limited size of columns and the focus on exact join instead of fuzzy join/semantic join. As a result, despite the simplicity of our setting, it reflects real industrial scenarios well.

[1] Hollmann, Noah, Samuel Müller, and Frank Hutter. "Large language models for automated data science: Introducing caafe for context-aware automated feature engineering." Advances in Neural Information Processing Systems 36 (2024).

[2] Han, Sungwon, et al. "Large Language Models Can Automatically Engineer Features for Few-Shot Tabular Learning." Forty-first International Conference on Machine Learning.

[3] Gan, Quan, et al. "Graph Machine Learning Meets Multi-Table Relational Data." Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining. 2024.

3. The datasets are pretty small.

The number of tables and columns in our datasets is relatively small, while the size of our dataset is not. One reason for this is the absence of datasets with a large number of tables and columns for the evaluation of GML models. As shown in [1], which conducts a preliminary study on datasets from https://relational-data.org/. The results show that either those datasets are too easy or do not present valuable structures for evaluating GML models. As a result, we mainly adopt datasets from [1].

Moreover, to extend the potential of our pipeline to large-scale datasets, we further demonstrate the following extension: we consider a variant combining LLM and JTD. For tables with many columns and tables, we first filter columns with high similarity and feed them to LLM. In this way, we can combine the advantages of the two methods with the cost of more computation overhead.

[1] Wang, Minjie, et al. "4DBInfer: A 4D Benchmarking Toolbox for Graph-Centric Predictive Modeling on Relational DBs." Advances in Neural Information Processing Systems 37 (2025).

4. Citations for relational graph learning are to 2023< papers, while this has been studies for 10+ years.

Thanks for pointing this out. We have followed [1, 2] and added a discussion in Appendix C.

[1] Zhou, Jie, et al. "Graph neural networks: A review of methods and applications." AI open 1 (2020): 57-81.

[2] Yang, Carl, et al. "Heterogeneous network representation learning: A unified framework with survey and benchmark." IEEE Transactions on Knowledge and Data Engineering 34.10 (2020): 4854-4873.

5. It is not clearly argued why relational graphs are most suitable. Other formalisms like hyper-relational ones might be more appropriate.

That's a great question! While hypergraphs have shown promise for representing single tabular datasets[1,2], the most effective way to apply graph-structured machine learning to complex, multi-tabular data remains an active area of research. For our work, we've chosen to utilize a message-passing GNN pipeline, the dominant approach in industry-level benchmarks [3,4], as it offers superior scalability and flexibility for capturing the intricate relationships within these datasets. This allows us to build upon an established foundation, ensuring comparability and reproducibility of our results.

[1] Chen, Pei, et al. "HYTREL: Hypergraph-enhanced tabular data representation learning." Advances in Neural Information Processing Systems 36 (2024).

[2] Du, Kounianhua, et al. "Learning enhanced representation for tabular data via neighborhood propagation." Advances in Neural Information Processing Systems 35 (2022): 16373-16384.

[3] Wang, Minjie, et al. "4DBInfer: A 4D Benchmarking Toolbox for Graph-Centric Predictive Modeling on Relational DBs." Advances in Neural Information Processing Systems 37 (2025).

[4] Robinson, Joshua, et al. "Relbench: A benchmark for deep learning on relational databases." arXiv preprint arXiv:2407.20060 (2024).

6. I suggest removing the claim of surpassing human experts. It is not clear whether all schemas from the experts are such that they were made as an ideal schema for a GNN architecture / the specific task.

You're right to point that out. We've removed the claim and appreciate you bringing it to our attention.

It's true that schemas designed by human experts might not be optimized for every specific task. For instance, on the MAG dataset, the expert-designed schema didn't perform well for year prediction. This highlights a key advantage of our LLM-based approach: it can automatically generate task-specific schemas, saving significant time and effort compared to manual design. This adaptability is crucial, especially when dealing with diverse tasks and datasets.

7. Recently, Alivanistos, et al. (2024) presented "The Effect of Knowledge Graph Schema on Classifying Future Research Suggestions". That work suggests that the classification performance depends on the chosen schema. Is this the same you observed in the current work? Should one consider existing schemas or let the model figure this creation out as well?

The work you mention is about the creation of a knowledge graph from text using some fixed schemas, and the result demonstrates that they greatly influence the final downstream task performance. Processing tabular data often involves a two-stage pipeline. The first stage focuses on transforming raw data into a structured format, while the second stage involves constructing graphs from this structured data to facilitate analysis. We think the work you mention is related to the first stage. While some research concentrates on the first stage [1], our work specifically addresses the second stage: constructing graphs from pre-structured data. While we haven't explicitly explored the schema influence to the same extent, we agree that schema design is critical. An ill-defined schema can lead to information loss and hinder effective analysis. For instance, existing schemas designed for scientific articles might not be suitable for more diverse data formats.

Regarding LLMs in the first stage, we've observed challenges with both code generation (LLMs generate pre-processing code, often resulting in non-executable code for complex cases) and direct structured output (LLMs directly output json output, limited to shorter inputs). While LLMs are powerful tools, human expertise remains crucial for reliable and comprehensive data structuring at this stage. As a result, we think a viable approach is to adopt LLMs together with manual post-processing.

[1] Wu, Haolun, et al. "Structured Entity Extraction Using Large Language Models." arXiv preprint arXiv:2402.04437 (2024).

Thank you for your answers. A couple of aspect remain worrisome to me.

Regarding W1: What does worry me a bit, is that you only look at venues in the graph, which I would expect to actually not have all that much variation. What do you obtain for other types? Overall, I think it would be useful to have some more extensive results on the long tail investigation in the paper. This is actually a nice finding as such.

Regarding W5: your response does not really deal with the missing aspect. Approaches being "dominant approach in industry-level benchmarks" does not mean anything. "superior scalability and flexibility for capturing the intricate relationships within these datasets" is just not true and "build upon an established foundation, ensuring comparability and reproducibility of our results" is a straw man fallacy.

W7: My understanding of that work is that it does both in one step. It creates a graph according to a schema. My point was not so much about comparing with that paper, but more about whether it makes sense to have multiple expert created schema and have the system find out which one is most beneficial.

Thanks for your time and efforts in reviewing.

1. W1: The problem definition is not explicitly stated.

We are willing to clarify the problem definition here.

• Input: A collection of tables with an unknown or incomplete relational structure [1]; a predictive task defined on the set of tables, along with some observable training labels.
• Output: A heterogeneous graph designed for this predictive task, which should help GML models achieve good task performance.
• Evaluation: Quality of the graph, and we adopt GML models' performance as anchors to reflect the graph quality.

[1] Gan, Quan, et al. "Graph Machine Learning Meets Multi-Table Relational Data." Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining. 2024.

2. 2. W2: Although the proposal utilizes carefully designed LLM prompts, it relies on standard techniques in LLMs like few-shot learning and chain of thought (CoT), making the novelty unclear.

Thank you for your feedback. We want to emphasize that our primary contribution lies in introducing a novel framework for converting tabular data into graph structures, enabling Large Language Models (LLMs) to perform complex analysis. While we utilize established prompting strategies like chain-of-thought, our focus is on how these techniques can be effectively applied within our framework to unlock the potential of LLMs for tabular data analysis.

Specifically, we observed that directly prompting LLMs for decisions without intermediate reasoning steps often led to the identification of only trivial relationships. By incorporating chain-of-thought prompting, LLMs will investigate the input data by explicitly stating it. We empower the LLMs to extract significantly more complex relationships derived from column statistics. Our work provides valuable insights into the effective application of chain-of-thought within this context, ultimately advancing the ability of LLMs to analyze and interpret tabular data.

3. W3: While the quantitative oracle evaluating GML with a validation set seems effective, Table 4 suggests the oracle may not be essential. The GML results are highly dependent on the choice of label selection (e.g., venue vs. year), making the conclusion "LLMs can generate good candidates merely based on prior knowledge" is not reasonable. We encourage the authors more detailed discussions here.

It's true that LLMs often generate effective schemas. However, they can sometimes introduce relationships detrimental to downstream tasks. For instance, when predicting publication years in the MAG dataset, LLMs might link papers based on relationships that introduce heterophily [1]. This can significantly hinder performance, as nodes with different labels become erroneously connected.

Our oracle mechanism acts as a safeguard against such scenarios, ensuring the generated schema is optimized for the specific task. This highlights the necessity of a robust pipeline that combines the generative power of LLMs with the refining capabilities of an oracle to address potential shortcomings and ensure optimal performance.

Moreover, you're correct that the original statement lacked precision. We've revised it in the updated version to more accurately reflect our findings.

Revised Statement (Line 459): "While we observe that LLMs can often generate effective candidate priors independently, incorporating an oracle remains necessary in certain cases to prevent bad cases. Developing a method to pre-determine the necessity of an oracle is a promising avenue for future research that could enhance the efficiency of our framework.

[1] Luan, Sitao, et al. "The heterophilic graph learning handbook: Benchmarks, models, theoretical analysis, applications and challenges." arXiv preprint arXiv:2407.09618 (2024).

4. W4: Concerning the five challenges in Section 3.1, if the schema is normalized, issues like C2 and C3 (1NF) seem unlikely to arise. Additionally, the proposal only addresses node classification and does not handle tasks like link prediction or node clustering, so C5 appears to be an overstatement.

That's a good question. After rethinking the five challenges, we find that C3 can be converted to C2 after normalization. However, we don't think the other challenges can be handled by normalization. The reason is that the decision made during the graph construction process is about how to model a column properly. For example, the objective of challenge 2 is to consider whether the relationship induced by this categorical value is beneficial. This decision needs to consider the semantic relationship between this column and the corresponding downstream tasks, which cannot be solved by normalization. (A student has a category like AI, computer network, system, etc. From the normalization perspective, there's no need to create an augmented table. However, from the graph construction perspective, such a student-subject-student relationship is beneficial for predictive tasks. As a result, the objective of normalization and graph construction is different)

For multi-task settings, we consider retrieval tasks like link prediction or recommendation in datasets like MAG and Diginetica. Node clustering is an unsupervised learning task, which may be valuable for future work beyond our benchmark.

5. W5: There is a lack of evaluation on speed improvements. Section 4.2 claims the high cost of JTD, and Section 4.3 mentions a design for potential speed-ups, making such an evaluation essential.

Thanks for pointing this out. The original statement in the paper is not correct. It's not fair to compare the running time of JTD and the whole pipeline since the goal is not totally the same (join discovery is just one target in the pipeline). Compared to JTD, LLM-based join discovery presents two advantages:

• No need to set the manual threshold
• No need to fine-tune the sentence-bert model

For fine-tuning, it takes 8 hours to train the fine-tuned JTD model on the webtable pairs with 8x A5000 GPUs. For a comparison of inference, we compare JTD with LLM on the join discovery task. In this setting, we remove all known key relationships between tables.

From the results, we can see that LLM is much faster in terms of join discovery. However, JTD is still important for real industrial data with a large number of tables and columns (which may go beyond LLM context length). As pointed out by other reviewers, we can actually combine LLM and JTD to deal with a large number of columns. We first filter columns with high similarity and feed them to LLM. In this way, we can combine the advantages of the two methods.

6. Is the problem defined as follows? The input: relational data, GML for downstream tasks, and records and class labels for training and validation data. output: transformed graph data from the relational data.

Exactly. It should be mentioned that we focus on multi-tabular data with unknown or incomplete relational structures.

7. The term "RGAT" may be incorrect and should be "GAT." The cited paper (Veličković et al., 2017) refers to GAT.

RGAT is an extension of the original GAT model for the heterogeneous graph, and we adopt the implementation from [1], we have updated the citation in the original paper.

8. Using GML models suited for homophilic graphs (e.g., RGCN, GAT) as an oracle may be unsuitable for tasks on heterophilic graphs. This issue could be addressed by selecting GML models tailored to heterophilic graphs as the oracle.

GCN and GAT are actually strong baselines for heterophilic graphs with proper hyperparameter settings [3]. In this paper, what we strengthen is the importance of not introducing heterophilous relations when constructing graphs. There exists no really effective model-centric solution for learning on heterophilic graphs which works consistently better than traditional GCN [2].

[1] Wang, Minjie, et al. "4DBInfer: A 4D Benchmarking Toolbox for Graph-Centric Predictive Modeling on Relational DBs." Advances in Neural Information Processing Systems 37 (2025).

[2] Luan, Sitao, et al. "The heterophilic graph learning handbook: Benchmarks, models, theoretical analysis, applications and challenges." arXiv preprint arXiv:2407.09618 (2024).

[3] Luo, Yuankai, Lei Shi, and Xiao-Ming Wu. "Classic GNNs are Strong Baselines: Reassessing GNNs for Node Classification." arXiv preprint arXiv:2406.08993 (2024).

Thanks for the acknowledgment. If there is anything else we can do to further improve your overall assessment of the paper, we will always be open to your suggestions. Please do let us know.