AutoSchema: Live Schema Grounding for Agentic Text-to-Sparql over Heterogeneous Knowledge Graphs

AutoSchema: Live Schema Grounding for Agentic Text-to-Sparql over Heterogeneous Knowledge Graphs Yiming Zhang

Koji Tsuda

zhang_yiming_25@stu-cbms.k.u-tokyo.ac.jp The University of Tokyo Kashiwa, Chiba, Japan

tsuda@k.u-tokyo.ac.jp Center for Basic Research on Materials, National Institute for Materials Science Tsukuba, Ibaraki, Japan RIKEN Center for Advanced Intelligence Project Tokyo, Japan

arXiv:2608.14228v1 [cs.LG] 14 Aug 2026

Abstract Life science knowledge graphs make large collections of structured data available through SPARQL, but each resource uses its own schema, identifiers, and links. TogoMCP helps language model agents query these resources by providing curated Metadata Interoperability Exchange files. Creating and maintaining these files still requires language model assisted drafting, validation, and manual review. We study live schema grounding, where an agent obtains the schema evidence needed for a question directly from the current endpoints. We present autoschema, a general framework for live schema grounding that requires no training. It inspects live schemas, maps entity names in a question to graph identifiers, explores relation paths, and finds possible connections between resources during iterative query construction. We use TogoMCP as our main comparison framework. We evaluate autoschema on Resource Focused Biomedical KGQA, Multi Resource Biomedical KGQA, Longitudinal Biomedical Semantic QA over BioASQ Task B, and Chemistry Knowledge Graph Transfer to a previously undocumented RDF graph. autoschema improves mean factoid accuracy over TogoMCP in the biomedical KGQA tasks and gives consistent gains in the longitudinal BioASQ evaluation. It also reduces iteration budget exhaustion and uses fewer tool calls on average in the core evaluation. The transfer study gives preliminary evidence that live schema grounding can support irregular and previously unseen graphs without first creating a curated schema file.

1

Introduction

Life science knowledge is spread across specialized resources for genes, proteins, variants, pathways, diseases, and compounds. RDF gives these resources a common data model, and SPARQL supports precise queries over their structured content [4, 37]. The RDF Portal brings together many reviewed life science knowledge graphs and provides public SPARQL endpoints [20]. These resources support data integration and biomedical discovery [19]. However, a researcher still needs detailed technical knowledge to use them. Answering a natural language question requires choosing a resource, mapping entity names to database identifiers, selecting valid predicates, and following links between resources. Natural language interfaces can lower this barrier, but database specific schemas remain a central challenge [28, 36]. Language models offer a flexible way to translate questions into SPARQL. Without schema evidence, they can generate valid looking queries that use predicates or identifiers that are absent from the target graph [8, 29]. Existing methods reduce these errors by

training on paired questions and queries, retrieving examples, or adding schema descriptions to the model context [11, 13, 26, 27, 31]. These methods show that schema grounding helps, but they usually assume that useful schema material already exists. TogoMCP [22] is the closest starting point for our work. It gives an agent access to the RDF Portal through Model Context Protocol tools. It also provides a Metadata Interoperability Exchange (MIE) file for each supported resource. An MIE file contains schema descriptions, working SPARQL examples, common errors, and cross resource query patterns. TogoMCP shows that this context is a main source of its performance gain [22]. We therefore use TogoMCP as our main baseline, rather than treating MIE as a separate system. MIE creation is a mixed automatic and manual process. The reported TogoMCP workflow uses automatic schema discovery, language model assisted drafting, endpoint validation, and manual review. Its reported implementation uses hosted Claude models, although the MIE format itself is not tied to one model family [22]. This workflow creates two practical limits. First, private RDF data may not be allowed to leave local infrastructure through a hosted model API. Second, exploring an endpoint and drafting a long MIE file can require many paid model tokens. A curated file must also be checked and updated when its endpoint changes. These costs slow down the addition of new resources and can leave an existing file out of date. We ask whether an agent can build executable SPARQL by discovering the needed schema directly from live endpoints at question time. We call this problem live schema grounding. It covers source selection, entity resolution, relation and path selection, and links between resources. Solving this problem would let an agent use a new or updated graph without first creating an MIE file. It would also keep each query decision tied to current endpoint evidence. When the graph is private, the complete workflow could remain on local infrastructure. We introduce autoschema, a general framework for live schema grounding in tool using agents. It inspects observed classes and properties, maps entity names in a question to graph identifiers, explores local relation paths, and finds possible links between resources. The agent requests this evidence only when it is needed. It then writes a SPARQL query, executes it, and uses the result to guide the next step. Figure 1 shows this process. In our controlled evaluation, we compare autoschema with TogoMCP and with a no-schema lower bound. We run the agents with models that have

Yiming Zhang and Koji Tsuda

1

Input: Natural Language Question

3 Knowledge Graphs (Live Endpoints)

Heterogeneous KGs

Example

1 Source Summarization (Which database to query?)

Which drugs are approved for treatingBRCA1-mutated breast cancer?

2

AutoSchema: Live Schema Grounding Framework Classes (top)

Summarize observed classes, properties and statistics of a knowledge graph.

Properties (top)

drug

12K

drug_approved_for

8.1K

Gene Graph

disease

9.4K

gene_associated_with 6.7K

(e.g., NCBI Gene)

gene

15K

treats

3.2K

…

…

…

…

Classes: gene, organism, ... Properties:associated_with, ...

Agentic Text-to-SPARQL Loop

BRCA1

…/gene/672

0.98

0.93

Drug Graph

…

(e.g., DrugCentral) Classes: drug, compound, ...

Example (fromBRCA1→ drug) associated_with

Expand local neighborhood or search paths between entities; return predicates and path templates.

gene

disease

Final Answer + Supporting Evidence

drug

Pathway Graph (e.g., Reactome)

gene — has_variant → variant — associated_with → disease — treated_by → drug

Classes: pathway, event, ...

gene — participates_in → pathway — targeted_by → drug

Properties:has_participant, ...

4 Cross-Database Bridging Find ID-conversion routes, direct IRI reuse, or shared join keys.

Properties:treats, approved_for, ...

treated_by

Other paths:

…

Example

(How to connect graphs?) e. Reflect & Iterate Update plan until answer

Properties:has_phenotype, ...

…

3 Relation & Path Discovery

Grounding Evidence

Classes: disease, phenotype, ...

0.97

Tool Call

c. Generate SPARQL Construct candidate query

Schema Context Compared

Score

Find and rank entities that match the entity name and return breast cancer …/disease/MESH:D001943 approved drug …/class/Drug IRIs and labels.

(What predicates/paths?)

d. Execute & Observe Run on endpoint, get results / errors

(e.g., MONDO)

(Map entity names to graph IDs) Entity name Top Matched Entities (IRI)

a. Plan Decide next action (tool call or query)

b. CallAutoSchema Tools Get live schema evidence

Disease Graph

Example

2 Entity Resolution

LLM Agent

KG A

ID conversion / shared join key

(Gene Graph)

KG B

Cross-Database Bridges

(Drug Graph)

(IRI reuse • shared key • ID conversion)

gene (A) — bridge → gene (B) — treated_by → drug (B)

All tools query the live endpoint and return current evidence.

No Schema (Baseline)

Curated MIE (Static Schema)

AutoSchema (Live Grounding)

• Only model parametric knowledge

• LLM draft with manual review

• Discover schema from live endpoints

• Often hallucinates predicates/IRIs

• High curation & maintenance cost

• Always up-to-date

• May lag behind live endpoint

• Fewer tool calls, higher accuracy

Legend Agent / Request Flow

• Low execution success

MIE

Grounding Evidence SPARQL Execution Bridge / Join Relation

Figure 1: AutoSchema in an agentic text-to-SPARQL loop over heterogeneous knowledge graphs. Given a natural-language question, the agent alternates planning, live grounding, query generation, execution, and reflection. AutoSchema supplies four question-time capabilities: source summarization, entity resolution, relation and path discovery, and cross-database bridging. Each capability returns current endpoint evidence rather than a complete schema dump. The bottom panel contrasts AutoSchema with TogoMCP and a no-schema lower bound. open weights and are hosted on local infrastructure. Schema discovery and question answering therefore do not require a closed model API. Our evaluation has three levels. At the graph query level, Resource Focused Biomedical KGQA tests questions answered from one RDF resource, and Multi Resource Biomedical KGQA tests questions that combine evidence or identifiers from several resources. At the general biomedical question answering level, Longitudinal Biomedical Semantic QA uses factoid, list, and yes or no questions from yearly BioASQ Task B test sets [24]. These questions also test whether the agent can decide when graph access is useful. At the transfer level, Chemistry Knowledge Graph Transfer tests a previously undocumented tmQM RDF graph with an irregular schema [7]. Across models with open weights, autoschema improves mean factoid accuracy over TogoMCP in the biomedical KGQA tasks. It also gives consistent factoid gains in the longitudinal BioASQ evaluation, lowers the rate of iteration budget exhaustion, and uses

fewer tool calls on average in the core evaluation. The chemistry transfer result is preliminary, but it suggests that live grounding is useful when a new graph has an irregular schema. Our contributions are as follows:

• We formulate live schema grounding for agentic text-toSPARQL. The task grounds query decisions in current endpoint evidence instead of a prewritten schema file. • We develop autoschema, a general framework for live schema grounding. It provides reusable functions for source selection, entity resolution, relation path discovery, and cross-resource bridging. It does not require model training and can work with locally hosted models that have open weights. • We provide a controlled evaluation across biomedical graph queries, longitudinal Biomedical Semantic QA, and chemistry graph transfer. We also measure interaction cost and study the value of repeated schema access.

AutoSchema: Live Schema Grounding for Agentic Text-to-Sparql over Heterogeneous Knowledge Graphs

2 Related Work 2.1 Text-to-SPARQL and KGQA Evaluation Text-to-SPARQL maps a natural language question to an executable graph query. Surveys identify entity linking, relation selection, and compositional reasoning as core challenges [6, 25]. Benchmarks such as WebQuestionsSP, ComplexWebQuestions, LC-QuAD 2.0, CFQ, and KQA Pro test different forms of these challenges [5, 10, 21, 40, 43]. However, evaluation protocols are often hard to compare, and random splits can overestimate transfer to unseen relations and compositions [17, 33]. A system may also receive a question whose answer is absent from the target graph [12, 32]. We therefore measure executed answers on live endpoints and separate graph supported questions from open biomedical questions.

2.2

Schema Grounding and Agentic Querying

Recent KGQA systems retrieve graph context before or during query generation. RNG-KBQA ranks candidate queries, TIARA combines entity and schema retrieval, and ArcaneQA limits program actions using the current graph context [14, 35, 42]. KB-BINDER and ChatKBQA first generate a logical form and then bind it to the graph [26, 27]. SG-KBQA further shows that schema context helps with unseen graph elements [13]. These methods usually assume a known target graph. Our setting also requires the agent to select a source and discover its current entity and relation structure. Tool based systems make grounding iterative. StructGPT provides interfaces to structured data, Interactive-KBQA uses graph feedback, Think-on-Graph traverses explicit reasoning paths, and SAGA constrains predicate exploration with schema evidence [16, 39, 41, 44]. Agentic SPARQL also studies endpoint discovery and federated query formulation through MCP [9]. Our controlled comparison keeps the agent and execution tools fixed and changes only the source of grounding evidence. RDF summaries offer another source of grounding evidence. VoID describes datasets and their links, while SchemEX, LODStats, Loupe, and ABSTAT summarize graph structure for search or inspection [2, 3, 23, 30, 38]. Federated engines such as FedX and ANAPSID instead focus on source selection and query execution [1, 34]. Autoschema does not replace a federated query engine. It turns live, question specific observations into grounding evidence for an agent.

2.3

Biomedical Knowledge Access and Benchmark Construction

Biomedical Linked Data provides a demanding instance of this problem because resources use different schemas and identifiers. Bio2RDF introduced common linked data conventions, BioFed supports queries across life science endpoints, and Bio-SODA provides interactive question answering [4, 15, 36]. The RDF Portal provides reviewed datasets and public SPARQL endpoints [20]. RDF-config places expert schemas behind a fixed query builder [31]. TogoMCP instead gives LLM agents direct access to the endpoints and supplies a compact MIE file for each resource [22]. TogoMCP is our main baseline. Autoschema is an independent grounding framework that discovers this evidence from live endpoints instead of relying on a prewritten MIE file.

Our evaluation combines two kinds of questions. BioASQ provides realistic factoid, list, and yes or no questions, but it does not guarantee that every answer exists in a given graph [24]. Graphlet based generation instead ties each question to graph evidence [18]. We use this principle for Resource Focused and Multi Resource Biomedical KGQA, and use several years of BioASQ Task B for Longitudinal Biomedical Semantic QA. We also test transfer to the tmQM-RDF chemistry graph [7].

3 Method 3.1 Problem Setting and Framework Overview An agent cannot write a reliable SPARQL query until it knows where the answer may be stored and how that source represents the concepts in the question. This information is difficult to assume in a collection of independently maintained graphs. Names, identifiers, relations, and links between graphs can differ even when the graphs describe the same domain. Autoschema addresses this problem by observing the endpoints when a question arrives and returning only the evidence needed for that question. Figure 1 shows the framework and its role. The agent interprets the question, plans, writes SPARQL, and checks the result. Autoschema sits between the agent and the live knowledge graphs. When the agent lacks schema knowledge, it calls a grounding module and receives a compact view of the current endpoint. This separation makes the framework independent of a particular agent or execution system. Autoschema is implemented as a standalone MCP server. Its four core functions are asynchronous and accept a database key as input. An endpoint resolver maps this key to a SPARQL endpoint and its named graphs. A deployment can also pass an endpoint URL directly. The core functions do not call a language model. They issue SPARQL queries, format the observed results as grounding evidence, and return that evidence to the calling agent. Query generation and execution remain outside the framework. This interface allows the same grounding layer to be used with different agents and model families. More formally, let D = {𝐺 1, . . . , 𝐺𝑚 } be a set of RDF graphs and let 𝑞 be a natural language question. To answer 𝑞, the agent must ground four decisions. It must identify the relevant source, resolve question terms to graph entities, find the relations and paths that express the request, and connect sources when one graph is not enough. The four modules in the center of Figure 1 support these decisions. On first uncached access to a source, the framework builds a bounded live index and caches it in memory and on disk. The index records frequent classes, properties, object kinds, and real example values. Each source has one cache entry. Calls within a process use memory, and later runs can load a JSON copy from disk. Refresh is optional and can be requested at any time to rebuild the index from the current endpoint. Entity search and local path expansion are not cached and still query the endpoint when called. The index is a sampled view of the endpoint rather than a complete ontology. This choice keeps onboarding bounded on large graphs while giving the agent enough evidence to form and test a query. Appendix A gives the exact sampling limits and function signatures.

Yiming Zhang and Koji Tsuda

Table 1: Evaluation tasks. Graph-supported means that each gold answer is verified by executing a gold SPARQL query. Task

Data and evaluation focus

Resource Focused Biomedical KGQA Multi Resource Biomedical KGQA Longitudinal Biomedical Semantic QA Chemistry Knowledge Graph Transfer

RDF Portal. Factoid and list questions within one resource. RDF Portal. Factoid and list questions across resources.

3.2

Six BioASQ Task B sets. Factoid, list, and yes or no questions collected over time. tmQM-RDF. Factoid and list questions on a graph outside biomedicine.

Live Grounding Modules

The modules follow a broad to focused process. They first locate a useful source and then reveal the specific entities and paths needed to form a query. Each module has a distinct role and returns evidence at a different level of detail. Source summarization answers “which graph should the agent query?” The source catalog first retrieves candidate databases from titles, descriptions, and categories. The agent then calls get_rdf_ schema. Its inputs are a database and an optional entity class. To build its index, the function counts instances grouped by rdf:type, keeps frequent classes, and retrieves stable example IRIs. For each retained class, it samples instances and counts their predicates. It then samples predicate objects to determine whether a value is a literal, an IRI, or a blank node. For IRI objects, it also checks their observed RDF types. The returned summary includes the required named graph scope, class counts, example entity IRIs, full predicate IRIs, observed range kinds, and example values. It also includes a simple query made from a real entity and predicate. The optional entity_class argument narrows the property view after a relevant class is known. These outputs let the agent distinguish, for example, a literal identifier from an IRI valued link before it writes a filter or join. Entity resolution answers “how does this graph identify the thing named in the question?” It searches labels and common accession forms and returns candidate graph identifiers. Concretely, search_rdf_entity(database, keyword) searches common label, title, name, identifier, and alternative label predicates. It also recognizes common biomedical accession forms, such as OBO and UniProt identifiers, that may be encoded directly in an IRI rather than stored as a label. Only URI subjects are returned as anchors. Blank node identifiers are not returned because they are not stable across separate SPARQL requests. Each result pairs an IRI with the label or identifier that matched. The agent uses the question context and the source summary to choose among candidates. This step prevents a surface name from being copied into a query when the endpoint uses a different identifier. Relation and path discovery answers “how are the requested entities or values connected?” Starting from a resolved entity, it examines nearby relations and short paths. The expand_entity function takes a database and a stable entity IRI. It uses one SPARQL request to retrieve direct properties and paths through up to three nested blank nodes. A nested path must be explored within one

request because its internal blank node identifiers cannot be reused later. The response groups direct properties by predicate and shows a few observed values. For nested structures, it returns the predicate chain, its leaf values, and an executable graph scoped SPARQL pattern. Paths ending in likely value fields such as labels, identifiers, and names are shown first. The agent can copy the returned pattern into its candidate query when a value must be filtered or joined. This local expansion provides a concrete query shape that is often missing from a class level summary. Cross-database bridging answers “how can evidence from two graphs be connected?” The get_cross_db_bridges function checks three signals. It first uses an optional identifier conversion service when one is configured. It then checks whether an IRI valued property in one source points directly into an entity namespace observed in the other source. Finally, it looks for property names observed in both live indexes and ranks identifier like properties above generic display fields. Direct IRI reuse is the strongest live signal because the object in one graph is already an entity in the other. A shared property name is weaker because the two properties may have different meanings. The module therefore returns bridge candidates and a SPARQL join skeleton rather than claiming that a join is correct. The agent must execute the skeleton and inspect its rows before using the bridge in an answer. Together, the modules avoid loading a complete schema before every question. The agent can stop after source and entity grounding for a simple query, use path discovery when the graph structure is unclear, and request a bridge only when the question spans multiple sources.

3.3

Agentic Query Construction

The left side of Figure 1 shows how the modules are used in an agent loop. The agent first decides whether a knowledge graph is appropriate for the question. If so, it calls the modules needed for its current subgoal, writes a candidate SPARQL query, and runs it on the selected endpoint. A useful result can support the final answer. An empty result or an endpoint error provides feedback that the selected entity, relation, path, or source may be wrong. The agent can then request more focused grounding evidence and revise the query. The loop is a policy rather than a fixed pipeline. For a graph question, the agent normally selects a source and requests its summary once. It resolves named entities before writing entity specific triples and calls local expansion only when the required predicate is unclear. The bridge module is reserved for questions that genuinely require two sources. Tool responses are added to the model context in a compact textual form. If two attempts at the same subproblem fail, the evaluation policy asks the agent to change the predicate, source, or grounding tool instead of repeating the same query. This loop is important because no single schema view is sufficient for every question. Source summaries guide the first choice, entity and path evidence support query construction, and execution results reveal what still needs to be corrected. The process ends when the agent has enough evidence to answer or reaches the shared interaction limit described in Section 4.4. Appendix A

AutoSchema: Live Schema Grounding for Agentic Text-to-Sparql over Heterogeneous Knowledge Graphs

gives the concrete tool signatures, sampling limits, and evaluation prompt.

3.4

A Live Grounding Example

Consider the question in Figure 3: “What value is associated with the strain that shares an identifier with CCM 2634 and also relates to entity 11225?” The live calls below are abbreviated from a successful BacDive trace. IRI prefixes are shortened only for readability. 1. Resolve the first question term. The call search_rdf_entity uses source bacdive and keyword “CCM 2634.” It returns collection record 20378 with the same label. 2. Call expand_entity. For record 20378, the response contains relation describesStrain. The observed object is strain/7366. 3. Resolve the second question term. Searching bacdive for “11225” returns several candidates. The candidate with type Strain is strain/11225, labeled “Nocardiopsis buerjinensis 11225.” 4. Compare observed properties. Expanding the two strain IRIs returns hasPhylum → Actinobacteria for both entities.

The evidence grounds every graph specific part of the query. In particular, it shows that CCM 2634 denotes a collection number record rather than a strain, and that describesStrain connects that record to the strain. It also identifies hasPhylum as the shared value relation. The agent can therefore form a candidate query with the two observed triple patterns strain:7366 bds:hasPhylum ?shared and strain:11225 bds:hasPhylum ?shared, scoped to the BacDive named graph. Here, strain: and bds: abbreviate the observed BacDive entity and schema namespaces. The shared binding is Actinobacteria. No bridge call is needed after live resolution shows that both entities and the answer relation occur in the same graph. This example illustrates the main division of labor in Figure 1. The agent decides what must be compared, while autoschema supplies the source, IRIs, and predicates observed at the current endpoint.

4 Experiments 4.1 Research Questions We organize the evaluation around three questions. RQ1 asks whether live grounding improves Resource Focused and Multi Resource Biomedical KGQA. RQ2 asks whether the gains hold in Longitudinal Biomedical Semantic QA and Chemistry Knowledge Graph Transfer. RQ3 asks how live grounding affects interaction cost and which parts of the framework account for its gains.

4.2

autoschema provides the live grounding modules in Section 3.2 without an MIE file. Single shot is an ablation of autoschema that allows at most one call to each grounding module per question.

Compared Frameworks

Our main comparison is between TogoMCP and autoschema with live grounding. We use the same models, questions, endpoints, and interaction budgets in all settings: No schema provides database names and query execution but no schema evidence. It serves as a lower bound. TogoMCP provides an LLM assisted and manually reviewed MIE file with schema descriptions and worked queries for each database.

Table 2: Resource Focused Biomedical KGQA with 559 questions. Results are mean ± standard deviation over three runs. Model

Framework

Factoid acc.

List F1

Limit rate

No schema 0.164 ± .019 0.122 ± .006 53.3 ± 1.8% gpt-oss-120b TogoMCP 0.198 ± .009 0.134 ± .001 44.0 ± 1.0% AutoSchema 0.260 ± .005 0.199 ± .012 33.5 ± 1.5% No schema 0.239 ± .022 0.117 ± .009 17.6 ± 1.0% gemma4-31b TogoMCP 0.258 ± .008 0.134 ± .003 20.2 ± 0.8% AutoSchema 0.281 ± .010 0.145 ± .006 17.1 ± 2.3%

4.3

Evaluation Tasks

Table 1 summarizes the four evaluation tasks introduced in Section 1. They move from questions with guaranteed graph answers to open biomedical questions and finally to a graph outside the development domain. Biomedical KGQA. We adapt graphlet anchored generation to the RDF Portal [18]. Each question begins with a connected fragment sampled from real triples. We reconstruct and execute its gold SPARQL query, then ask a language model to express the fragment as a natural language question without seeing the answer. Resource Focused Biomedical KGQA contains questions answered within one resource. Multi Resource Biomedical KGQA uses verified links across resources. Longitudinal Biomedical Semantic QA. We use factoid, list, and yes or no questions from six yearly BioASQ Task B test sets [24]. These open questions may or may not benefit from an RDF source, so they also test whether the agent chooses graph tools when appropriate. Summary questions are outside our scope. Chemistry Knowledge Graph Transfer. We use tmQM-RDF [7], which has no pre-existing MIE and was not used to develop the framework. Section 4.9 describes its irregular schema and the transfer protocol.

4.4

Models, Metrics, and Protocol

We evaluate two models with open weights, gpt-oss-120b and gemma4-31b. Each model is served locally through vLLM on one NVIDIA A100 GPU. We use the same task instructions and budget policy in all settings. The grounding part of the prompt directs each framework to its own interface. Appendix A.3 gives the autoschema policy. We use a limit of 20 iterations in every compared setting. We also report the limit rate, which is the fraction of questions that reach the final iteration. Predictions are matched to gold synonyms using exact matching, lexical matching, and an LLM judge for unresolved pairs. We report the final judge-tier score as top-1 accuracy for factoid questions, set F1 for list questions, and accuracy for yes or no questions. Unless noted otherwise, each result is the mean ± standard deviation over three runs.

Yiming Zhang and Koji Tsuda

4.5

Biomedical Knowledge Graph QA

4.7

Table 2 reports Resource Focused Biomedical KGQA. Autoschema gives the highest factoid accuracy and list F1 for both models. It also lowers the limit rate relative to TogoMCP. The gains are larger for gpt-oss-120b, which reaches the interaction limit much more often under the other frameworks. Table 3 reports Multi Resource Biomedical KGQA. Autoschema again gives the highest mean factoid accuracy for both models and lowers the limit rate relative to TogoMCP. Variation across runs is larger than in the resource focused task, so we treat the accuracy gains as directional rather than conclusive. Trace analysis shows that many questions are solved through shared reference values found by local entity expansion. The dedicated bridge module is rarely selected, which we examine further in Section 4.10. Table 3: Multi Resource Biomedical KGQA with 226 questions. Results are mean ± standard deviation over three runs. Model

Framework

Factoid acc.

List F1

4.8

Cost and Latency

Live grounding adds endpoint requests, so we measure both wall clock latency and tool calls. Table 5 pools the two biomedical KGQA tasks and the two BioASQ test sets in Table 4. Autoschema uses fewer tool calls than TogoMCP for both models while latency remains comparable. The latency ordering differs by model and is more variable. Trace inspection suggests that an early schema lookup can replace several failed SPARQL attempts based on guessed predicates.

Limit rate

No schema 0.178 ± .004 0.138 ± .001 45.7 ± 1.4% gpt-oss-120b TogoMCP 0.167 ± .024 0.165 ± .005 49.4 ± 0.3% AutoSchema 0.203 ± .020 0.200 ± .019 40.0 ± 1.1%

Table 5: Mean per-question interaction cost across the two biomedical KGQA tasks and two selected BioASQ sets. Values are mean ± standard deviation over three runs.

No schema 0.110 ± .027 0.105 ± .010 25.1 ± 2.0% gemma4-31b TogoMCP 0.140 ± .008 0.125 ± .019 32.9 ± 1.6% AutoSchema 0.216 ± .041 0.134 ± .003 26.1 ± 1.6%

4.6

Results Across BioASQ Task B Years

We extend the gpt-oss-120b comparison to all six yearly BioASQ Task B test sets. Figure 2 shows the change in mean factoid accuracy from TogoMCP to autoschema. The mean is higher in every year. The size of the gain varies, and run variation makes some individual years less conclusive. The consistent direction across independently collected test sets provides stronger evidence of temporal robustness than any one year.

Model

Framework

Latency (s)

Tool calls

No schema 71.4 ± 5.6 13.22 ± .04 gpt-oss-120b TogoMCP 67.1 ± 5.9 12.91 ± .05 AutoSchema 59.5 ± 11.9 11.13 ± .12

Longitudinal Biomedical Semantic QA

Table 4 reports an early and a recent BioASQ test set for both models. Unlike the graph supported tasks, BioASQ also tests whether the agent avoids unnecessary graph queries. Autoschema improves mean factoid accuracy over TogoMCP for both models in both years. The gains are clearer on Task 8B than on the more variable Task 13B. List and yes or no results are mixed, which suggests that the main benefit is more reliable retrieval of short entity answers. Table 4: Longitudinal Biomedical Semantic QA on two BioASQ Task B test sets. Results are mean ± standard deviation over three runs. Model

Framework

Fact.

List F1

Yes/no

8B (2020) No schema 0.468 ± .008 0.404 ± .031 0.829 ± .026 gpt-oss-120b TogoMCP 0.510 ± .024 0.360 ± .027 0.838 ± .015 AutoSchema 0.581 ± .040 0.396 ± .022 0.860 ± .014 No schema 0.614 ± .027 0.494 ± .013 0.875 ± .013 gemma4-31b TogoMCP 0.565 ± .030 0.466 ± .008 0.877 ± .004 AutoSchema 0.625 ± .030 0.500 ± .014 0.897 ± .014 13B (2025) No schema 0.611 ± .048 0.334 ± .038 0.862 ± .019 gpt-oss-120b TogoMCP 0.554 ± .060 0.347 ± .043 0.850 ± .014 AutoSchema 0.632 ± .046 0.384 ± .014 0.837 ± .031 No schema 0.660 ± .006 0.503 ± .019 0.801 ± .019 gemma4-31b TogoMCP 0.646 ± .027 0.458 ± .006 0.825 ± .019 AutoSchema 0.681 ± .040 0.453 ± .012 0.846 ± .025

No schema gemma4-31b TogoMCP AutoSchema

4.9

80.5 ± 1.3 74.2 ± 1.6 76.4 ± 3.2

9.31 ± .08 9.22 ± .05 8.27 ± .23

Chemistry Knowledge Graph Transfer

The core evaluation uses biomedical graphs. We therefore test transfer to a 3,200-complex subset of tmQM-RDF [7]. The graph was not used to develop autoschema and has no pre-existing MIE. Its schema is irregular because values are represented through nested nodes and the same property can have several reported sources. We construct 39 graph supported questions that cover lookup, aggregation, source selection, and multi-hop traversal. For TogoMCP, we create and check an MIE using its standard workflow. This takes 28.2 minutes, 221,834 model tokens, and 106 tool calls. Live indexing takes 37.4 seconds and no model tokens. The experiment therefore measures both onboarding and answer quality. Table 6 reports one run and should be read as preliminary. Autoschema improves factoid accuracy and lowers the limit rate, but uses more time and tool calls. List F1 is unchanged. On a separate flat control graph, both frameworks reach the same factoid accuracy. These results suggest that live discovery is most useful for irregular schemas, but more graphs and repeated runs are needed.

4.10

Ablations

Iterative grounding. Table 7 compares full autoschema with the single shot ablation. On Resource Focused Biomedical KGQA, limiting each module to one call causes only small changes for

AutoSchema: Live Schema Grounding for Agentic Text-to-Sparql over Heterogeneous Knowledge Graphs

Across tasks and models

gpt-oss-120b

gemma4-31b

Change from TogoMCP to AutoSchema

gpt-oss-120b across six yearly test sets

+.20

Change in factoid accuracy

Longitudinal BioASQ Task B

+.20

+.134 +.129 +.078

+.078

+.15

+.15 +.076

+.071

+.071

+.082

+.048

10B 2022

11B 2023

+.060

+.10

+.035 +.062

+.05

+.10

+.036

+.05

+.023

0

0 Resource focused

Multi resource

BioASQ Task 8B

BioASQ Task 13B

8B 2020

Biomedical KGQA and selected BioASQ sets

9B 2021

12B 2024

13B 2025

Independent yearly BioASQ Task B test sets

Figure 2: Factoid accuracy gain of autoschema over TogoMCP. Bars show differences between three-run means. Error bars show the root sum square of the reported standard deviations and are descriptive rather than confidence intervals.

Multi Resource Biomedical KGQA Question: A strain is associated with CCM 2634 and entity 11225. What value is shared? Gold answer: Actinobacteria

TogoMCP 1

Plan

1

Use the MIE pattern and treat the collection number as a direct property of the strain.

Plan

Ground the collection record before writing SPARQL. Ask the live endpoint how the identifier is represented.

Observation

2

hasCultureCollection Number

The endpoint returns no matches because this edge is not present.

Resolve the entity, then inspect its local path.

edge.

Several query variants are empty.

2

Action

AutoSchema

Generate SPARQL with an

Action

CCM 2634 → record → strain → phylum

Observation Entity resolution finds a CultureCollectionNumber

node. Path discovery exposes describesStrain followed by hasPhylum.

Reflect

Reflect and Answer

Revise the query while keeping the same assumed relation.

The observed path supports a valid query and answer.

Iteration limit reached. No answer.

Actinobacteria. Correct in 6 calls.

Figure 3: Paired trace for a Multi Resource Biomedical KGQA question. TogoMCP continues from an incorrect static relation and reaches the interaction limit. Autoschema uses live entity resolution and local path discovery to return the correct answer. The example explains a mechanism and does not estimate how often it occurs. both models. Most of the benefit therefore comes from the first grounding request. Multi Resource Biomedical KGQA is less uniform. Results remain similar for gemma4-31b, but gpt-oss-120b loses list performance under the limit. This suggests that follow-up

grounding can matter when the agent discovers a second source during query construction.

Yiming Zhang and Koji Tsuda

Table 6: Chemistry Knowledge Graph Transfer on 39 tmQMRDF questions with gemma4-31b. Results are from one run. Framework

Fact. List F1 Limit Time (s) Calls

TogoMCP 0.273 AutoSchema 0.394

0.167 35.9% 0.167 23.1%

1060.3 15.1 1306.5 16.7

Table 7: Iterative and single shot grounding. Values are mean ± standard deviation over three runs. R and M denote the Resource Focused and Multi Resource Biomedical KGQA tasks. Task Access

Fact.

List F1

Limit

Time (s)

gpt-oss-120b R Iterative 0.260 ± .005 0.199 ± .012 33.5 ± 1.5% 69.6 ± 17.6 R Single shot 0.246 ± .013 0.185 ± .011 35.5 ± 1.0% 66.3 ± 1.9 M Iterative 0.203 ± .020 0.200 ± .018 40.0 ± 1.1% 77.2 ± 19.4 M Single shot 0.185 ± .017 0.155 ± .010 41.9 ± 2.9% 68.4 ± 1.6 gemma4-31b R Iterative 0.281 ± .010 R Single shot 0.272 ± .006 M Iterative 0.216 ± .041 M Single shot 0.227 ± .004

4.11

0.145 ± .005 17.1 ± 2.3% 100.0 ± 6.2 0.133 ± .021 16.5 ± 0.1% 97.1 ± 3.3 0.134 ± .003 26.1 ± 1.6% 105.7 ± 3.1 0.125 ± .013 24.0 ± 1.6% 103.1 ± 2.0

Qualitative Analysis

Figure 3 compares two traces for the same Multi Resource Biomedical KGQA question. TogoMCP follows a relation pattern that is absent from the endpoint and reaches the interaction limit. Autoschema first resolves the collection record and then discovers the local path to the phylum. The observed path supports the correct answer without an explicit bridge call. The other traces show the boundary of this benefit. In Chemistry Knowledge Graph Transfer, live inspection recovers the named graph and nested property path when the MIE namespaces do not match the loaded graph. On the flat control graph, both frameworks return the same answer in the same number of calls. Live grounding is therefore most useful when the endpoint representation is uncertain or differs from the static description.

5

Conclusion

We introduced live schema grounding as an alternative to requiring a prewritten and manually reviewed schema file before an agent can query a knowledge graph. We implemented it in autoschema, a general framework for agentic text-to-SPARQL. Its four capabilities expose source structure, entity candidates, local relation paths, and potential cross-database connections only when the agent needs them. This division of labor leaves interpretation and query planning to the language model while grounding structural choices in observations from the current endpoint. Across two open-weight models, autoschema consistently improves mean factoid accuracy over TogoMCP on Resource Focused Biomedical KGQA and Multi Resource Biomedical KGQA. It also improves gpt-oss-120b across six yearly BioASQ Task B test sets and reduces average tool use in the biomedical evaluation. The tmQMRDF transfer study provides additional, preliminary evidence that the approach can expose a previously undocumented graph without first producing a curated schema file. The ablations also qualify the result: one live grounding request captures most of the benefit in

Resource Focused Biomedical KGQA, whereas follow-up access can matter in Multi Resource Biomedical KGQA. These findings establish live endpoint evidence as a practical grounding interface, but not yet as a complete solution to automatic federation. The dedicated bridge capability was rarely selected, some multi resource gains are noisy, and the external transfer experiment contains only one run. A natural next step is therefore to couple live discovery with explicit source and bridge planning, stronger answer verification, and evaluations over more previously unseen graphs. More broadly, shifting schema access from static prompt context to observable, question-time evidence offers a path toward knowledge-graph agents that remain useful as their underlying data changes.

Ethics and Privacy Statement This study uses public benchmark questions and publicly accessible RDF endpoints. It does not involve human participants or collect personal data. AutoSchema sends question-dependent lookup queries to selected endpoints. These requests may reveal the scientific terms in a question to endpoint operators and may add load to public services. Our experiments use public questions without private user information. Deployments that handle sensitive questions should use access-controlled endpoints, avoid storing raw questions, and apply caching and rate limits. The framework may return incomplete or incorrect answers because endpoint content, entity matches, or generated queries can be wrong. This risk is especially important for biomedical questions. AutoSchema is intended for research and information retrieval, not for clinical decision making. Its answers should be checked against the returned source evidence before they are used in practice. We use locally hosted models with open weights, which avoids sending questions to a closed model API. Local deployment does not remove the need for secure storage, access control, and responsible use. Users are also responsible for following the terms and licenses of the data sources they query.

References [1] Maribel Acosta, Maria-Esther Vidal, Tomas Lampo, Julio Castillo, and Edna Ruckhaus. 2011. ANAPSID: An Adaptive Query Processing Engine for SPARQL Endpoints. In The Semantic Web – ISWC 2011. Springer, 18–34. doi:10.1007/9783-642-25073-6_2 [2] Keith Alexander, Richard Cyganiak, Michael Hausenblas, and Jun Zhao. 2009. Describing Linked Datasets – On the Design and Usage of VoID, the Vocabulary of Interlinked Datasets. In Proceedings of the Linked Data on the Web Workshop (CEUR Workshop Proceedings, Vol. 538). https://ceur-ws.org/Vol-538/ [3] Sören Auer, Jan Demter, Michael Martin, and Jens Lehmann. 2012. LODStats – An Extensible Framework for High-Performance Dataset Analytics. In Knowledge Engineering and Knowledge Management. Springer, 353–362. doi:10.1007/978-3642-33876-2_31 [4] Alison Callahan, José Cruz-Toledo, and Michel Dumontier. 2013. Ontology-Based Querying with Bio2RDF’s Linked Open Data. Journal of Biomedical Semantics 4, Suppl 1 (2013), S1. doi:10.1186/2041-1480-4-S1-S1 [5] Shulin Cao, Jiaxin Shi, Liangming Pan, Lunyiu Nie, Yutong Xiang, Lei Hou, Juanzi Li, Bin He, and Hanwang Zhang. 2022. KQA Pro: A Dataset with Explicit Compositional Programs for Complex Question Answering over Knowledge Base. In Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics, 6101–6119. doi:10.18653/v1/2022.acl-long.422 [6] Nilesh Chakraborty, Denis Lukovnikov, Gaurav Maheshwari, Priyansh Trivedi, Jens Lehmann, and Asja Fischer. 2021. Introduction to Neural Network-Based Question Answering over Knowledge Graphs. WIREs Data Mining and Knowledge Discovery 11, 3 (2021), e1389. doi:10.1002/widm.1389 [7] Luca Cibinel, Trond Linjordet, Johan Pensar, David Balcells, Riccardo De Bin, and Basil Ell. 2026. tmQM-RDF Data Set: A Knowledge Graph Representing

AutoSchema: Live Schema Grounding for Agentic Text-to-Sparql over Heterogeneous Knowledge Graphs

Transition Metal Complexes. Journal of Chemical Information and Modeling 66, 13 (2026), 7524–7538. doi:10.1021/acs.jcim.6c01281 [8] Jacopo D’Abramo, Andrea Zugarini, and Paolo Torroni. 2025. Investigating Large Language Models for Text-to-SPARQL Generation. In Proceedings of the 1st Workshop on Knowledge Augmented Methods for Natural Language Processing. Association for Computational Linguistics, 66–80. doi:10.18653/v1/2025.knowledgenlp1.5 [9] Daniel Dobriy, Frederik Bauer, Amr Azzam, Debayan Banerjee, and Axel Polleres. 2026. Agentic SPARQL: Evaluating SPARQL-MCP-Powered Intelligent Agents on the Federated KGQA Benchmark. arXiv:2603.06582 [cs.AI] https://arxiv.org/ abs/2603.06582 [10] Mohnish Dubey, Debayan Banerjee, Abdelrahman Abdelkawi, and Jens Lehmann. 2019. LC-QuAD 2.0: A Large Dataset for Complex Question Answering over Wikidata and DBpedia. In The Semantic Web – ISWC 2019. Springer, Auckland, New Zealand, 69–78. doi:10.1007/978-3-030-30796-7_5 [11] Vincent Emonet, Jerven Bolleman, Severine Duvaud, Tarcisio Mendes de Farias, and Ana Claudia Sima. 2024. LLM-Based SPARQL Query Generation from Natural Language over Federated Knowledge Graphs. arXiv:2410.06062 [cs.CL] https://arxiv.org/abs/2410.06062 [12] Prayushi Faldu, Indrajit Bhattacharya, and Mausam. 2024. RetinaQA: A Robust Knowledge Base Question Answering Model for Both Answerable and Unanswerable Questions. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics, 6643–6656. doi:10.18653/v1/2024.acl-long.359 [13] Shengxiang Gao, Jey Han Lau, and Jianzhong Qi. 2025. Beyond Seen Data: Improving KBQA Generalization Through Schema-Guided Logical Form Generation. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing. Association for Computational Linguistics, Suzhou, China, 8753–8772. doi:10.18653/v1/2025.emnlp-main.442 [14] Yu Gu and Yu Su. 2022. ArcaneQA: Dynamic Program Induction and Contextualized Encoding for Knowledge Base Question Answering. In Proceedings of the 29th International Conference on Computational Linguistics. International Committee on Computational Linguistics, 1718–1731. https://aclanthology.org/2022.coling1.148/ [15] Ali Hasnain, Qaiser Mehmood, Syeda Sana e Zainab, Muhammad Saleem, Jr. Warren, Claude, Durre Zehra, Stefan Decker, and Dietrich Rebholz-Schuhmann. 2017. BioFed: Federated Query Processing over Life Sciences Linked Open Data. Journal of Biomedical Semantics 8 (2017), 13. doi:10.1186/s13326-017-0118-0 [16] Jinhao Jiang, Kun Zhou, Zican Dong, Keming Ye, Xin Zhao, and Ji-Rong Wen. 2023. StructGPT: A General Framework for Large Language Model to Reason over Structured Data. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing. Association for Computational Linguistics, 9237– 9251. doi:10.18653/v1/2023.emnlp-main.574 [17] Longquan Jiang and Ricardo Usbeck. 2022. Knowledge Graph Question Answering Datasets and Their Generalizability: Are They Enough for Future Research?. In Proceedings of the 45th International ACM SIGIR Conference on Research and Development in Information Retrieval. Association for Computing Machinery, Madrid, Spain, 3209–3218. doi:10.1145/3477495.3531751 [18] Richard A. A. Jonker, Bárbara Maria Ribeiro de Abreu Martins, and Sérgio Matos. 2026. BioGraphletQA: Knowledge-Anchored Generation of Complex QA Datasets. arXiv:2604.26048 [cs.CL] https://arxiv.org/abs/2604.26048 [19] Maulik R. Kamdar, Tania Tudorache, Mark A. Musen, Javier D. Fernández, and Axel Polleres. 2019. Enabling Web-Scale Data Integration in Biomedicine through Linked Open Data. npj Digital Medicine 2 (2019), 90. doi:10.1038/s41746-0190162-5 [20] Shuichi Kawashima, Toshiaki Katayama, Hideki Hatanaka, Tatsuya Kushida, and Toshihisa Takagi. 2018. NBDC RDF Portal: A Comprehensive Repository for Semantic Data in Life Sciences. Database 2018 (2018), bay123. doi:10.1093/ database/bay123 [21] Daniel Keysers, Nathanael Schärli, Nathan Scales, Hylke Buisman, Daniel Furrer, Sergii Kashubin, Nikola Momchev, Danila Sinopalnikov, Lukasz Stafiniak, Tibor Tihon, Dmitry Tsarkov, Xiao Wang, Marc van Zee, and Olivier Bousquet. 2020. Measuring Compositional Generalization: A Comprehensive Method on Realistic Data. In International Conference on Learning Representations. https://openreview. net/forum?id=SygcCnNKwr [22] Akira R. Kinjo, Yasunori Yamamoto, Samuel Bustamante-Larriet, Jose-Emilio Labra-Gayo, and Takatomo Fujisawa. 2026. TogoMCP: Natural Language Querying of Life-Science Knowledge Graphs via Schema-Guided LLMs and the Model Context Protocol. Database 2026 (2026), baag042. doi:10.1093/database/baag042 [23] Mathias Konrath, Thomas Gottron, Steffen Staab, and Ansgar Scherp. 2012. SchemEX: Efficient Construction of a Data Catalogue by Stream-Based Indexing of Linked Data. Journal of Web Semantics 16 (2012), 52–58. doi:10.1016/j.websem. 2012.06.002 [24] Anastasia Krithara, Anastasios Nentidis, Konstantinos Bougiatiotis, and Georgios Paliouras. 2023. BioASQ-QA: A Manually Curated Corpus for Biomedical Question Answering. Scientific Data 10 (2023), 170. doi:10.1038/s41597-023-02068-4

[25] Yunshi Lan, Gaole He, Jinhao Jiang, Jing Jiang, Wayne Xin Zhao, and Ji-Rong Wen. 2021. A Survey on Complex Knowledge Base Question Answering: Methods, Challenges and Solutions. In Proceedings of the Thirtieth International Joint Conference on Artificial Intelligence. International Joint Conferences on Artificial Intelligence Organization, 4483–4491. doi:10.24963/ijcai.2021/611 [26] Tianle Li, Xueguang Ma, Alex Zhuang, Yu Gu, Yu Su, and Wenhu Chen. 2023. Few-Shot In-Context Learning for Knowledge Base Question Answering. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics, 6966–6980. doi:10.18653/v1/2023.acl-long.385 [27] Haoran Luo, Haihong E, Zichen Tang, Shiyao Peng, Yikai Guo, Wentai Zhang, Chenghao Ma, Guanting Dong, Meina Song, Wei Lin, Yifan Zhu, and Anh Tuan Luu. 2024. ChatKBQA: A Generate-then-Retrieve Framework for Knowledge Base Question Answering with Fine-Tuned Large Language Models. In Findings of the Association for Computational Linguistics: ACL 2024. Association for Computational Linguistics, 2039–2056. doi:10.18653/v1/2024.findings-acl.122 [28] Anca Marginean. 2017. Question Answering over Biomedical Linked Data with Grammatical Framework. Semantic Web 8, 4 (2017), 565–580. doi:10.3233/SW160223 [29] Thinhinane Mecharnia and Mathieu d’Aquin. 2025. Performance and Limitations of Fine-Tuned LLMs in SPARQL Query Generation. In Proceedings of the Fourth International Workshop on Knowledge-Augmented Methods for Natural Language Processing. Association for Computational Linguistics, 69–77. https://aclanthology.org/2025.genaik-1.8/ [30] Nandana Mihindukulasooriya, María Poveda-Villalón, Raúl García-Castro, and Asunción Gómez-Pérez. 2015. Loupe – An Online Tool for Inspecting Datasets in the Linked Data Cloud. In Proceedings of the ISWC 2015 Posters & Demonstrations Track (CEUR Workshop Proceedings, Vol. 1486). https://ceur-ws.org/Vol-1486/ paper_113.pdf [31] Hikaru Nagazumi, Yuki Moriya, Shuichi Kawashima, Toshiaki Katayama, and Kana Shimizu. 2026. Accurate SPARQL Generation via In-Context Learning and Schema-Based Query Construction. Bioinformatics 42, 5 (2026), btag174. doi:10.1093/bioinformatics/btag174 [32] Mayur Patidar, Prayushi Faldu, Avinash Singh, Lovekesh Vig, Indrajit Bhattacharya, and Mausam. 2023. Do I Have the Knowledge to Answer? Investigating Answerability of Knowledge Base Questions. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics, 10341–10357. doi:10.18653/v1/2023.acl-long.576 [33] Aleksandr Perevalov, Xi Yan, Liubov Kovriguina, Longquan Jiang, Andreas Both, and Ricardo Usbeck. 2022. Knowledge Graph Question Answering Leaderboard: A Community Resource to Prevent a Replication Crisis. In Proceedings of the Thirteenth Language Resources and Evaluation Conference. European Language Resources Association, Marseille, France, 2998–3007. https://aclanthology.org/ 2022.lrec-1.321/ [34] Andreas Schwarte, Peter Haase, Katja Hose, Ralf Schenkel, and Michael Schmidt. 2011. FedX: Optimization Techniques for Federated Query Processing on Linked Data. In The Semantic Web – ISWC 2011. Springer, 601–616. doi:10.1007/978-3642-25073-6_38 [35] Yiheng Shu, Zhiwei Yu, Yuhan Li, Börje F. Karlsson, Tingting Ma, Yuzhong Qu, and Chin-Yew Lin. 2022. TIARA: Multi-Grained Retrieval for Robust Question Answering over Large Knowledge Base. In Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing. Association for Computational Linguistics, 8108–8121. doi:10.18653/v1/2022.emnlp-main.555 [36] Ana Claudia Sima, Tarcisio Mendes de Farias, Maria Anisimova, Christophe Dessimoz, Marc Robinson-Rechavi, Erich Zbinden, and Kurt Stockinger. 2022. Bio-SODA UX: Enabling Natural Language Question Answering over Knowledge Graphs with User Disambiguation. Distributed and Parallel Databases 40 (2022), 409–440. doi:10.1007/s10619-022-07414-w [37] Ana Claudia Sima, Tarcisio Mendes de Farias, Erich Zbinden, Maria Anisimova, Manuel Gil, Heinz Stockinger, Kurt Stockinger, Marc Robinson-Rechavi, and Christophe Dessimoz. 2019. Enabling Semantic Queries across Federated Bioinformatics Databases. Database 2019 (2019), baz106. doi:10.1093/database/baz106 [38] Blerina Spahiu, Riccardo Porrini, Matteo Palmonari, Anisa Rula, and Andrea Maurino. 2016. ABSTAT: Ontology-Driven Linked Data Summaries with Pattern Minimalization. In The Semantic Web: ESWC 2016 Satellite Events. Springer, 381– 395. doi:10.1007/978-3-319-47602-5_51 [39] Jiashuo Sun, Chengjin Xu, Lumingyuan Tang, Saizhuo Wang, Chen Lin, Yeyun Gong, Lionel Ni, Heung-Yeung Shum, and Jian Guo. 2024. Think-on-Graph: Deep and Responsible Reasoning of Large Language Model on Knowledge Graph. In International Conference on Learning Representations. https://openreview.net/ forum?id=nnVO1PvbTv [40] Alon Talmor and Jonathan Berant. 2018. The Web as a Knowledge-Base for Answering Complex Questions. In Proceedings of the 2018 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, Volume 1. Association for Computational Linguistics, 641–651. doi:10.18653/v1/N18-1059

Yiming Zhang and Koji Tsuda

[41] Guangzhi Xiong, Qiao Bao, and Wen Zhao. 2024. Interactive-KBQA: Multi-Turn Interactions for Knowledge Base Question Answering with Large Language Models. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics, 10561–10582. doi:10.18653/v1/2024.acl-long.569 [42] Xi Ye, Semih Yavuz, Kazuma Hashimoto, Yingbo Zhou, and Caiming Xiong. 2022. RNG-KBQA: Generation Augmented Iterative Ranking for Knowledge Base Question Answering. In Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics, 6032–6043. doi:10.18653/v1/2022.acl-long.417 [43] Wen-tau Yih, Matthew Richardson, Chris Meek, Ming-Wei Chang, and Jina Suh. 2016. The Value of Semantic Parse Labeling for Knowledge Base Question Answering. In Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics (Volume 2: Short Papers). Association for Computational Linguistics, 201–206. doi:10.18653/v1/P16-2033 [44] Yiming Zhang and Koji Tsuda. 2026. SAGA: Schema-Aware Grounding for Agentic Text-to-SPARQL Generation. arXiv:2607.14494 [cs.CL] https://arxiv. org/abs/2607.14494

A

AutoSchema Tool Interfaces

Autoschema is implemented as a standalone MCP server. Its core interface consists of four asynchronous functions. The functions only query RDF endpoints and do not call a language model. A deployment maps each database argument to an endpoint and zero or more named graphs. It may instead accept an endpoint URL directly. Query execution remains outside the framework. The agent uses the returned evidence to construct a query and sends that query to the executor available in its environment. Table 8: Core MCP tools exposed by autoschema. Defaults are shown in the signatures. Tool and inputs

Returned grounding evidence

get_rdf_schema database, optional entity_class=""

Query scope, frequent classes with counts and example IRIs, observed properties with range kinds and values, and example SPARQL queries. The optional class name narrows the property view. Candidate entity IRIs and labels found through common label and identifier properties. For recognized biomedical accessions, the response may provide a directly constructed IRI instead of a label match. Direct properties and paths that pass through as many as three nested blank nodes. Each nested path includes a SPARQL pattern that can be run again to obtain a filterable or joinable result. Candidate links based on an optional identifier conversion service, direct IRI reuse, or property names observed in both sources. The response includes a join skeleton when a shared property is found.

search_rdf_entity database, keyword, optional limit=10 expand_entity database, entity_iri

get_cross_db_bridges database_a, database_b

A.1

Live Index and Output Scope

Section 3.2 describes how the live index is built. The current implementation surveys at most 25 classes and 40 properties per class. The property survey uses up to 300 sampled instances of a class. Requests are issued with bounded concurrency. The index is cached in memory and on disk so that later calls do not repeat the endpoint work. A deployment can rebuild the cache when the source changes. This interface returns observed evidence rather than a complete ontology. A class or property that is absent from the summary may still exist outside the bounded sample. Individual endpoint failures are skipped instead of aborting the entire index build. The tools therefore help the agent form and test a query, but they do not prove that an unobserved relation is absent.

A.2

Source Catalog Adapter

The standalone server can work with one endpoint or a registry of named endpoints. Our evaluation uses many named biomedical sources. Its adapter also exposes three catalog calls. They are find_ databases, list_databases, and list_categories. These calls select a source before the four core tools are used. Existing source titles and descriptions are retained when available. For a source without a catalog record, the adapter derives a short entry from class and property names in the live index. This entry helps source selection but does not provide query patterns or manually written schema relations.

A.3

Evaluation Prompt Policy

The evaluation wrapper converts the MCP input schemas into function calls and returns textual tool results to the agent. Each result is limited to 6,000 characters before it is added to the model context. The AutoSchema system prompt applies the following policy. (1) First decide whether the question calls for structured graph data. General facts and literature questions do not open an RDF source only as a precaution. (2) For a graph question, call find_databases once. Then call get_rdf_schema once for each selected source. (3) Use search_rdf_entity to map a name in the question to an IRI. Use expand_entity when the needed value is not a direct property or may be stored behind blank nodes. (4) For a question that truly needs two sources, call the bridge tool once before constructing the join. (5) Execute the candidate SPARQL with the required namedgraph scope. If two attempts at the same subproblem fail or return no rows, change the predicate, source, or tool instead of repeating the same attempt. (6) Return a concise answer when enough evidence has been found. If the interaction budget is nearly exhausted, return the best supported answer available rather than ending without an answer. The task instructions and the failure-pivot rule are shared across compared frameworks. The grounding block above replaces instructions for reading a prewritten schema file with calls to the live interfaces.

Related documents

• KGVoyager: Knowledge Graph Agnostic Question Answering via Agentic Navigation#822207
• Perceptron Connectives in Knowledge Representation#732349
• A survey of RDF stores & SPARQL engines for querying knowledge graphs#646943
• BuildGraph: A Synthetic Multi-Archetype Building Knowledge Graph Dataset#1154661
• Benchmarking Automated Knowledge Graph Construction from Semi-Structured Data#1108882