SABER: A SQL-Compatible Semantic Document Processing System Based on Extended Relational Algebra

TL;DR

SABER introduces a SQL-compatible semantic algebra based on extended relational algebra, enabling unified, optimized, and formally correct processing of structured and unstructured data in semantic data processing systems.

Contribution

The paper presents SABER, a novel algebraic foundation for SDPSs that supports logical plan construction, optimization, and formal correctness, with a SQL interface for mixed data processing.

Findings

Demonstrates feasibility of a unified semantic algebra for SDPSs.

Enables mixing and matching operators from different SDPSs.

Provides formal correctness guarantees for semantic operations.

Abstract

The emergence of large-language models (LLMs) has enabled a new class of semantic data processing systems (SDPSs) to support declarative queries against unstructured documents. Existing SDPSs are, however, lacking a unified algebraic foundation, making their queries difficult to compose, reason, and optimize. We propose a new semantic algebra, SABER (Semantic Algebra Based on Extended Relational algebra), opening the possibility of semantic operations' logical plan construction, optimization, and formal correctness guarantees. We further propose to implement SABER in a SQL-compatible syntax so that it natively supports mixed structured/unstructured data processing. With SABER, we showcase the feasibility of providing a unified interface for existing SDPSs so that it can effectively mix and match any semantically-compatible operator implementation from any SDPS, greatly enhancing SABER's applicability for community contributions.

Tables

Table 1. Table 1. Overview of SABER

Category	Operator Name	RA Symbol	SQL Mapping	Semantic Operator	SABER SQL UDF
Basic	Selection	$\sigma$	WHERE	${\sigma }^{\text{sem}}$	SEM_WHERE(‘semantic_query’)
	Projection	$\pi$	SELECT	${\pi }^{\text{sem}}$	SEM_SELECT(‘semantic_query’) AS alias
	Product	$\times$	Relations in FROM	N/A	N/A
	Set-Difference	${-}_S$	EXCEPT	${-}_S^{\text{sem}}$	SEM_DISTINCT(SEM_EXCEPT_ALL(SABER query1, SABER query2))
	Bag-Difference	${-}_B$	EXCEPT ALL	${-}_B^{\text{sem}}$	SEM_EXCEPT_ALL(SABER query1, SABER query2)
	Set-Union	${\cup }_S$	UNION	${\cup }_S^{\text{sem}}$	SEM_DISTINCT(SABER query1 UNION ALL SABER query2)
	Bag-Union	${\cup }_B$	UNION ALL	N/A	N/A
Compound	Set-Intersection	${\cap }_S$	INTERSECT	${\cap }_S^{\text{sem}}$	SEM_DISTINCT(SEM_INTERSECT_ALL(SABER query1, SABER query2))
	Bag-Intersection	${\cap }_B$	INTERSECT ALL	${\cap }_B^{\text{sem}}$	SEM_INTERSECT_ALL(SABER query1, SABER query2)
	Join	$\bowtie$	JOIN	${\bowtie }^{\text{sem}}$	SEM_JOIN(Table1, Table2, ‘semantic_query’)
Extended	Grouping	$\gamma$	GROUP BY	${\gamma }^{\text{sem}}$	SEM_GROUP_BY(attribute, k)
	Aggregation	$\xi$	SUM, AVG, etc.	${\xi }^{\text{sem}}$	SEM_AGG([attribute, ]‘semantic_query’) AS alias
	Deduplication	$\delta$	DISTINCT	${\delta }^{\text{sem}}$	SEM_DISTINCT(attribute)
	Sorting	$\tau$	ORDER BY	${\tau }^{\text{sem}}$	SEM_ORDER_BY([attribute, ]‘semantic_query’)
	Top-$k$	$\lambda$	LIMIT	N/A	N/A

Table 2. Table 2. Support for Semantically Enriched Relational Algebra Operators Across SDPSs

Category	Operator	LOTUS	DocETL	Palimpzest
Basic	${\sigma }^{\text{sem}}$ Selection	✓  sem_filter	✓  Filter	✓  sem_filter, filter
	${\pi }^{\text{sem}}$ Projection	✓  sem_map, sem_extract	✓  Map, Parallel Map, Extract	✓  sem_add_columns, project, map
	${-}^{\text{sem}}$ Difference	$\times$	$\times$	$\times$
Compound	${\cap }^{\text{sem}}$ Intersection	$\times$	$\times$	$\times$
	${\bowtie }^{\text{sem}}$ Join	✓  sem_join, sem_sim_join	✓  Equijoin	$\times$
Extended	${\gamma }^{\text{sem}}$ Group-by	✓  sem_cluster_by	✓  Cluster	✓  groupby
	${\xi }^{\text{sem}}$ Aggregation	✓  sem_agg	✓  Reduce	$△$  count, average
	${\delta }^{\text{sem}}$ Deduplication	✓  sem_dedup	✓  Resolve	$\times$
	${\tau }^{\text{sem}}$ Sorting	✓  sem_topk	✓  Rank	✓  retrieve

Table 3. Table 3. Top Movies per Backend Related to Personal Resilience (Director Summaries Truncated for Space)

Backend	Title	Director	Year	Rating	Director Summary
LOTUS	The Shawshank Redemption	Frank Darabont	1994	9.3	Frank Darabont, born in a refugee camp in France and raised in Los Angeles, overcame…
	One Flew Over the Cuckoo’s Nest	Milos Forman	1975	8.7	Milos Forman, orphaned during World War II after losing his parents to the Nazis, overcame…
	The Pianist	Roman Polanski	2002	8.5	Roman Polanski, a Polish filmmaker born in 1933, overcame the harrowing challenges…
	Modern Times	Charles Chaplin	1936	8.5	Charlie Chaplin overcame numerous challenges throughout his life, including a tumultuous…
	Bicycle Thieves	Vittorio De Sica	1948	8.2	Vittorio De Sica overcame the challenges of a poor upbringing in Naples by transitioning…
DocETL	The Shawshank Redemption	Frank Darabont	1994	9.3	Frank Darabont overcame the challenges of being a refugee child by establishing himself…
	One Flew Over the Cuckoo’s Nest	Milos Forman	1975	8.7	Milos Forman surmounted the traumatic loss of his parents during World War II and the…
	City of God	Fernando Meirelles	2002	8.6	Fernando Meirelles overcame the challenges of transforming a complex story with over…
	The Pianist	Roman Polanski	2002	8.5	Roman Polanski overcame immense challenges during his childhood, including surviving the…
	American History X	Tony Kaye	1998	8.5	Tony Kaye faced significant challenges in his career, including disowning the final cut of…
Palimpzest	The Shawshank Redemption	Frank Darabont	1994	9.3	Frank Darabont overcame the challenges of being a refugee and struggling in the film…
	One Flew Over the Cuckoo’s Nest	Milos Forman	1975	8.7	Milos Forman overcame the loss of his parents during World War II and political upheaval…
	It’s a Wonderful Life	Frank Capra	1946	8.6	Frank Capra overcame poverty, family opposition to his education, and professional…
	Harakiri	Masaki Kobayashi	1962	8.6	Masaki Kobayashi overcame the challenge of being a prisoner of war to create impactful…
	The Lion King	Roger Allers	1994	8.5	Roger Allers overcame the challenge of having his project ’Kingdom of the Sun’ retooled…

Full text

1. Introduction

The emergence of large language models (LLMs) has transformed document-centric data processing Zhuang et al. (2025); Delgado-Chaves et al. (2025); Patel et al. (2025); Shankar et al. (2025); Liu et al. (2025). LLMs provide rich semantic understanding, enabling systems to interpret, reason over, and extract information from unstructured content using natural language interfaces with low engineering effort. Building on these capabilities, a new class of semantic data processing systems (SDPSs) has emerged. Systems such as LOTUS Patel et al. (2025), DocETL Shankar et al. (2025), and Palimpzest Liu et al. (2025) offer LLM-backed operations for tasks like filtering, extraction, joining, and clustering based on semantic content. These systems expose natural-language-based APIs to support unstructured document processing.

However, we find that a major limitation of the existing SDPSs is the lack of a unified algebraic foundation. Each system defines its own semantic operations in isolation, with nuanced deviations or limitations compared to the standard relational semantics. As a result, multi-step pipelines involving operations such as joins, filtering, grouping, and set/bag difference become difficult to compose, reason about, or optimize. In contrast, the success of SQL systems for structured data is due to the foundation of standard relational algebra Grumbach et al. (1996); Garcia-Molina et al. (2000); Slivinskas et al. (2002, 2001); Console et al. (2022); Grumbach and Milo (1993); Albert (1991); Benzaken and Contejean (2019); Guagliardo and Libkin (2017); Grefen and de By (1994), which enables correct composition and optimization of complex queries. To bridge this gap, we propose Semantic Algebra Based on Extended Relational algebra (SABER), a formal algebra for semantic data processing that augments standard relational algebra with logical semantic operators with well-defined semantics, such as semantic selection, projection, join, difference, intersection, grouping, and sorting. Such formalisms are essential not only for correct declarative query evaluation but also for enabling SDPS’s logic plan optimization. In this work, we describe how we define the logical semantic operators in SABER. Then we analyze existing SDPSs, including LOTUS, DocETL, and Palimpzest, and demonstrate possible mapping of their operators and their limitations or deviations that prevent them from correctly expressing common queries. This comparative evaluation reveals critical gaps in functionality, particularly in the support for difference and intersection, which are essential for expressing exclusion and overlap in semantic pipelines.

Another limitation of existing SDPSs is the inability to handle mixed structured/unstructured data easily due to its laser focus on document processing. In fact, production systems often have to handle a mix or nesting of structured, semi-structured, and unstructured data Ong et al. (2014). To address this challenge, we augment the SQL syntax with a number of semantic operators (such as SEM_SELECT, SEM_WHERE, SEM_ORDER_BY) and implement a query rewriter to compose correct semantic queries in one of the SDPSs using the mapping from the previous analysis. Specifically, the SDPSs’ implementations are treated as physical operators that correspond to the logical operators in SABER if they are compatible based on our analysis. Then, our system can freely choose one of the SDPSs’ implementations or mix-n-match implementations from different SDPS systems. For the missing semantically-compatible SDPS operators, SABER falls back to its own implementation. As a result, we show that SABER opens up an opportunity to provide a unified interface in a system that can integrate existing SDPSs’ physical operator implementation, similar to works that provide unified relational interfaces for heterogenous data systems Agrawal et al. (2018); Beedkar et al. (2023).

In summary, the major contributions of this work are as follows. (1) We propose SABER as a new SDPS grounded in a semantic algebra based on extended relational algebra, which makes SABER amenable to reasoning its correctness and logic plan optimization. (2) We propose to implement SABER in a SQL-compatible syntax, making it directly applicable to processing mixed structured and unstructured data. (3) Based on our analysis of three modern SDPS systems’ semantic compatibility with SABER, we further show that SABER can provide a unified interface to all SDPSs, allowing SABER to freely reuse semantic implementations from either SDPS systems. Experimentation further demonstrates the validity and practicality of SABER as a novel SDPS.

2. Related Work

Relational Algebra for SQL. Relational algebra serves as the formal backbone of structured query languages, providing a logical framework for reasoning about query correctness, equivalence, and transformation Grumbach et al. (1996); Garcia-Molina et al. (2000); Console et al. (2022); Grumbach and Milo (1993); Albert (1991); Benzaken and Contejean (2019). Classical relational algebra assumes set semantics, but practical database systems predominantly adopt bag (multi-set) semantics to reflect duplicate-preserving behaviors in SQL. To model this, researchers have proposed bag-extended relational algebras with well-defined operators for union, join, difference, and projection. To further capture ordering in query optimization, list-based relational algebra has been introduced Slivinskas et al. (2002), enabling formal treatments of top-$k$ queries. These algebraic frameworks support algebraic equivalences, transformation rules, and cost-based optimization strategies foundational to SQL query processing. Lack of such formalism in existing SDPSs presents a key limitation for correctly and efficiently composing and optimizing queries. In this work, we attempt to address the limitation by designing SABER for enabling declarative query evaluation over a mix of structured and unstructured data.

SQL towards Unstructured Data. Recent extensions to support unstructured data in SQL include SUQL Liu et al. (2024), which introduces ANSWER and SUMMARY as user-defined functions but without algebraic semantics. SSQL Mittal et al. (2024) enables semantic vector filtering via SEMANTIC clauses, limited by embedding granularity and absence of structured query semantics. UQE Dai et al. (2024) defines UQL for unstructured data analytics via LLM-based sampling and planner scheduling. BINDER Cheng et al. (2023) augments symbolic programs with LLM calls through unified APIs, improving generality but lacking algebraic formalism. As they only extend the SQL solely for the specific tasks they are designed for, they cannot be directly used as the common semantic algebra for SDPSs. In contrast, our work augments the extended relational algebra with a number of logical semantic operators, and our system supports the correct mapping of them to the underlying SDPSs’ implementation to preserve SQL semantics.

Semantic Data Processing Systems. A growing body of work has investigated LLM-backed semantic data processing. Systems such as LOTUS Patel et al. (2025), DocETL Shankar et al. (2025), and Palimpzest Liu et al. (2025) exemplify this trend, each introducing abstractions for semantic filtering, extraction, joining, or clustering based on LLM-generated embeddings or prompt responses. While these systems demonstrate the practical benefits of integrating LLMs into data workflows, they lack a shared formal semantic foundation. Operator semantics are defined in system-specific terms, without unified algebraic rules or formal notions of equivalence. Additionally, the supported sets of operators vary across systems, and core semantic relational primitives such as difference, intersection, or deduplication are often missing or only partially implemented. To date, no existing SDPS defines a general-purpose algebra that integrates LLM-driven semantics with SQL-compatible operators. This gap limits composability, interoperability, and formal reasoning, motivating the need for a framework like SABER to unify semantic and relational paradigms.

Cross-platform data processing. Apache Wayang Agrawal et al. (2018); Beedkar et al. (2023) is a unified framework for integrating multiple data systems. It allows mix-n-match physical operator implementation from different data systems to compose a query pipeline for a SQL query under the standard extended relational algebra. Different from Apache Wayang, our work extends the relational algebra with LLM-backed semantic operators and enables the integration of SDPSs.

3. The Design of SABER

3.1. Algebraic Form and Integration Potential

We present Semantic Algebra Based on Extended Relational Algebra (SABER), which extends the extended relational algebra framework introduced by Slivinskas et al. (2002), where relations are represented as ordered lists to capture duplicates and ordering, moving beyond the set-theoretic formulation. Additional insights are drawn from Garcia-Molina et al. (2000); Grumbach et al. (1996); Grefen and de By (1994).

Table 1 provides an overview of SABER. It categorizes operators into three groups: Basic, which includes fundamental relational expressions Grefen and de By (1994); Compound, which consists of operators expressible using the basic ones; and Extended, which contains operators that support some of the additional features of SQL (e.g., ORDER BY) that cannot be expressed using only Basic and Compound operators. SABER comprises 12 conventional relational algebra operators and 10 semantic relational operators. Semantic operators are denoted with a superscript sem, e.g., $\sigma^{\textit{sem}}$, to distinguish them from their classical counterparts. Each semantic operator in SABER incorporates language-based reasoning, similarity computation, or prompt-driven transformations to handle unstructured or loosely structured data. The Product, Bag-Union, which corresponds to Union-all in Slivinskas et al. (2002), and Top-$k$ operators do not have semantic counterparts because their $\lambda$-calculus definitions rely solely on standard auxiliary functions and the $Loop$ function Slivinskas et al. (2002). In other words, unlike other relational algebra operators, they do not need LLM-based semantic involvement.

Formally, the semantic operators are defined by replacing the non-semantic data transformation or comparison with semantic transformation or comparison in their counter-parts in the standard extended relational algebra. For example, $\sigma_{P}^{sem}(r)$ is defined as filtering each row from subexpression $r$ by evaluating the boolean semantic predicate $P$ on it, which is usually implemented by invoking LLM with a prompt comprising the user provided natural language predicate augmented with additional metadata and prompt words, and only retain those where $P$ evaluates to true. Deduplication $\delta^{sem}$ is defined based on similarity-based equality instead of data type-based equality. Semantic projection is defined over a collection $\mathcal{F}^{\textit{sem}}$ of semantic expressions ${{{f}}_{i}}^{\textit{sem}}$. Semantic aggregation is defined over a function set $\mathbb{F}^{\textit{sem}}$ containing operators $F_{i}^{\textit{sem}}$ with semantic interpretation. Semantic grouping—corresponding to GetGroup in Slivinskas et al. (2002)—generalizes equality-based grouping by collecting all tuples whose group-by attributes are semantically equivalent to those of the reference tuple. Semantic difference relies on ${\texttt{isIn}}^{\textit{sem}}$, which evaluates membership based on semantic equivalence. Semantic sorting uses an attribute order specification $a^{\textit{sem}}$ that reflects semantic comparability rather than syntactic order.

Semantic operators have the same semantics as their relational algebra counterparts, with the only difference being that the data transformation/predicate (which are type-checked black boxes to relational algebra) are implemented in LLM rather than traditional programming languages. As a result, transformation rules defined for conventional relational algebra (e.g., selection push-down, projection composition, duplicate elimination propagation) are applicable to semantic operators as well. That is, if a rule $e_{1}\equiv e_{2}$ holds in the conventional setting, the corresponding semantic rule $e_{1}^{\textit{sem}}\equiv^{\textit{sem}}e_{2}^{\textit{sem}}$ can be applied under the appropriate semantic equivalence.

By grounding semantic processing in a formal algebra compatible with SQL’s extended semantics, SABER serves as a bridge between the structured and unstructured data processing paradigms. This enables systematic integration of LLM-powered semantic transformations into the relational model and paves the way for principled optimization, hybrid reasoning, and formal semantics in next-generation data systems.

3.2. Comparison of SABER and Existing SDPS

Grounded in the SABER framework introduced above, we systematically analyze three representative SDPSs—LOTUS Patel et al. (2025), DocETL Shankar et al. (2025), and Palimpzest Liu et al. (2025)—to assess their operational coverage. These systems exemplify cutting-edge approaches to LLM-integrated document analysis, each offering different abstractions and pipelines for semantic data manipulation.

We evaluate each system in terms of its support for SABER semantic operators (Table 2). We categorize the operators into Basic, Compound, and Extended as Table 1, and annotate support via documented APIs and system behavior. Table 2 reveals both commonalities and divergences among the three systems:

• •

All three systems support semantic selection ($\sigma^{\textit{sem}}$) and projection ($\pi^{\textit{sem}}$), reflecting their core role in LLM-driven filtering and transformation.

• •

Semantic join ($\Join^{\textit{sem}}$)111We only consider equi-join for $\Join^{\textit{sem}}$ for now and leave general $\theta$ join for future work. is supported in LOTUS and DocETL, but not in Palimpzest, highlighting divergence in pipeline composability.

• •

Extended operators such as grouping ($\gamma^{\textit{sem}}$), aggregation ($\xi^{\textit{sem}}$), deduplication ($\delta^{\textit{sem}}$), and sorting ($\tau^{\textit{sem}}$) are variably supported. Palimpzest offers only partial aggregation, whereas LOTUS and DocETL provide richer operator sets.

• •

Critically, none of the systems supports semantic difference ($-^{\textit{sem}}$) or intersection ($\cap^{\textit{sem}}$) directly, making it challenging to construct these operators. For instance, semantic difference cannot be expressed in these systems. For $\cap^{\textit{sem}}$, it is not natively supported by any of the three SDPSs – it can only be composed through a combination of $\pi^{\textit{sem}}$ and $\Join^{\textit{sem}}$: all attributes are first projected into a single attribute using $\pi^{\textit{sem}}$, after which applying $\Join^{\textit{sem}}$ yields a result that is semantically equivalent to $\cap^{\textit{sem}}$. These omissions are significant, as both operations are essential for capturing exclusion and overlapping patterns in comparative and conditional analyses.

SABER thus serves not only as a blueprint for identifying such gaps but also as a guide for actionable system evolution. By formalizing semantic operator semantics within an algebraic framework, SDPSs can achieve the same advantages that SQL systems have long leveraged: composability, rewrite rules, and query plan optimizations grounded in well-defined operator semantics.

4. SQL-Based Implementation of SABER

4.1. System Architecture and Workflow

We implement the Semantic Algebra Based on Extended Relational algebra (SABER) through SQL-accessible UDF-style interfaces that integrate semantic reasoning into structured queries. Our architecture separates relational execution from semantic evaluation, yet keeps both interoperable under a unified SQL front-end.

Internally, semantic operations are triggered not through SQL parsing or logical plan transformations—as is standard in classical relational engines—but through pattern matching against SQL strings using regular expressions. This pragmatic approach avoids invasive changes to the SQL parser and enables rapid deployment in existing systems. Each semantic operator invocation (e.g., SEM_JOIN(...)) is identified, parsed, and dispatched to dedicated runtime handlers that implement the corresponding SABER semantics.

The system follows a three-stage pipeline:

1. (1)

SQL String Pattern Matching: The input SQL is scanned using regex patterns to identify and extract semantic UDF invocations and their arguments. 2. (2)

Semantic Execution: For each matched operator, the system loads the referenced data (e.g., from tables or subqueries), applies the appropriate LLM-backed transformation (e.g., prompt-based projection), and materializes the output as an intermediate table or dataframe. 3. (3)

Hybrid Reassembly: The modified SQL query is rewritten to substitute semantic calls with references to the materialized outputs, enabling standard relational engines to continue processing.

The following SABER query exemplifies this pipeline in action. It answers the natural language question: “Among products, what is the most expensive apple-related one?” Here, the SEM_WHERE clause triggers semantic execution, where product names are semantically filtered based on their relation to “apple”:

⬇

SELECT name, price

FROM products

WHERE SEM_WHERE(’{name} is related to apple’, ’lotus’)

ORDER BY price DESC

LIMIT 1;

We implement SABER on top of three existing SDPSs rather than building a new system from scratch. As these SDPSs do not support semantic difference and intersection, we implement them using embedding-based similarity. This approach allows us to benefit from existing query optimization while showcasing the flexibility of our design. The architecture remains modular and non-intrusive: it isolates the semantic runtime and supports hybrid pipeline execution without requiring changes to SQL parsers or query optimizers, leaving deeper integration and optimization of custom semantics as directions for future work.

4.2. Semantic SQL UDF Syntax

Table 1 shows our UDF-style syntax for invoking SABER operators. Each semantic operator is denoted with a superscript sem and implemented as a standalone Python function internally matched and executed. Optional arguments such as prompts or system templates allow flexible interaction with LLM-based semantics.

4.3. Composability and Query Expressiveness

The regex-based operator extraction mechanism allows SABER UDFs to interleave seamlessly with classical SQL clauses, enabling hybrid queries that operate over both relational tables and LLM-interpreted document structures. The system supports modularity by encapsulating each semantic UDF as a self-contained logical transformation grounded in SABER semantics. It also offers flexibility through prompt and template parameters that dynamically steer semantic behavior, encouraging re-usability and experimentation. Despite leveraging LLMs, the UDFs preserve SQL’s declarative nature by abstracting away model-specific operations.

Crucially, the design maintains algebraic closure: the outputs of semantic UDFs are relational tables that remain compatible with downstream SQL operators. This paves the way for future extensions, including cost-based planning that spans semantic and classical operators, intermediate materialization strategies using vector caches or partial execution, and formal provenance tracking of semantically transformed data.

Overall, this implementation bridges relational and semantic paradigms through a pragmatic SQL-first interface, laying the foundation for fully integrated hybrid query engines.

5. Experimental Results

We evaluate SABER’s expressiveness and utility by executing a semantically enriched SQL query over a real dataset using three representative SDPS backends: LOTUS, DocETL, and Palimpzest. Although these systems interface with LLMs through distinct modalities, none supports algebraically composable semantics. SABER addresses this limitation by embedding declarative, operator-based semantic constructs directly into SQL.

5.1. Task and Data

This experiment is driven by the following natural-language query:

What are the top 5 rated movies about personal resilience that were directed by directors who overcame significant personal challenges?

We construct a normalized semantic database by integrating IMDb metadata from the official IMDb non-commercial dataset222https://developer.imdb.com/non-commercial-datasets/ and the Cinemagoer (IMDbPY) library333https://github.com/cinemagoer/cinemagoer. The integration process begins by extracting mappings between movies and their directors from the title.crew.tsv.gz file. We then retrieve the top 250 movies via the IMDbPY API, collecting metadata such as title, year, rating, and plot. Each movie is linked to its primary director to ensure relational uniqueness. Biographical information for each director—including summaries and personal histories—is also fetched via IMDbPY. The resulting schema consists of two relational tables: movies, which contains film-level metadata (e.g., tconst, title, rating, plot), and directors, which includes director-specific contextual information (e.g., nmconst, name, biography). For instance, the entry for The Shawshank Redemption (rated 9.3) is linked to director Frank Darabont, whose biography includes his experiences as a refugee and early writing struggles.

We issue the SABER query shown in Figure 1. The SABER query combines semantic projection ($\pi^{\textit{sem}}$) and selection ($\sigma^{\textit{sem}}$) operators in a unified execution plan:

• •

$\pi^{\textit{sem}}$ (SEM_SELECT) summarizes directors’ biography in one sentence.

• •

$\sigma^{\textit{sem}}$ (SEM_WHERE) filters to include only directors who overcame significant personal challenges.

5.2. SABER Query Rewriting

Our system can rewrite the unified query for each of the three backends, which instantiates these operators with its own LLM prompt. Figure 2 shows the rewritten SQL queries.

5.3. System Comparison and Discussion

Table 3 shows the results from each backend. While each system employs its own LLM prompting schema, SABER abstracts these differences and ensures consistent semantic interpretation.

The results demonstrate SABER’s capacity to encapsulate LLM-driven transformations within declarative algebra, enabling structured reasoning over descriptive fields and ensuring portable semantic intent across diverse backends. This unified SQL paradigm supports systematic comparison of semantic query implementations and lays the groundwork for extensible operator-based semantics in SDPS architectures.

6. Conclusion and Future Work

We have introduced Semantic Algebra Based on Extended Relational algebra (SABER), a principled algebraic framework that integrates semantic processing into SQL-based data systems. SABER extends classical relational algebra with LLM-backed semantic counterparts, supporting semantic selection, projection, difference, intersection, join, group-by, aggregation, deduplication, and sorting. By embedding these operators as user-defined SQL functions, SABER preserves SQL’s declarative nature while substantially enhancing its expressiveness over unstructured and semi-structured data.

SABER’s algebraic operators unify and expose existing semantic functionalities from multiple systems—LOTUS, DocETL, and Palimpzest—under a common relational abstraction. Our SQL-based interface enables these operators to be invoked as UDFs, supporting hybrid pipelines that seamlessly integrate structured querying with LLM-driven semantics. Experiments across these systems demonstrate SABER’s portability, compositionality, and expressive power.

Looking ahead, several promising directions arise:

• •

Formal Semantics for LLM Operators. While SABER defines operator-level behavior algebraically, the underlying LLM responses—such as prompt interpretation and similarity scoring—lack formal guarantees. Developing probabilistic or approximate models of these behaviors is an important direction for future work.

• •

Native Integration with Query Engines. The current prototype relies on regex-based UDF dispatch. Extending SQL parsers and query planners to natively support SABER semantics would enable deeper optimization and execution efficiency.

• •

Semantic Query Optimization. SABER presently lacks cost-based reasoning and semantic-aware plan rewriting. Future work will explore integrating semantic operators into logical and physical query optimizers to support scalable execution.

We view SABER as a foundational step toward a unified, declarative framework for semantic data processing. Future efforts will investigate hybrid optimization strategies, formal verification of semantic operator behavior, and principled extensions to additional modalities such as vision and multi-modal tables.