The SPARQL ecosystem has become increasingly fragmented as engines introduce valuable but incompatible language extensions. This growing diversity undermines query portability, tooling reliability, and the pace of innovation. To address this, we designed a modular parser architecture that supports dynamic extension and modular grammar definitions. This paper presents a builder-based, TypeScript-native parser framework inspired by Chevrotain and the modular principles of Comunica. Our prototype demonstrates that key SPARQL extensions can be integrated, altered, or removed with minimal effort and strong type safety. These results suggest that modular, declarative parsing is not only feasible but essential for keeping pace with evolving SPARQL standards. Looking forward, we identify the need for round-trippable ASTs, Babel-inspired generators and transformer pipelines to enable a complete, future-proof SPARQL toolchain.
The SPARQL query language [
In this work, we show the need for a modular parser and what such a parser could look like.
Unlike traditional parser generators such as ANTLR [
A modular parser, that allows you to add, override, or swap grammar fragments at runtime,
would empower both researchers and practitioners to create a new generation of language-aware
SPARQL tools. This opens the door to use cases such as heterogeneous query tooling (e.g., adapting
editors like YASGUI [
The next section touches lightly on the related work, while Section 3 describes the system architecture. Section 4 sketches the demonstration that we will provide to the work‐shop. In Section 5 we conclude the future work and desired impact of this research.
In this section, we examine prominent software packages in the SPARQL ecosystem that implement parsing capabilities. Our findings are summarized in Fig. 1.
Notably, all discussed major open-source SPARQL parsers rely on either parser generators or parser-building toolkits to define their grammars. In compiled languages such as Rust or Java, the parser generation step can be integrated directly into the main build step—e.g., Oxigraph uses rustpeg for this purpose. Interestingly, in our survey only Stardog’s Millan does not use a parser builder. Instead, it uses Chevrotain without constructing an Abstract Syntax Tree (AST); it appears to focus solely on validation rather than full syntactic analysis.
This highlights a broader pattern: while parser generators dominate SPARQL tooling, few systems are designed with modularity or extensibility as a first-class concern. In particular, full modularity—including the ability to remove grammar rules—is not supported in current public implementations, making adaptation or evolution of these parsers difficult.
Yasgui
1. Hand-built parsers: These are manually implemented parsers tailored to a specific
grammar. While they can be highly performant due to low-level optimizations and
language-specific design, they are often difficult to maintain, extend, or modularize.
2. Parser generators: Tools such as ANTLR [
To support modularity while keeping the mental model approachable, a modular parser should
be build using a parser building toolkit. Parsing itself is typically divided into multiple phases [
Inspired by the Comunica modular query engine [
However, unlike Comunica which uses Components.js, a dependency injection framework using RDF based config files, the modular query engine can be configured within the host language itself since components share a similar interface. We propose that a parser be build using a builder pattern and that parser packages export the builder used, so other may extend upon it. Using a builder pattern for the parser allows you to take a builder that is used to build one parser and manipulate the grammar rules to construct a new parser. Concretely, we propose a builder which allows rules to be registered by name into a rule map, thereby creating a loose coupling between registered rules. Each rule is defined as a ParserRule object, containing both a rule name and a rule implementation. Rule implementations can be expressed declaratively using Chevrotain’s grammar definition functions like: 1. SUBRULE : invokes another rule, registered under some name in the current parser, 2. MANY : matches zero or more occurrences of a pattern, 3. OR : matches one of several alternatives.
We propose, each rule implementation returns a function that, when invoked, receives the parsing context and any parameters, and outputs part of the final syntax tree. Listing 1 shows an example parser rule definition. The ParserBuilder can then be used for compositional construction and extension through methods like addRule , deleteRule , merge , and typePatch. The typePatch utility would enable type updates to existing rules — particularly useful when extending or modifying a dependent rule without altering the original rule’s implementation. After the construction of your parser, you can build it, as shown in Listing 2, returning a parser which allows you to start parsing a string from any of the parser rules added to the builder - a property transferred from the underlying parser builder toolkit.
import type { SparqlRule } from '@traqula/core'; const iriOrNil: SparqlRule<'iriOrNil', URL | null> = <const>{ name: 'iriOrNil', impl: ({SUBRULE, CONSUME, OR}) => () => OR<URL | null>([ {ALT: () => SUBRULE(iri, undefined)}, {ALT: () => {
CONSUME(nilToken); return null; } }, ]), }; Listing 1: The definition of a parser rule parsing either a URI of the nil token, returning the parser URI or null respectively.
import { ParserBuilder } from '@traqula/core'; const parser = ParserBuilder .create([ iriOrNil, rule1 ]) .addRule(rule2) .patchRule(rule1Alternative) .build({
tokenVocabulary: myLexerBuilder.tokenVocabulary, }); // The argument and return types of the function are known, // ast will thus be inferred to have the type `URL | null`.
const ast = parser.iriOrNil(myString, myContext, myParameters) Listing 2: The construction of a parser including the iriOrNil rule constructed in Listing 1. It also shows how to parse using the iriOrNil rule as the starting rule.
As for the lexer, a similar approach to the parser should be taken. Tokens should be coupled loosely through a name-definition map. The consumption of a token then results in the consumption of the token with that name in the used lexer. Besides that our only requirement is that the tokens can be expressed through the definition of a regex.
In the workshop demonstration, we will showcase how our proof of concept modular
parserbuilder enables straightforward modification and extension of the existing parsers. Starting from a
prebuilt SPARQL 1.1 parser, we will incrementally evolve the grammar in four small steps using
the described builder-based architecture. Each change will be demonstrated live, with code edits
performed in an IDE and parser behavior verified in a browser-based UI. Specifically, we will:
1. extend SPARQL to support the ADJUST function [
These modifications will demonstrate how the modular parser architecture—built around builders enables safe and modular grammar changes with minimal effort. The focus will be on how individual grammar components can be extended or replaced with‐out touching unrelated parts of the parser. We will also highlight how the use of strong typing improves the developer experience by surfacing integration errors at compile time.
For each of the extensions we alter the grammar rules in accordance to the SPARQL 1.1
specification [
While the demo is not interactive for attendees, all code and tooling will be made available for experimentation after the session. The demo will serve to illustrate how a modular parser builder enables a new generation of language-aware SPARQL tools with modular, declarative grammar support and a strong developer experience.
In this paper, we presented the need for a modular parser, and offered an initial prototype to cover this need. Our prototype uses a builder-based architecture for constructing extensible SPARQL parsers. By embracing runtime modularity, declarative rule definitions, and strong typing, our approach enables a new class of SPARQL tools that can evolve alongside a rapidly diversifying query ecosystem. Through our demonstration, we showed that parser modification can be performed with minimal overhead and high confidence in correctness.
Looking ahead, several important challenges remain:
1. In order to bootstrap the adoption of the modular parser, a robust, default parser with a
well-defined Abstract Syntax Tree (AST) format should be created. This AST should
support round-tripping—ensuring that a query parsed into the AST and then regenerated
from it yields a string-identical query. This requirement on the AST will facilitate the
creation of language tools such as linters.
2. To support such round-tripping, we will need to design a corresponding generator. This
generator could follow architectural patterns established by the Babel JavaScript compiler
[
Together, these next steps would complete a robust pipeline: from parsing, through transformation, to code generation—all powered by modular, declarative components. We hope this work provides a foundation for building SPARQL tools that are not only adaptable to change, but actively enable it.
Acknowledgements.
Jitse De Smet is a predoctoral fellow of the Research Foundation – Flanders (FWO) (1SB8525N). Ruben Taelman is a postdoctoral fellow of the Research Foundation – Flanders (FWO) (1202124N).
During the preparation of this work, the author(s) used Chat-GPT-4 in order to: Paraphrase and reword, improve writing style, perform grammar and spelling checks, and drafting the abstract. After using these tool(s)/service(s), the author(s) reviewed and edited the content as needed and take(s)full responsibility for the publication’s content.