Pith. sign in

REVIEW 4 major objections 5 minor 35 references

An LLM can turn natural-language questions into perfectly accurate SPARQL queries when the domain ontology is designed to be readable and semantically annotated, hitting 100% on a 21-question expert-built test set in a neuroimaging archive.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 16:18 UTC pith:QWS2AFYG

load-bearing objection A genuinely useful ontology-first recipe with a clean SPARQL-vs-SQL comparison, but the headline 100% accuracy is development-set fit — the 21 questions co-evolved with the ontology and rider. the 4 major comments →

arxiv 2607.18029 v1 pith:QWS2AFYG submitted 2026-07-20 cs.DB cs.AI

Natural Language Access to Domain-Specific Metadata: A Reusable Framework for LLM Query Generation

Blake G. Fitch , Cato Elia Kurtz This is my paper
classification cs.DB cs.AI
keywords natural language querySPARQLSQLOWL ontologyzero-shot LLMmetadata searchknowledge graphneuroimaging metadata
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper claims that the bottleneck in natural-language access to domain metadata is not the LLM but the ontology: if domain vocabulary and semantics are captured in a well-designed OWL ontology with full English names and rich annotations, a locally deployed LLM can generate correct SPARQL queries zero-shot, without fine-tuning, retrieval, or multi-agent orchestration. On a 21-question competency set built with domain experts, the best configuration reaches 100% SPARQL accuracy, while an auto-generated SQL backend from the same ontology reaches only 57%. An ablation across eight ontology representations shows that readable entity names and semantic annotations are the dominant accuracy factors, more so than model choice or prompting. The demonstration domain is a large neuroimaging archive where privacy rules force local deployment on modest hardware, and a quantized 27B dense model achieves the same perfect accuracy as a full-precision model.

Core claim

The paper establishes that when an OWL ontology is deliberately engineered with full-word property names, consistent naming patterns, explicit domain/range, natural-language comments, labels, and synonyms, a local LLM can generate correct SPARQL for unseen natural-language questions with no training examples. The full Turtle ontology is placed in the system prompt; the LLM uses its names and annotations to map the question to graph patterns, inverse properties, and filters. The strongest measure is 100% accuracy on 21 competency/regression questions covering lookups, joins, filters, aggregations, and ontology introspection. The paper further shows that stripping comments and labels drops SPA

What carries the argument

The central mechanism is the OWL ontology itself, treated as a single source of truth and consumed directly by the LLM in its full Turtle form. Design principles (full English words, has-Property naming, explicit domain and range, rdfs:comment and skos:altLabel annotations, no opaque codes) make the schema self-describing. The ETL pipeline materializes implied triples so no reasoner is needed at query time, and a prompt rider encodes conventions that naming cannot express. The ablation across eight representations isolates exactly which parts of this machinery matter: names and annotations dominate, while prompt formulation and temperature have only minor effects.

Load-bearing premise

The load-bearing premise is that the 21 competency questions are representative of real user questions and were not effectively optimized into the ontology and prompt rider during the iterative development cycle; if novel end-user queries differ substantially, the 100% accuracy may not carry over.

What would settle it

Collect a fresh set of natural-language metadata questions from actual end users after the ontology, prompt rider, and competency set are frozen; run the same best model and full Turtle ontology on this held-out set with no further edits. If accuracy falls well below 100% (or below the regression-set level), the claimed zero-shot capability is an artifact of co-design rather than a property of the ontology representation alone.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Institutions with privacy constraints can deploy a local ~27B dense quantized model and achieve complete SPARQL query accuracy on curated questions, without outsourcing data to external APIs.
  • For new domain metadata projects, the paper implies that investing in ontology naming and annotation quality is more effective than investing in fine-tuning, retrieval infrastructure, or complex prompt engineering.
  • When a knowledge graph is available, SPARQL is likely a better target backend than auto-generated SQL for LLM-based natural-language access, because OWL's structural features transfer to the prompt more directly.
  • The co-evolution process (ontology, competency questions, and prompt rider iterating together) makes accuracy measurable and regression-free, providing a reusable development loop for other domains.
  • The result suggests that compact or abstract ontology representations, which fit smaller contexts, come at a substantial accuracy cost, so fitting the full annotated ontology in context should be the default when possible.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Because the 21 competency questions co-evolved with the ontology and rider, the 100% figure likely measures the tuning loop rather than true zero-shot generalization; a held-out set of questions frozen after development would be a stronger test and might score notably lower.
  • The large SPARQL-vs-SQL gap hints that relational schemas could be redesigned with ontology-like features—readable names, explicit join directions, and rich column comments—to narrow the gap; this is a testable design hypothesis the paper does not pursue.
  • The reported MoE underperformance is from one model family and one task; readers should not generalize to all mixture-of-experts architectures without broader evaluation.
  • For ontologies too large to fit the context window, the paper's token-dense compact representations lose ~30 points of accuracy, so future work will likely need hierarchical or summarized ontology encodings to scale the method.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents NLKGQ, a framework and development process for enabling natural-language access to domain-specific metadata by first capturing domain vocabulary in a well-designed OWL ontology, then using a local LLM to generate SPARQL (or SQL) queries zero-shot. The framework includes a web interface, a query harness, a combinatorial test driver, and an automatic OWL-to-SQL schema generator. The demonstration domain is a neuroimaging archive. The headline result is that the best configuration achieves 100% accuracy on a 21-question competency/regression set for SPARQL, with 57% for auto-generated SQL, and an ablation across eight ontology representations suggests that readable entity names and semantic annotations matter more than model choice or prompt engineering.

Significance. If the central claim is valid—that a small local LLM plus a carefully named and annotated OWL ontology suffices for accurate zero-shot NL-to-SPARQL on domain metadata—this is a genuinely useful engineering contribution. The paper provides a reusable infrastructure, a transparent OWL-to-SQL conversion, a combinatorial evaluation harness, and a practical demonstration on institutional hardware with privacy constraints. The authors also openly acknowledge the co-evolution of test cases with the ontology and the small test-set size. However, the reported 100% accuracy currently measures performance on a development set, not generalization to novel queries; the ablation is confounded by model choice across representations; and the 'zero-shot' label is weakened by the fix-retry protocol. These issues are load-bearing for the abstract's strongest claims, so the current evidence does not yet support the zero-shot generalization statement. The framework and process remain valuable as a reported system, but the evaluation needs to be substantially strengthened before the claims can be accepted.

major comments (4)
  1. [§3.3, §4.5, §6.4] The 100% accuracy figure is an in-sample measure. §3.3 states that test failures feed back into ontology renames, rider directives, and new test cases; §4.5 says 'Save Test Case' creates artifacts 'directly from a successful query.' Thus the 21 test questions co-evolved with the ontology and prompt, and the reported accuracy is a fit to the development set. The limitation statement in §6.4 concedes that 'accuracy on novel end-user queries may differ from test set performance,' but the abstract and §5.1 still frame the result as zero-shot. A held-out evaluation, with the ontology, rider, and question set frozen before collecting new questions from end users or domain experts, is required to support the headline claim. Without this, the central quantitative claim is not established.
  2. [§3.4, §4.5] The 'zero-shot' claim is further weakened by the fix-retry protocol. §3.4 admits that retrying failed queries is 'technically not zero-shot,' and §4.5 permits up to two correction attempts on syntax errors. The paper does not report how many of the 21 successes required retries, nor accuracy without retries. If, for example, only a small fraction of runs needed a second attempt, the deviation may be minor; but as reported, the reader cannot tell whether the 100% reflects the model's first-generation capability or error correction. Please report first-attempt accuracy and the distribution of retries per configuration.
  3. [§5.2, Table 4] The ablation across ontology representations is confounded by model selection. Table 4 reports the 'best configuration for each ontology representation,' but the winning model differs across rows: 'default' uses Q36.27B.D, while 'abstract-dict' uses Q36.35B.M and 'abstract-graph' uses Q36.35B.F. Since Table 3 shows large accuracy differences between models (e.g., 27B dense vs 35B MoE), the accuracy drop from 100% (default) to 19%/10% (abstracts) cannot be attributed solely to the representation. The claim that 'readable names and annotations are the dominant factor' requires holding the model fixed across representations, or at least reporting per-model results. Additionally, 21 questions is small; binning into percentages with no error bars overstates precision. Please provide a model-controlled ablation and, ideally, confidence intervals or per-question breakdowns.
  4. [§5.4, Table 7] The SPARQL-vs-SQL comparison is also affected by the same co-evolved test set and by selecting different best configurations for each backend (SPARQL uses 27B dense at 100%, SQL uses the Q8 model at 57%). While the direction of the gap is plausible and the per-query breakdown in Table 8 is informative, the comparison is not controlled for model, temperature, or prompt. The conclusion that OWL provides a structural advantage over SQL DDL is reasonable as a working hypothesis, but the current data cannot rule out that a different prompt or model would reduce the gap. The authors should temper the conclusion or provide additional runs with the same model on both backends.
minor comments (5)
  1. [§3] Typo: 'adevelopment process' should be 'a development process.'
  2. [General] The paper says '20+ competency questions' in §4.5 but Table 2 lists exactly 21. Please standardize the count.
  3. [§5.1] In the abstract and intro, 'the best model achieves 100%' might be misread as all models. Clarify that this is the best configuration among the 27B dense models, and that other models achieve lower accuracy.
  4. [Table 4] The 'Tokens' column is useful; consider also reporting the number of triples or classes in each representation to help readers interpret the effect of compactness.
  5. [§6.4] The limitation on context window is stated, but the implication for scaling to larger ontologies is only briefly discussed; a more precise bound (e.g., tokens per class/property) would help practitioners.

Circularity Check

2 steps flagged

Headline 100% zero-shot SPARQL accuracy is an in-sample product of the co-evolution loop; the test set is constructed from successful queries and the paper concedes novel-query accuracy may differ.

specific steps
  1. fitted input called prediction [§3.3 Iterative Development; §5.1 Table 3; §6.4 Limitations]
    "The ontology, competency questions, and domain-specific prompt rider co-evolve through testing. Running test cases against the system reveals gaps that feed back into all three: ... A new user question that the system handles poorly becomes a new competency test case. ... The result is a progressively refined system where the ontology captures the domain vocabulary, the test cases capture the query patterns, and the rider captures the conventions that naming alone cannot express."

    The 100% figure in §5.1 is measured on the same competency questions that drove the iterative loop: failed tests trigger ontology renames, rider directives, and new test cases, and the suite is re-run until accuracy is 'acceptable.' The reported accuracy therefore measures convergence of the development loop on its own development set, not zero-shot generalization to independently sampled user questions. §6.4 concedes exactly this: 'accuracy on novel end-user queries may differ from test set performance.' Presenting this in-sample score as the evidence for the abstract's zero-shot claim is fitting the artifacts to the benchmark and then reporting the benchmark as a result.

  2. self definitional [§4.5 Evaluation Protocol]
    "The web application's 'Save Test Case' function generates these artifacts directly from a successful query, enabling domain experts to create new test cases without manual JSON editing."

    Each test case is generated from a query that has already succeeded in the system, so its reference SPARQL and expected results are by construction reachable by the production path. The test set is thus a selection of system-confirmed successes, not an independent sample of end-user questions. The 100% pass rate across the best configurations is partly guaranteed by construction: the test cases were defined from outputs the system already produced.

full rationale

The paper's engineering contributions — ontology design principles, ETL pattern, OWL-to-SQL conversion, local deployment — are not circular; they are grounded in ablations and controlled comparisons. The circularity is confined to the central quantitative evidence: 100% zero-shot SPARQL accuracy. Section 3.3 states that ontology, competency questions, and prompt rider co-evolve, with test failures feeding renames, rider directives, and new test cases; §4.5 says test cases are saved 'directly from a successful query'; and §6.4 explicitly concedes that novel-query accuracy may differ. Thus the headline number is a measure of the design loop's convergence on its own development set, not of zero-shot generalization to novel phrasings. The fix-retry policy in §4.5/§3.4 additionally blurs the 'zero-shot' label, since up to two error-correction attempts are allowed. None of this invalidates the ablations or the SPARQL-vs-SQL comparison as engineering observations, but it does mean the strongest claim in the abstract is only weakly supported.

Axiom & Free-Parameter Ledger

5 free parameters · 6 axioms · 0 invented entities

Central claim rests on: the representativeness of the 21-question set, the fairness of the auto-generated SQL baseline, the negligibility of fix-retries, and the transferability of Qwen3/one-domain results. No numerical constants are fit, but design artifacts (ontology names/comments, rider directives, test-set composition, matching tolerances) are hand-tuned. No new theoretical entities are introduced.

free parameters (5)
  • Post-hoc best-configuration selection = e.g., SPARQL: Qwen3.6-27B, default ontology, baseline prompt, t=0.0
    Accuracy is reported per category as the maximum over 8 models × 8 representations × 3 prompts × 4 temperatures (768 configs), selecting the best model/prompt/temperature for each row. This inflates the reported accuracy and confounds the ablation (Tables 3–6).
  • Fix-retry attempts = up to 2 correction attempts per failed query
    All evaluations allow the harness to resend syntax errors to the LLM (§4.5), so the 'zero-shot' claim is not strictly true; best models rarely trigger it, but results include retries.
  • Result-match tolerance = column-name normalization, order-independent rows, URI-prefix stripping
    The SQL test driver uses tolerant comparison against SPARQL reference results (§4.1); the tolerance rules are hand-chosen and can turn partial matches into full matches.
  • Ontology/rider/test-set co-evolution loop = unbounded iterative edits (renames, new altLabels, rider directives, new test cases)
    §3.3: test failures feed back into ontology and rider; the same test cases then measure success. This is a hand-tuning loop analogous to fitting a model on the test set.
  • Temperature = 0.0–0.6, best selected
    Swept for each configuration; reported best rows often use different temperatures (Tables 3–6).
axioms (6)
  • domain assumption An LLM can generate correct SPARQL/SQL from a readable schema in context, without fine-tuning or RAG.
    This is the central empirical premise; the paper supports it with results, but it is assumed to hold for Qwen3 models at 8B–35B scale (§4.4, §5.1).
  • domain assumption The 21 competency questions, developed with domain experts, are representative of real end-user queries.
    The evaluation and all accuracy numbers depend on this. §6.4 concedes the set is small and co-evolved; no held-out novel-query evaluation is provided.
  • domain assumption The ETL pipeline can materialize all inferred relationships as concrete triples, so no OWL reasoner is needed at query time.
    §3.2 states this is 'sufficient for the OWL constructs we use'; if some queries rely on inferences not materialized, the 100% result would not transfer.
  • ad hoc to paper The auto-generated SQL schema (one table per class; object properties as FKs) is a fair and representative relational baseline.
    §4.3: The SQL comparison uses an automatically derived wide-table schema; a differently designed or hand-tuned relational schema could perform better or worse, so the 100% vs 57% gap is specific to this conversion.
  • ad hoc to paper Up to two fix-retries is a negligible deviation from zero-shot for the reported configurations.
    §4.5: The authors acknowledge retry is 'technically not zero-shot'. Since reported accuracy includes retried runs, the 'zero-shot' label depends on this assumption.
  • domain assumption Results generalize from Qwen3-family models to LLMs broadly and from neuroimaging metadata to other domains.
    §6.4 says all models are Qwen3 and only one domain was evaluated; cross-domain generalization is unvalidated.

pith-pipeline@v1.3.0-alltime-deepseek · 14079 in / 17110 out tokens · 232029 ms · 2026-08-01T16:18:47.635068+00:00 · methodology

0 comments
read the original abstract

Researchers need to answer ad-hoc questions about the contents of domain-specific archives but often lack the expertise to write structured queries on the metadata. We show that when domain vocabulary and semantics are captured in a well-designed Web Ontology Language (OWL) ontology, Large Language Models (LLMs) can generate accurate structured queries zero-shot, without fine-tuning, retrieval augmentation, or multi-agent orchestration. We present the Natural Language Knowledge Graph Query (NLKGQ) system, a framework and development process that enables natural language access to metadata in such archives. The framework includes a web interface that helps researchers pose natural language questions, which a domain-agnostic harness translates to SPARQL via an LLM and executes against a knowledge graph. The development process begins with capturing domain vocabulary and semantics in a formal OWL ontology. Domain-specific code then extracts metadata from archive sources and imports it into a knowledge graph defined by the ontology. Both are designed for reuse across domains. We demonstrate the system on metadata derived from a large-scale neuroimaging research archive, evaluating multiple LLMs and ontology representations. The best configurations achieve 100% accuracy on a competence and regression question set developed with domain experts. An ablation study across eight ontology representations reveals that readable entity names and semantic annotations are the dominant factors in accuracy, more significant than model choice or prompt engineering. We also compare SPARQL to an auto-generated SQL database as query backends, showing that OWL's structural features provide a substantial advantage over SQL DDL for LLM-driven query generation. Our demonstration domain also requires local LLMs on modest institutional hardware to address privacy concerns for human subject data.

Figures

Figures reproduced from arXiv: 2607.18029 by Blake G. Fitch, Cato Elia Kurtz.

Figure 1
Figure 1. Figure 1: MRI Research Ontology (MRO) class diagram. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The NLKGQ web interface. The user types a natural [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Framework architecture showing production components (solid) and research infrastructure (dashed). [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

35 extracted references · 2 canonical work pages

  1. [1]

    Debayan Banerjee, Sushil Awale, Ricardo Usbeck, and Chris Biemann

  2. [2]

    Catherine Brei, Annika Kraft, Marco Danner, Florian Vogel, and Jens Lehmann

  3. [3]

    Carroll, Ian Dickinson, Chris Dollin, Dave Reynolds, Andy Seaborne, and Kevin Wilkinson

    Jeremy J. Carroll, Ian Dickinson, Chris Dollin, Dave Reynolds, Andy Seaborne, and Kevin Wilkinson. 2004. Jena: Implementing the Semantic Web Recommenda- tions. InProceedings of the 13th International World Wide Web Conference (WWW). ACM, 74–83. doi:10.1145/1013367.1013381

    arXiv 2004

  4. [4]

    Peter Baile Chen, Fabian Wenz, Yi Zhang, Devin Yang, Justin Choi, Nesime Tatbul, Michael Cafarella, Çağatay Demiralp, and Michael Stonebraker. 2024. BEAVER: An Enterprise Benchmark for Text-to-SQL.arXiv preprint arXiv:2409.02038 (2024)

    Pith/arXiv arXiv 2024

  5. [5]

    Jacopo D’Abramo, Andrea Zugarini, and Paolo Torroni. 2025. Investigating Large Language Models for Text-to-SPARQL Generation. InProceedings of the 4th Inter- national Workshop on Knowledge-Augmented Methods for NLP (KnowledgeNLP). Association for Computational Linguistics, 66–80

    2025

  6. [6]

    Blake G. Fitch. 2022. MrData: An iRODS Based Human Research Data Manage- ment System. InProceedings of the iRODS User Group Meeting. Leuven, Belgium

    2022

  7. [7]

    Jeff Geerling. 2026. AI/LLM Benchmarks (llama.cpp and Ollama). https://github. com/geerlingguy/ai-benchmarks

    2026

  8. [8]

    Krzysztof J Gorgolewski et al. 2016. The brain imaging data structure, a format for organizing and describing outputs of neuroimaging experiments.Scientific Data3 (2016), 160044. doi:10.1038/sdata.2016.44

    doi:10.1038/sdata.2016.44 2016

  9. [9]

    Aidan Hogan, Eva Blomqvist, Michael Cochez, Claudia d’Amato, Gerard de Melo, Claudio Gutierrez, Sabrina Kirrane, Jose Emilio Labra Gayo, Roberto Navigli, Sebastian Neumaier, et al. 2021. Knowledge Graphs.Comput. Surveys54, 4 (2021), 1–37

    2021

  10. [10]

    Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E Gonzalez, Hao Zhang, and Ion Stoica. 2023. Efficient Memory Management for Large Language Model Serving with PagedAttention. InProceedings of SOSP

    2023

  11. [11]

    Xiangrui Li, Paul S Morgan, John Ashburner, Jolinda Smith, and Christopher Rorden. 2016. The first step for neuroimaging data analysis: DICOM to NIfTI conversion.Journal of Neuroscience Methods264 (2016), 47–56. doi:10.1016/j. jneumeth.2016.03.001

    doi:10.1016/j 2016

  12. [12]

    LLM Check. 2026. Apple Silicon LLM Benchmarks: Real tok/s by Model, Chip and Quantization. https://llmcheck.net/benchmarks

    2026

  13. [13]

    Karolina Mader and Maike Kleemeyer. 2023. Castellum: A Data Protection- Compliant Web Application for the Subject Management of Human Science Studies. InProceedings of the Conference on Research Data Infrastructure (CoRDI), Vol. 1. doi:10.52825/cordi.v1i.325

    work page doi:10.52825/cordi.v1i.325 2023

  14. [14]

    Max Planck Computing and Data Facility. 2025. Viper-GPU User Guide. https: //docs.mpcdf.mpg.de/doc/computing/viper-gpu-user-guide.html. 228 nodes, 2 × AMD Instinct MI300A APUs per node, 128 GB HBM3 per APU

    2025

  15. [15]

    Noy and Deborah L

    Natalya F. Noy and Deborah L. McGuinness. 2001.Ontology Development 101: A Guide to Creating Your First Ontology. Technical Report. Stanford University. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05

    2001

  16. [16]

    Nitarshan Rajkumar, Raymond Li, and Dzmitry Baber. 2022. Evaluating the Text- to-SQL Capabilities of Large Language Models.arXiv preprint arXiv:2204.00498 (2022)

    Pith/arXiv arXiv 2022

  17. [17]

    Rasheed and Marina Aguado

    Mohammed H. Rasheed and Marina Aguado. 2025. LLM-Based Natural Language to SPARQL Translation over Domain-Specific Knowledge Graph.Knowledge Organization52, 8 (2025). doi:10.31083/KO42705

    work page doi:10.31083/ko42705 2025

  18. [18]

    RDFLib Team. 2024. rdflib: A Python library for working with RDF. https: //github.com/RDFLib/rdflib

    2024

  19. [19]

    Md Rashad Al Hasan Rony, Uttam Kumar, Roman Teuber, Liubov Kovriguina, and Jens Lehmann. 2022. SGPT: A Generative Approach for SPARQL Query Generation From Natural Language Questions.IEEE Access10 (2022), 70712– 70723. doi:10.1109/ACCESS.2022.3188714

    arXiv 2022

  20. [20]

    Juan Sequeda, Dean Briggs, Nithish Mihindukulasooriya, and Oscar Corcho. 2023. A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model’s Accuracy for Question Answering on Enterprise SQL Databases.arXiv preprint arXiv:2311.07509(2023)

    Pith/arXiv arXiv 2023

  21. [21]

    Tommaso Soru, Edgard Marx, Diego Moussallem, Gustavo Publio, André Valdes- tilhas, Diego Esteves, and Ciro Baron Neto. 2017. SPARQL as a Foreign Language. InSEMANTiCS

    2017

  22. [22]

    Ricardo Usbeck, Ria Hari Gusmita, Axel-Cyrille Ngonga Ngomo, and Muhammad Saleem. 2018. 9th Challenge on Question Answering over Linked Data (QALD-9). InSemantic Web Challenges

    2018

  23. [23]

    Denny Vrandečić and Markus Krötzsch. 2014. Wikidata: A Free Collaborative Knowledgebase.Commun. ACM57, 10 (2014), 78–85. doi:10.1145/2629489

    doi:10.1145/2629489 2014

  24. [24]

    W3C. 2012. OWL 2 Web Ontology Language Primer. https://www.w3.org/TR/ owl2-primer/

    2012

  25. [25]

    W3C. 2013. SPARQL 1.1 Query Language. https://www.w3.org/TR/sparql11- query/

    2013

  26. [26]

    Sebastian Walter and Hannah Bast. 2026. GRASP: Generic Reasoning And SPARQL Generation across Knowledge Graphs. InProceedings of ECIR. Natural Language Access to Domain-Specific Metadata: A Reusable Framework for LLM Query Generation

    2026

  27. [27]

    Mark D Wilkinson et al. 2016. The FAIR Guiding Principles for scientific data management and stewardship.Scientific Data3 (2016), 160018

    2016

  28. [28]

    Niklas Wretblad, Fredrik Storås, Martin Ingebrigtsen, Halvor Björklund, Sushant Nayak, and Petter Lundberg. 2024. Synthetic SQL Column Descriptions and Their Impact on Text-to-SQL Performance.arXiv preprint arXiv:2408.04691(2024)

    Pith/arXiv arXiv 2024

  29. [29]

    Tao Yu, Rui Zhang, Kai Yang, Michihiro Yasunaga, Dongxu Wang, Zifan Li, James Ma, Irene Li, Qingning Yao, Shanelle Roman, et al. 2018. Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task. InProceedings of EMNLP

    2018

  30. [30]

    Zhiqiang Zhang, Liqiang Wen, and Wen Zhao. 2024. A GAIL Fine-Tuned LLM Enhanced Framework for Low-Resource Knowledge Graph Question Answering. InProceedings of the 33rd ACM International Conference on Information and Knowledge Management (CIKM). ACM, 3300–3309. doi:10.1145/3627673.3679753

    arXiv 2024

  31. [31]

    Chengshuai Zhao, Bowen Zheng, Haoming Zhang, et al . 2025. CyberBOT: Towards Reliable Cybersecurity Education via Ontology-Grounded Retrieval Augmented Generation. InProceedings of the 34th ACM International Conference on Information and Knowledge Management (CIKM). ACM

    2025

  32. [32]

    Yuxiang Zhao, Moritz Blum, Sander Witteveen, Peter Meltzer, and Sajan Koshy

  33. [2023]

    InProceedings of ISWC

    Spider4SPARQL: A Complex Benchmark for Evaluating Knowledge Graph Question Answering Systems. InProceedings of ISWC

  34. [2024]

    InProceedings of SEMANTiCS

    Generating SPARQL from Natural Language Using Chain-of-Thoughts Prompting. InProceedings of SEMANTiCS

  35. [2025]

    InProceedings of the 34th ACM Inter- national Conference on Information and Knowledge Management (CIKM)

    AGENTiGraph: A Multi-Agent Knowledge Graph Framework for Inter- active, Domain-Specific LLM Chatbots. InProceedings of the 34th ACM Inter- national Conference on Information and Knowledge Management (CIKM). ACM. doi:10.1145/3746252.3761459

    arXiv