On the Implementations of the BiTemporal RDF Model: An Experimental Approach

Abstract

The BiTemporal RDF (BiTRDF) model extends the standard RDF data model by integrating both valid time and transaction time, thus enabling the representation and querying of dynamic and historical knowledge. While the theoretical foundations of BiTRDF have been established, practical implementation strategies have not yet been systematically studied. This paper bridges this gap by exploring six alternative approaches to implementing BiTRDF, combining object-oriented programming and database-oriented designs using Python and PostgreSQL. We evaluate these approaches using six synthetic datasets ranging from 0.5 million to 16 million bitemporal triples. The evaluation focuses on memory consumption, data-loading time, and query performance as data load increases. The results show that all approaches perform comparably when the knowledge store fits in memory. As the dataset size grows beyond available RAM, database-oriented implementations achieve substantially better loading and query performance, while object-oriented implementations offer greater flexibility and extensibility. These findings demonstrate the feasibility of implementing BiTRDF using existing technologies and provide practical guidance for selecting appropriate implementation strategies based on data size, performance requirements, and extensibility needs.

1. Introduction

The Internet has evolved beyond a platform for communication, transactions, and cloud storage. It is now a large and continuously expanding knowledge repository, where both humans and machines create, share, and analyze information. The Semantic Web was proposed to enable machine-understandable data and automated reasoning through the Semantic Web Layer Cake framework [1]. At the core of this framework lies the Resource Description Framework (RDF), which provides a standard model for representing knowledge as triples of the form $\langle subject,predicate,object\rangle$.

Despite its simplicity and widespread adoption, standard RDF is limited to representing binary relationships. Modeling more complex n-ary relationships often requires reification or additional extensions, which increase modeling complexity and may introduce performance overhead. These limitations become more pronounced when RDF is used to represent dynamic and evolving knowledge.

Temporal information is a fundamental aspect of many real-world applications, including legal records, financial systems, scientific data management, and historical knowledge bases. Temporal data can generally be classified into two types: valid time, which indicates when a fact holds in the real world, and transaction time, which records when that fact is stored, updated, or deleted in a data store. Temporal relational databases emphasize the importance of managing both dimensions of time to support auditing, historical queries, and data consistency.

Similarly, there is a growing need to support temporal semantics in RDF and RDF Schema. Temporal RDF extensions aim to capture the evolution of knowledge over time and enable historical reasoning. However, many existing approaches treat time as an attribute, rely heavily on reification, or support only a single temporal dimension. As a result, these models often suffer from increased structural complexity, limited extensibility, or unclear implementation strategies.

The BiTemporal RDF model (BiTRDF) addresses these challenges by uniformly extending RDF with both valid time and transaction time. In this model, time is treated as a reference, embedding temporal semantics directly into RDF resources rather than appending timestamps as auxiliary attributes. This design avoids the complexity of reification-based approaches for managing temporal knowledge [2,3]. In BiTRDF, all resources and relationships are inherently bitemporal, leading to cleaner semantics and stronger temporal consistency. While prior work has established the theoretical foundation of BiTRDF, practical questions remain open. In particular, it is unclear how BiTRDF can be efficiently implemented, stored, queried, and scaled using existing programming languages and data management technologies.

The goal of this paper is to bridge this gap between theory and practice. We explore multiple implementation strategies for BiTRDF by combining object-oriented programming techniques with database-oriented designs. Rather than proposing a single implementation, we investigate and compare six alternative approaches, each representing a different trade-off among flexibility, performance, memory consumption, and scalability. Through systematic experimentation, we evaluate these approaches using datasets of varying sizes and analyze their behavior under common operations such as data loading and querying.

To achieve the above goals, the following three considerations guided our study:

• Mapping BiTRDF effectively to the relational and object-oriented structures while maintaining temporal coherence.
• The performance trade-offs between memory-centric and storage-centric designs.
• Scaling various implementations when dataset sizes exceed physical memory.

The remainder of this paper is organized as follows. Section 2 reviews related work on temporal RDF extensions and bitemporal data management. Section 3 summarizes the key definitions and principles of the BiTemporal RDF model. Section 4 presents the design and implementation of the six BiTRDF approaches, including a running example and query illustrations. Section 5 describes the experimental setup and evaluation methodology, followed by a comparative analysis of performance results and a discussion of the findings in Section 6. Finally, Section 7 concludes the paper with recommendations and directions for future work.

Additional supporting details are provided in the Appendices: Appendix A details the input–process–output (IPO) workflow; Appendix B, Appendix C, Appendix D, Appendix E, Appendix F and Appendix G illustrate the running example as implemented across each of the six approaches; Appendix H provides comprehensive bitemporal query examples; and Appendix I contains the detailed data tables from the performance experiments.

2. Related Work

Although temporal RDF has been extensively studied, most research focuses on representation rather than efficient implementation. A common organization is where temporal information is attached in the RDF model: Graph-level embedding, triple-level embedding, and resource-level embedding [4]. Graph-level approaches often use named graphs to associate a shared temporal context with a set of triples [5]. Triple-level approaches attach time to individual statements, frequently through explicit or implicit reification, which can increase the number of triples and complicate query processing [6,7]. Resource-level approaches temporalize RDF resources (subjects, predicates, and/or objects), for example, by temporalizing predicates (e.g., Singleton Property) or introducing entity versions (e.g., 4D Fluents) [8,9].

Instead of proposing a new encoding, this study implements and evaluates BiTRDF, a resource-level bitemporal model that assigns both time dimensions uniformly to RDF resources [2,3]. We therefore position our related work around (i) RDF store engineering and indexing, (ii) executable support for temporal/versioned RDF over existing engines, and (iii) bitemporal database foundations that inform implementation design.

2.1. RDF Store Implementations and Indexing for SPARQL Workloads

RDF query performance is primarily determined by physical design, including storage layout, indexing, and join processing. Sesame exemplifies a storage-independent architecture that separates query evaluation from the storage backend, enabling alternative backend realizations under the same query layer [10]. Surveys of RDF stores and SPARQL engines consolidate these implementation choices and emphasize that physical design is often the dominant performance factor [11].

Triple-pattern queries in RDF benefit from having indexes on multiple permutations of subject, predicate, and object. Hexastore supports this with sextuple indexing to speed up different access patterns [12]. RDF-3X likewise shows that careful index design, together with efficient query processing, can scale SPARQL evaluation to large datasets [13]. This motivates treating index and access-path design as key variables in our BiTRDF implementation study.

2.2. Executable Temporal and Versioned RDF over Existing RDF Stores

A key practical question is whether existing RDF standards can handle temporal semantics. Named graphs provide a standard way to attach metadata, such as provenance and temporal context, to sets of triples [5]. Using this idea, research on RDF archives typically encodes versions in the data and translates versioned queries into standard SPARQL systems. Cuevas and Hogan compare several named-graph encodings for RDF archives and study how these choices affect query cost [14]. Ostrich proposed storage and indexing methods for random-access versioned querying and analyzing the trade-offs among data loading, storage overhead, and query performance [15]. Overall, these studies show that time-aware RDF support often depends less on the abstract model and more on how the data is stored and how queries are executed.

2.3. Bitemporal Database for Implementing BiTRDF

BiTRDF is designed in the spirit of bitemporal databases. It supports both valid time and transaction time to enable operators analogous to temporal as-of and change-oriented queries. TSQL2 consolidates core temporal database concepts and standardizes temporal operators that later systems often adopt [16]. When these ideas are brought into RDF, many existing approaches either treat time as an attribute or add extra structural layers (e.g., reification or mapping constructs). SPARQL and its extensions, such as C-SPARQL, provide mechanisms for querying RDF data with temporal constraints, typically by evaluating time conditions at query execution. However, these approaches generally treat temporal information as annotations or external attributes and do not enforce temporal consistency at the data model level. In contrast, the BiTRDF model embeds valid-time and transaction-time semantics directly into RDF resources and relationships, ensuring that temporal coherence is maintained as an intrinsic property of the data.

While several alternative temporal RDF models have been proposed, no established bitemporal RDF prototypes currently exist for side-by-side performance benchmarking [4]. The implementations presented in this work, therefore, focus on realizing this resource-level bitemporal representation, providing a storage and indexing foundation that can support temporal querying in a more consistent manner. We compare and evaluate trade-offs in storage organization, indexing, and query execution, based on established RDF store and archiving insights [11,12,13,15].

3. BiTRDF Model Overview

This section presents a concise overview of the BiTemporal RDF (BiTRDF) model [2,3], which provides the theoretical foundation for the implementation strategies examined later in this paper. This section introduces the key concepts and constraints that directly influence system design and implementation.

BiTRDF extends the standard RDF data model by integrating two temporal dimensions into all RDF resources. The central design principle of BiTRDF is that time is treated as a reference rather than an attribute. Instead of annotating facts with timestamps, temporal semantics are embedded directly into the structure of RDF resources and relationships. This design leads to a cleaner model and enables consistent reasoning about both real-world validity and system history.

BiTRDF introduces two temporal dimensions:

• Valid Time (VT), which represents the period during which a fact is true in the real world;
• Transaction Time (TT), which represents the period during which a fact is stored, known, or maintained in the knowledge base.

These dimensions enable BiTRDF to capture the evolution of both real-world facts and system knowledge, in a way that is conceptually aligned with bitemporal relational databases.

3.1. Bitemporal Resources and Triples

In BiTRDF, all RDF components—subjects, predicates, and objects—are inherently bitemporal. Each resource carries both a valid-time interval and a transaction-time interval, representing its real-world existence and its recorded history within the system.

• Bitemporal Resource ($R^{bit}$): A standard RDF resource r is extended with a valid-time interval ($vt$) and a transaction-time interval ($tt$). Formally, a bitemporal resource is defined as:

  $$R^{bit}=\{r•vt•tt\mid r\in R\wedge vt\in V{T}_I\wedge tt\in T{T}_I\},$$

  (1)

  where R denotes the set of RDF resources, and $V{T}_I$ and $T{T}_I$ denote the sets of valid-time and transaction-time intervals. Intuitively, $vt$ specifies when a resource exists or holds in the real world, while $tt$ specifies when it is known or maintained by the system.
• Bitemporal Triple ($TRIPL{E}^{bit}$): A bitemporal triple preserves the standard RDF structure while enforcing temporal consistency across all its components:

  $$\begin{array}{c}TRIPL{E}^{bit}=\{<s^{bit}{p}^{bit}{o}^{bit}>\mid s^{bit}\in (I^{bit}\cup B^{bit})\wedge p^{bit}\in P^{bit}\wedge \\ o^{bit}\in (I^{bit}\cup B^{bit}\cup L^{bit})\wedge \\ p^{bit}.vt\ne \varnothing \wedge p^{bit}.tt\ne \varnothing \wedge \\ p^{bit}.tt\subseteq (s^{bit}.tt\cap o^{bit}.tt)\wedge p^{bit}.vt\subseteq (s^{bit}.vt\cap o^{bit}.vt)\}\end{array}$$

  (2)

  where $I^{bit}$, $B^{bit}$, $L^{bit}$, and $P^{bit}$ denote the sets of bitemporal IRIs, blank nodes, literals, and predicates, respectively.

This definition imposes a key constraint: a relationship can exist only when its subject and object coexist within the same valid-time and transaction-time intervals. This constraint is essential for maintaining temporal coherence and has direct implications for how BiTRDF data structures are stored and validated in practice.

3.2. Temporal Coherence and Core Operators

A central strength of the BiTRDF model is its built-in support for temporal coherence. BiTRDF ensures that all facts in a knowledge base are temporally consistent through an integrity rule and two core operators. These operators allow the system to reconstruct past system states and historical views of the real world.

• BiTemporal Triple Integrity: For a bitemporal predicate $p^{bit}$ to be valid, its subject $s^{bit}$ and object $o^{bit}$ must coexist throughout the temporal span of the predicate:

  $$p^{bit}.tt\subseteq (s^{bit}.tt\cap o^{bit}.tt)\wedge p^{bit}.vt\subseteq (s^{bit}.vt\cap o^{bit}.vt)$$

  (3)
  This rule prevents temporal contradictions, such as asserting relationships between entities that did not exist at the same time, and ensures that the knowledge base always represents a logically possible world.
• Rollback Operator (${\delta }_{t_I}$): The rollback operator reconstructs the state of the knowledge base at a past transaction time $t_I$:

  $${\delta }_{t_I}\left(KB\right)=\{f\mid f.tt\subseteq t_I\}$$

  (4)
  This operator supports queries such as “What did the system know at time $t_I$?” and provides a formal mechanism for restoring historical system states.
• Time Slice Operator ($\mathbb{TS}$): The time slice operator retrieves facts that were valid in the real world during a given valid-time interval $i_I$, as recorded at transaction time $t_I$:

  $$\mathbb{TS}(KB,i_I,t_I)=\{f\mid f.vt=i_I\wedge f.tt\subseteq t_I\}$$

  (5)
  This operator enables reconstruction of historical world states and supports queries such as “What was true during this period, based on what was known at that time?”

The complete formal semantics and proofs of these operators are provided in [2,3]. Together, the BiTRDF model and its core operators establish a rigorous and implementation-oriented foundation for managing bitemporal knowledge in RDF-based systems. In the next section, we build on this foundation to present concrete design choices and implementation strategies for BiTRDF.

4. Implementation Design

An RDF store is responsible for persistently storing, managing, and querying RDF graphs. Since BiTRDF extends the standard RDF model with bitemporal semantics, its implementation must support the creation, storage, retrieval, and querying of bitemporal resources and bitemporal triples, while preserving temporal coherence and acceptable query performance. Building upon the formal definitions of $R^{bit}$ and $TRIPL{E}^{bit}$ introduced in Section 3, we now translate these theoretical constraints, particularly the Triple Integrity Rule, into concrete data structures and logic.

This section presents two implementation strategies for BiTRDF. The first strategy adopts a relational database perspective using PostgreSQL and emphasizes persistence, indexing, and scalability. The second strategy follows an object-oriented programming (OOP) design implemented in Python (Version:3.8.8) and emphasizes flexibility, modularity, and in-memory performance. These approaches demonstrate trade-offs among performance, memory usage, extensibility, and system complexity. Particular attention is given to indexing and search mechanisms, since query processing is a central requirement of temporal knowledge stores.

4.1. Relational Database Implementation Using PostgreSQL

Relational database systems provide a mature and robust foundation for managing structured and persistent data. While native RDF stores exist, many systems cannot efficiently support complex interval-based logic [2]. In particular, most RDF engines are designed around fixed triple-based schemas and typically support temporal information through reification, named graphs, or annotation patterns, which introduce additional structural overhead and complicate query processing. PostgreSQL was specifically chosen due to its support of custom composite data types and GiST indexing, which are better suited for bitemporal interval arithmetic than standard triple-store indexing [17]. These features enable bitemporal attributes to be modeled directly and evaluated efficiently using native database operations, rather than being encoded indirectly within RDF structures. Furthermore, this choice enables precise control over storage layout and indexing strategies, which is essential for systematically evaluating the performance trade-offs of different BiTRDF implementations.

The database schema follows established principles of temporal database design [18] and maps BiTRDF concepts directly to relational constructs. The design consists of one composite data type and three core tables.

Bitemporal Resource Data Type: PostgreSQL allows users to define custom composite data types using the CREATE TYPE statement. To represent bitemporal resources, we define a composite type named BiTemporalResource, which encapsulates both valid-time and transaction-time intervals:

The Name field represents a standard RDF resource identifier, while the remaining fields capture its valid-time and transaction-time intervals. This data type directly corresponds to the BiTRDF resource model and is reused across tables to ensure consistency and simplify temporal query processing.

Bitemporal Triple Table: Bitemporal triples are stored in a dedicated table named BiTemporalTripleTable:

Each row represents a single bitemporal triple. The Id column uniquely identifies a triple and supports indexing and future extensions. Subjects and objects are stored as resource identifiers, while predicates are stored using the BiTemporalResource type to capture their temporal semantics. This design preserves the temporal integrity of relationships while avoiding unnecessary duplication of entity-level temporal data.

Entity and Predicate Tables: To manage temporal metadata for entities and predicates independently, two additional tables are defined:

These tables store the temporal lifespans of subjects, objects, and predicates. Primary key constraints enforce uniqueness and allow efficient lookup of bitemporal resources during query execution and integrity validation.

Indexing and Query Efficiency: Efficient query processing is critical for RDF stores. PostgreSQL automatically creates B-tree indexes for primary keys, enabling fast retrieval of entities and predicates. Additional indexes are defined on the triple table to support common RDF access patterns:

These indexes correspond to standard subject–predicate–object permutations and allow queries constrained by any triple component to be evaluated efficiently. B-tree indexes provide logarithmic-time complexity and support both exact matching and range-based temporal conditions.

4.2. Object-Oriented Implementation Using Python

In addition to the database-oriented approach, BiTRDF can be implemented using an object-oriented design in Python. This approach emphasizes modularity, extensibility, and ease of experimentation, making it well-suited for prototyping and in-memory analytics.

Input Processing and Parsing: The implementation reads BiTRDF graphs expressed in Turtle syntax [19]. Each input line represents a bitemporal triple. The input processor parses the file sequentially and decomposes each line into RDF resources, temporal intervals, and structural relationships. For simplicity, input files are assumed to be syntactically correct.

Construction of Bitemporal Components: The object-oriented design decomposes BiTRDF construction into several modular components:

• Resource Constructor, which converts IRIs, literals, or blank nodes into RDF resource objects;
• Temporal Data Constructor, which extracts temporal annotations and constructs valid-time and transaction-time intervals;
• Bitemporal Resource Constructor, which combines RDF resources with temporal intervals;
• Bitemporal Triple Constructor, which assembles bitemporal subjects, predicates, and objects while enforcing BiTemporal Triple Integrity.

This modular structure makes it straightforward to extend the system with additional dimensions, such as confidence values or spatial attributes. The overall input–process–output workflow is summarized in

Table A1. IPO of Processors, Constructors, Output, and Serialization.

Function	Input	Process	Output
Input	The path to a text file which contains a BiTRDF graph written in Turtle syntax [19]	Process a BiTRDF graph written in Turtle syntax: (1) read the text file line by line; (2) call the resource constructor, temporal data constructor, bitemporal resource constructor, bitemporal triple constructor to break down each line to basic elements and to constructor a bitemporal triple from each line	A BiTRDF graph
Resource	A string that represents an IRI, a literal, or a blank node	Construct a standard RDF resource	A standard RDF resource
Temporal data	A string that represent a time interval which starts with “[”, has a lower bound $t_s$ and a upper bound $t_e$, and ends with “]” if $t_e$ is $now$ or “)” if $t_e$ is not $now$	Construct a time interval	A time interval as $[t_s,now]$ or $[t_s,t_e)$
BiTemporal Resource	A standard RDF resource, r, a valid time interval, and a transaction time interval	Concatenate the resource component, valid time component, and transaction time component together to create a bitemporal resource	A bitemporal resource $r^{bit}$
BiTemporal Triple	Three bitemporal resources, $s^{bit}$, $p^{bit}$, and $o^{bit}$	Place the three resources in the corresponding positions of a triple as the subject, the predicate, and the object	A bitemporal triple, $<s^{bit}{p}^{bit}{o}^{bit}>$
Query	A BiTRDF knowledge store, a set of arguments	Process the arguments against the BiTRDF knowledge store	Bitemporal resources or bitemporal triples that satisfy the query
Output	A BiTRDF graph	Serialize the BiTRDF graph to Turtle syntax [19]	A text file that contains a BiTRDF graph written in Turtle syntax [19]

.

Query Processing and Serialization: A unified query processor supports pattern-based searches over bitemporal triples. Queries may constrain subjects, predicates, objects, valid time, transaction time, or combinations of these dimensions. The processor is designed to be generic and parameter-driven, enabling flexible query formulation.

The system also supports serialization, allowing stored knowledge to be exported back into Turtle format. This ensures consistency between input and output representations and supports interoperability with other RDF tools. The BiTRDF model is defined at the conceptual level and is independent of any specific RDF serialization format. While Turtle is used in our implementation for readability, the underlying bitemporal semantics can be preserved in alternative formats such as N-Triples or JSON-LD, provided that valid-time and transaction-time intervals are explicitly encoded as part of the resource representation. In this implementation, temporal intervals are represented as structured literal values, which can be consistently serialized across formats. As long as the temporal components and integrity constraints of BiTRDF are maintained, the choice of serialization does not affect the correctness of the model.

In-Memory Indexing with Dictionaries: To support fast in-memory queries, the OOP implementation uses Python dictionaries as indexing structures. Dictionaries provide hash-based access with constant-time lookup on average. Three nested dictionary indexes are maintained:

• Subject-indexed: $\{s^{bit}:\{p^{bit}:\left\{o^{bit}\right\}\}\}$
• Predicate-indexed: $\{p^{bit}:\{o^{bit}:\left\{s^{bit}\right\}\}\}$
• Object-indexed: $\{o^{bit}:\{s^{bit}:\left\{p^{bit}\right\}\}\}$

This design enables efficient queries but increases memory usage and update overhead because all indexes must remain synchronized. This reflects a common space–time trade-off in knowledge store design.

4.3. Summary of Design Trade-Offs

The PostgreSQL-based implementation emphasizes persistence, scalability, and mature indexing support, making it suitable for large and long-lived BiTRDF knowledge stores. In contrast, the object-oriented implementation emphasizes flexibility, extensibility, and fast in-memory access, making it well-suited for experimentation and smaller-scale workloads. These complementary designs form the basis for the empirical evaluation presented in the next section.

5. Experiments

The goals of the experimental evaluation are threefold: (1) to demonstrate that BiTRDF knowledge stores can be correctly constructed and queried; (2) to validate the correctness of bitemporal querying under valid-time and transaction-time constraints; (3) to compare the performance of different implementation alternatives in terms of memory usage, loading time, and query efficiency.

5.1. Triple Stores Available

We examined a wide range of existing triple stores, including RDF Benchmarks [20], Oracle Spatial and Graph 12c [21,22], AllegroGraph [23], Stardog [24,25,26], OpenLink Virtuoso [27,28,29], GraphDB [30,31], BlazeGraph [32], Jena TDB [33,34,35], RDF4Led [36], RDFox [37], RDFLib [38], 3Store [39], 4Store [40], OpenRDF Sesame [41], Rya [42]. While these triple stores support the standard RDF model and often integrate SQL capabilities, extending their resources to include temporal information remains difficult. While these existing solutions satisfy some of the expectations, they are missing the crucial need of extensibility to include temporal knowledge.

5.2. Implementing Alternatives

Based on the design premises described in Section 4, we developed a software package named BiTRDFLib that includes six implementation alternatives. These alternatives differ in how BiTRDF elements are represented and stored, allowing us to explore trade-offs between flexibility, performance, and scalability. The alternatives are grouped into two categories: object-oriented implementations and storage-oriented implementations.

The object-oriented (OOP) implementations explicitly construct BiTRDF elements, including temporal intervals, bitemporal resources, and bitemporal triples. All OOP alternatives share the same parsing, construction, querying, and serialization logic, and differ only in their underlying storage structures.

• OOP + Dictionary: Uses Python dictionaries with hash-based indexing. Three dictionaries are maintained to optimize subject-, predicate-, and object-based queries.
• OOP + DataFrame: Uses Pandas DataFrames to store bitemporal triples, entities, and predicates in tabular form, leveraging built-in indexing and filtering operations.
• OOP + List: Stores each bitemporal triple as a list element without reorganization. This approach minimizes structural overhead but does not optimize query performance.

The storage-oriented implementations prioritize simplicity and performance by directly storing atomic values rather than object instances. These approaches bypass the construction of BiTRDF elements and instead focus on efficient value-level storage.

• Database + PostgreSQL: Uses a relational schema with composite bitemporal data types, as described in Section 4, and persists data in a PostgreSQL database.
• Database + Dictionary: Stores each bitemporal triple as 15 atomic values corresponding to the three bitemporal resources and their temporal intervals, using a Python dictionary.
• Database + List: Stores each bitemporal triple as a fixed-size list of 15 elements, enabling direct index-based access with minimal overhead.

5.3. Running Example BiTRDF Knowledge Store

For demonstration purposes, we used a running example BiTRDF knowledge store:

5.4. Object-Oriented Programming Implementation

The three OOP-based alternatives differ only in storage, sharing all other processing logic. We explain the different storage processes of each alternative separately in detail in this section.

OOP + Dictionary: In this alternative, we adopted the dictionary data structure in Python. The dictionary data structure uses a {key:value} pair to organize data. Using hashing, the access time for the value associated with a key is O(1). To maximize the searching time for queries, three dictionaries are created to store the BiTRDF graph in different ways. Once a bitemporal triple is constructed, its subject, predicate, and object components will be saved as:

The running example stored in dictionaries is depicted in Appendix B.

To speed up the response time for queries, we store the same bitemporal triple in three dictionaries that are optimized for the subject, the predicate, or the object of triples. If a query is about a particular component of bitemporal triples, the corresponding dictionary will be called for the query. If the AS OF clause is not specified, the default $now$ will be used.

OOP + DataFrame: In this alternative, we adopted the DataFrame structure of the Pandas package. Pandas is a widely used package to deal with tabular data, and DataFrame is well known for its fast and efficient data manipulation with integrated indexing. When a bitemporal triple is constructed, it will be stored in three dataframes.

The running example stored in dataframes is depicted in Appendix C.

OOP + List: In this alternative, we adopted the list data structure in Python. The list is very basic but powerful. Once a bitemporal triple is constructed, it will be saved directly as an element in a list without any modification. Thus, if the BiTRDFLib package needs extensions, modifying the underlying structure of triples will not affect the storing and query processes. This alternative is included to provide a straightforward implementation for scenarios where rapid deployment is prioritized over efficiency.

The running example stored in a list is depicted in Appendix D.

5.5. Database Implementation

While OOP alternatives construct BiTRDF instances, database-oriented ones focus on retrieval of triples. Without the BiTRDF elements, alternatives in the database logic lack flexibility and extensibility in the OOP logic, but they can perform more efficiently both in loading and searching. We discuss the possible alternatives in detail in this section.

Database + PostgreSQL: In this alternative, we adopted a relational database. We created a PostgreSQL database, and used Pony, a Python package, to communicate between Python and PostgreSQL. The running example stored in a relational table is depicted in Appendix E.

Database + Dictionary: In this alternative, we adopted Python dictionary data structure as well. A bitemporal triple has 15 parts, respectively:

• $subject\_resource$, $subject\_v{t}_s$, $subject\_v{t}_e$, $subject\_t{t}_s$, $subject\_t{t}_e$,
• $predicate\_resource$, $predicate\_v{t}_s$, $predicate\_v{t}_e$, $predicate\_t{t}_s$, $predicate\_t{t}_e$,
• $object\_resource$, $object\_v{t}_s$, $object\_v{t}_e$, $object\_t{t}_s$, $object\_t{t}_e$

This storage structure is a direct mapping of the formal BiTemporal Resource definition. Since a single bitemporal resource consists of 5 components, and a triple consists of 3 bitemporal resources, the total storage requirement is 15 atomic values. Since each line in the text file represents a bitemporal triple, we retrieve and store these 15 values in a dictionary directly. The running example stored in a dictionary is depicted in Appendix F.

Database + List: In this alternative, we adopted the Python list data structure as well. As we discussed in the previous alternative, each bitemporal triple contains 15 parts. A list of size 15 can store the values of these parts. The running example stored in a list is depicted in Appendix G.

5.6. Query Examples

We evaluate three classes of queries:

• Structural queries, which filter by subject, predicate, or object;
• Valid-time queries, which retrieve facts valid at a specified time instant;
• Transaction-time queries, which reconstruct the knowledge store as of a given transaction time.

Representative query results are shown in

Table A2. Query Output: Select all subjects whose resource is “:Lu”.

Subject
:Lu[1,now][1,now]

,

Table A3. Query Output: Select all predicates whose resource is “:livesIn”.

Predicate
:livesIn[1,5)[1,5)
:livesIn[5,10)[5,10)
:livesIn[10,now][10,now]

,

Table A4. Query Output: Select all objects whose resource is “:NY”.

Predicate
:NY[0,now][0,now]

,

Table A5. Query Output: Select all bitemporal triples in the sample store.

Subject	Predicate	Object
:NJ[0,now][0,now]	bitrdf:type[0,now][0,now]	:state[0,now][0,now]
:NY[0,now][0,now]	bitrdf:type[0,now][0,now]	:state[0,now][0,now]
:CO[0,now][0,now]	bitrdf:type[0,now][0,now]	:state[0,now][0,now]
:NYC[0,now][0,now]	bitrdf:type[0,now][0,now]	:city[0,now][0,now]
:NYC[0,now][0,now]	:locatesAt[0,now][0,now]	:NY[0,now][0,now]
:CUNY[0,now][0,now]	bitrdf:type[0,now][0,now]	:Univ[0,now][0,now]
:CUNY[0,now][0,now]	:locatesAt[0,now][0,now]	:NY[0,now][0,now]
:CU[0,now][0,now]	bitrdf:type[0,now][0,now]	:Univ[0,now][0,now]
:CU[0,now][0,now]	:locatesAt[0,now][0,now]	:CO[0,now][0,now]
:Lu[1,now][1,now]	bitrdf:type[1,now][1,now]	:person[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[1,5)[1,5)	:NJ[0,now][0,now]
:Lu[1,now][1,now]	:studyAt[1,now][1,now]	:CUNY[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[5,10)[5,10)	:NY[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[10,now][10,now]	:CO[0,now][0,now]
:Lu[1,now][1,now]	:worksAt[10,now][10,now]	:CU[0,now][0,now]
:Lu[1,now][1,now]	:worksWith[10,now][10,now]	:Ab[1,now][1,now]
:Ab[1,now][1,now]	bitrdf:type[1,now][1,now]	:person[0,now][0,now]
:Ab[1,now][1,now]	:livesIn[5,10)[5,10)	:NJ[0,now][0,now]
:Ab[1,now][1,now]	:livesIn[10,now][10,now]	:NY[0,now][0,now]

,

Table A6. Query Output: Select all bitemporal triples whose subjects’ resource is “:Lu”.

Subject	Predicate	Object
:Lu[1,now][1,now]	bitrdf:type[1,now][1,now]	:person[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[1,5)[1,5)	:NJ[0,now][0,now]
:Lu[1,now][1,now]	:studyAt[1,now][1,now]	:CUNY[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[5,10)[5,10)	:NY[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[10,now][10,now]	:CO[0,now][0,now]
:Lu[1,now][1,now]	:worksAt[10,now][10,now]	:CU[0,now][0,now]
:Lu[1,now][1,now]	:worksWith[10,now][10,now]	:Ab[1,now][1,now]

,

Table A7. Query Output: Select all bitemporal triples whose predicates’ resource is “:livesIn”.

Subject	Predicate	Object
:Lu[1,now][1,now]	:livesIn[1,5)[1,5)	:NJ[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[5,10)[5,10)	:NY[0,now][0,now]
:Ab[1,now][1,now]	:livesIn[5,10)[5,10)	:NJ[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[10,now][10,now]	:CO[0,now][0,now]
:Ab[1,now][1,now]	:livesIn[10,now][10,now]	:NY[0,now][0,now]

,

Table A8. Query Output: Select all bitemporal triples whose objects’ resource is “:NY”.

Subject	Predicate	Object
:NYC[0,now][0,now]	:locatesAt[0,now][0,now]	:NY[0,now][0,now]
:CUNY[0,now][0,now]	:locatesAt[0,now][0,now]	:NY[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[5,10)[5,10)	:NY[0,now][0,now]
:Ab[1,now][1,now]	:livesIn[10,now][10,now]	:NY[0,now][0,now]

,

Table A9. Query Output: Select all bitemporal triples whose predicates’ resource is “:livesIn” and are valid at time 1.

Subject	Predicate	Object
:Lu[1,now][1,now]	:livesIn[1,5)[1,5)	:NJ[0,now][0,now]

,

Table A10. Query Output: Select all bitemporal triples whose predicates’ resource is “:livesIn” and are valid at time 5.

Subject	Predicate	Object
:Lu[1,now][1,now]	:livesIn[5,10)[5,10)	:NY[0,now][0,now]
:Ab[1,now][1,now]	:livesIn[5,10)[5,10)	:NJ[0,now][0,now]

,

Table A11. Query Output: Select all bitemporal triples whose predicates’ resource is “:livesIn” and are valid at time 10.

Subject	Predicate	Object
:Lu[1,now][1,now]	:livesIn[10,now][10,now]	:CO[0,now][0,now]
:Ab[1,now][1,now]	:livesIn[10,now][10,now]	:NY[0,now][0,now]

,

Table A12. Query Output: Select all bitemporal triples whose predicates’ resource is “:livesIn” as of time 10.

Subject	Predicate	Object
:Lu[1,now][1,now]	:livesIn[1,5)[1,5)	:NJ[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[5,10)[5,10)	:NY[0,now][0,now]
:Ab[1,now][1,now]	:livesIn[5,10)[5,10)	:NJ[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[10,now][10,now]	:CO[0,now][0,now]
:Ab[1,now][1,now]	:livesIn[10,now][10,now]	:NY[0,now][0,now]

and

Table A13. Query Output: Select all bitemporal triples whose predicates’ resource is “:livesIn” as of time 5.

Subject	Predicate	Object
:Lu[1,now][1,now]	:livesIn[1,5)[1,5)	:NJ[0,now][0,now]
:Lu[1,now][1,now]	:livesIn[5,10)[5,10)	:NY[0,now][0,now]
:Ab[1,now][1,now]	:livesIn[5,10)[5,10)	:NJ[0,now][0,now]

. These examples confirm that BiTRDF operators correctly enforce valid-time constraints and support rollback semantics.

5.7. Use-Case Scenario

The dataset is designed to simulate dynamic knowledge graphs with temporal evolution, where entities and relationships change over both real-world time (valid time) and system recording time (transaction time). Such scenarios commonly arise in domains including:

• Personnel and employment history tracking,
• Location and mobility data (e.g., individuals moving across regions),
• Organizational affiliations and institutional changes,
• Versioned knowledge bases and data auditing systems.

In this study, we use this temporal entity–relationship evolution scenario as an abstracted use case for domains such as personnel records, mobility tracking, and organizational history, where entities change locations and affiliations over time and those changes must be audited with respect to both valid time (when changes occur in the real world) and transaction time (when they are recorded). This conceptual scenario directly informs the design of our synthetic datasets, which encode similar patterns of evolving entities and relationships under both temporal dimensions, while allowing us to systematically control scale and temporal distributions for performance experiments. The running example in Section 5.3 (e.g., individuals living in different states over time and working at institutions) reflects a temporal entity-relationship evolution scenario, which serves as a conceptual grounding for the larger synthetic datasets.

5.8. Dataset Description

To evaluate performance and scalability, we generated six synthetic BiTRDF knowledge stores. The datasets are synthetically generated to systematically control:

• The number of bitemporal triples;
• The distribution of valid-time and transaction-time intervals;
• The independence of structural and temporal dimensions.

This design allows us to isolate the system-level performance characteristics (memory usage, loading time, and query efficiency) without confounding factors introduced by domain-specific data irregularities. While the data is synthetic, it preserves the structural and temporal properties of real-world temporal knowledge graphs, including overlapping temporal intervals, evolving relationships, and multi-version entity states. Building on this controlled design, the datasets are further structured to evaluate scalability across increasing data volumes. Specifically, we generated six knowledge stores of progressively larger sizes to simulate high-frequency bitemporal event scenarios, such as financial auditing or legal logging, where precise tracking of both valid time and transaction time is critical for data provenance. Each bitemporal triple is composed of three such resources. For example, the following are randomly generated bitemporal triples:

BiTRDF knowledge stores are created based the specified number of bitemporal triples. We started with a relatively small knowledge store, with only 500,000 triples, and ended with a relatively large knowledge store, with 16,000,000 triples. The number of triples was doubled for each triple store to evaluate the scaling of their performance. In particular, we would like to examine and compare the performance before and after the computation needs exceed the Random Access Memory (RAM) and the operating system has to swap between RAM and physical storage. We summarize the six BiTRDF knowledge stores in

Table 1. Summary of the six knowledge stores.

Name	Number of Bitemporal Triples	Size
D1	500,000	37 MB
D2	1,000,000	73 MB
D3	2,000,000	146 MB
D4	4,000,000	292 MB
D5	8,000,000	583 MB
D6	16,000,000	1170 MB

.

The chosen dataset design is particularly suitable for evaluating the BiTRDF model. First, it requires the simultaneous management of valid time (real-world changes) and transaction time (system-recorded history), which are the two core temporal dimensions of BiTRDF. Second, the generated data enforces temporal consistency across entities and relationships, reflecting the integrity constraints defined in the BiTRDF model (Section 3). Third, the dataset supports representative query patterns, including time-slice queries (e.g., “what was true at time t?”) and rollback queries (e.g., “what did the system know at time t?”), which are directly aligned with the BiTRDF operators. Therefore, the dataset provides a controlled yet representative environment for evaluating both the correctness and performance of BiTRDF implementations.

5.9. Testing Device Description

All experiments were conducted on a consumer-grade laptop with the configuration shown in

Table 2. Summary of the Testing Device.

Tech Specification	Value
Brand	Apple
Model	MacBook Pro, 13-inch, 2020
CPU	M1
Memory	16 GB
OS	macOS Monterey
Python	3.8.8

. This setup reflects a realistic deployment environment rather than a specialized server.

5.10. Evaluation Criteria

We measured performance using three standardized criteria: Memory Consumption, Loading Time, and Query Time.

Memory Consumption: BiTRDFLib first loads data into memory to construct and store a BiTRDF knowledge store. Memory consumption reflects the space efficiency of processing and storing a BiTRDF knowledge store. Memory consumption is measured using psutil, a cross-platform library for retrieving information on running processes and system utilization. This measurement compares the total memory usage before and after the execution of a function. It can also indicate when the RAM is not big enough to handle the needs: when the swap between RAM and physical storage happens, we can observe a small or even a negative memory consumption.

Loading Time: When comparing different implementations, loading time is part of overall performance. Because all data must be loaded into memory before query tasks can begin, the time required for loading directly impacts the efficiency of the system.

Query Time: In practice, search time is critical to the performance of the implementation, since searches are executed frequently by many users. Long response time is unacceptable for a satisfactory user experience. It is important for us to understand how each alternative performs in this criterion. It is also important to compare performance before and after the swap has happened, since it is directly associated with scalability. We used a simple query to find all triples whose subjects’ resource matches, for the evaluation.

The time used for loading and searching is measured using cProfile, a Python built-in module that provides statistics on the execution of a program. In order to obtain a more accurate result, we computed the mean of these quantitative values across 100 runs for each alternative. In addition to the total value of these three quantitative facts, we also calculated their per-million-triple values, as they are useful for evaluating scalability.

6. Results and Discussion

This section presents and analyzes the experimental results from three perspectives: memory consumption, loading time, and query time. The goal is to understand how different implementation alternatives behave as the size of the BiTRDF knowledge store increases, and to identify the trade-offs between extensibility and performance.

6.1. Memory Consumption

Table A14. Summary of Memory Consumption (MB).

Alternative/DataSet	D1	D2	D3	D4	D5	D6
OOP + Dictionary	831	1247	1468	1330	536	554
OOP + DataFrame	1101	1260	1429	1329	1094	658
OOP + List	1041	1303	1814	1525	1512	1334
DB + PostgreSQL	1667	3401	2323	456	1983	2532
DB + Dictionary	853	1701	3256	5054	3404	2479
DB + List	638	1273	2526	4640	3115	2779

summarizes the memory consumption of all six implementation alternatives across the six datasets. For smaller knowledge stores (D1 and D2), all alternatives exhibit comparable memory usage. At this scale, memory consumption is mainly influenced by implementation overhead rather than dataset size. The PostgreSQL-based alternative consumes more memory due to the initialization of a separate database process and internal buffering.

When the dataset reaches D3, PostgreSQL begins to offload data to disk, resulting in a temporary reduction in observed memory usage. This behavior reflects internal database memory management rather than improved space efficiency. For larger datasets (D4–D6), all alternatives exceed available RAM and rely on disk swapping to some extent.

Among the OOP-based alternatives, memory usage remains relatively stable after swapping occurs, although object creation and metadata introduce nontrivial overhead. In contrast, the database-oriented dictionary and list alternatives show higher memory growth at larger scales because all atomic values are stored explicitly without object reuse.

Figure 1 shows both absolute memory usage and per-million-triple trends. Overall, memory consumption is primarily driven by data representation choices and system-level memory management once the dataset size exceeds physical memory.

6.2. Loading Time

Table A15. Summary of Loading Time (seconds).

Alternative/DataSet	D1	D2	D3	D4	D5	D6
OOP + Dictionary	12.87	26.67	68.10	335.50	1069.00	2849.00
OOP + DataFrame	14.75	30.60	62.13	260.33	773.40	2523.10
OOP + List	9.14	18.31	36.50	76.49	406.68	1296.00
DB + PostgreSQL	5.70	15.00	35.00	102.00	254.00	598.00
DB + Dictionary	2.24	4.37	8.94	17.50	37.27	91.90
DB + List	2.85	6.13	12.79	26.57	107.06	409.38

reports details of the time required to load each knowledge store. Loading time increases with dataset size for all alternatives, as expected. For small and medium datasets (D1–D3), the differences are moderate, and all implementations complete loading within a reasonable time. Once the dataset exceeds available memory (D4–D6), performance gaps become significant.

The OOP-based alternatives incur higher loading costs because each triple must be parsed, instantiated as objects, and connected through internal structures. This overhead grows rapidly under memory pressure. Among these alternatives, the list-based implementation performs best due to its simpler storage model.

Database-oriented alternatives load data more efficiently by storing atomic values directly. The dictionary-based database approach consistently achieves the fastest loading times, followed by the list-based variant. PostgreSQL shows stable behavior but introduces overhead from database communication and transaction handling.

These trends are clearly illustrated in Figure 2, especially in the per-million-triple comparison. Overall, database-oriented storage is better suited for large-scale data ingestion, while OOP-based implementations favor semantic clarity over loading efficiency.

6.3. Query Time

Table A16. Summary of Query Time (seconds).

Alternative/DataSet	D1	D2	D3	D4	D5	D6
OOP + Dictionary	0.13	0.33	2.90	8.50	25.00	67.00
OOP + DataFrame	0.25	0.40	0.87	3.67	8.55	24.90
OOP + List	0.11	0.09	0.45	2.51	10.32	22.00
DB + PostgreSQL	0.12	0.18	0.25	1.37	5.68	15.25
DB + Dictionary	0.07	0.16	0.34	3.17	10.20	30.10
DB + List	0.05	0.10	0.21	0.43	5.94	18.60

summarizes the details of the query time results. For small datasets (D1 and D2), all alternatives provide fast query response times. As the dataset size increases, performance differences become more apparent. The OOP + dictionary alternative shows a sharp increase in query time from D3 onward, mainly due to nested dictionary traversal and memory swapping effects.

Other alternatives scale more smoothly. The list-based OOP approach maintains acceptable performance despite linear scans, benefiting from minimal structural overhead. Database-oriented alternatives perform consistently, with PostgreSQL benefiting from internal query optimization and efficient disk access.

Per-million-triple results indicate that query time grows approximately linearly for most alternatives, suggesting stable scalability. Figure 3 confirms that database-oriented implementations offer more predictable query performance under memory pressure.

Overall, the results reveal a clear trade-off between extensibility and performance. OOP-based implementations closely follow the BiTRDF conceptual model and are well-suited for experimentation and future extensions. Database-oriented implementations, in contrast, provide better scalability and efficiency for large-scale loading and querying tasks.

7. Conclusions

This paper presents the first systematic study of practical implementation methods for the BiTemporal RDF model. Through a comprehensive experimental evaluation of six implementation alternatives, we examined how different design choices affect memory consumption, loading time, and query performance across knowledge stores of increasing size.

The results show that, for small-scale knowledge stores, all alternatives perform similarly. When sufficient RAM is available (up to approximately one million triples), loading times remain under 30 s and query times remain below 0.5 s for all implementations. At this scale, the choice of implementation has little impact on overall system performance, allowing developers to prioritize design clarity and extensibility.

Performance differences become pronounced once the knowledge store exceeds available memory. For datasets larger than two million triples, database-oriented implementations consistently outperform object-oriented ones in both loading and querying. At the largest scale tested (16 million triples), the OOP + Dictionary alternative requires 2849 s to load the data, while the Database + Dictionary alternative completes loading in only 91.9 s. A similar gap is observed in query performance, where OOP + Dictionary requires 67 s, compared to 15.25 s for the PostgreSQL-based implementation. The results show that the storage strategy is critical for scalability.

Beyond quantitative performance, the architectural trade-offs among the alternatives are critical. While database-oriented designs favor retrieval efficiency, the Object-oriented implementations closely align with the BiTRDF conceptual model and provide strong flexibility and extensibility. These methods allow developers to modify bitemporal resource definitions, introduce additional dimensions, or adapt parsing and serialization logic with minimal effort. For applications that operate on moderate-sized knowledge stores or emphasize rapid development and experimentation, these methods offer a practical and maintainable solution.

Unlike SPARQL and its extensions, such as C-SPARQL, which primarily address temporal aspects at the query level through filtering or stream processing, our implementation focuses on embedding bitemporal semantics directly at the data model and storage level. This resource-level approach avoids reliance on reification or auxiliary structures to represent temporal information, thereby reducing structural overhead and improving efficiency. As a result, the proposed implementation provides a practical storage and indexing foundation that can support existing or future temporal SPARQL extensions.

The main contributions of this paper are summarized as follows:

• Presenting the first comprehensive study of practical implementation strategies for the BiTemporal RDF model.
• Designing and implementing six alternative approaches for storing and managing BiTRDF knowledge stores using Python and PostgreSQL.
• Empirically evaluating these approaches based on memory consumption, data loading time, and query performance across multiple dataset scales.
• Analyzing the strengths and limitations of each approach and providing practical guidance for selecting suitable implementation strategies under different system requirements.

Rather than delivering a fully production-ready BiTRDF system, this study demonstrates the feasibility of the BiTRDF model and highlights key design considerations for its implementation. Several directions remain open for future work, including support for update and deletion operations, conversion between BiTRDF and standard RDF, integration with SPARQL-based querying, and the development of temporal inference mechanisms. Together, these extensions would further advance the adoption of bitemporal semantics in RDF-based knowledge systems.