Bitemporal Data vs Temporal Knowledge Graphs: A Guide

Executive Summary

Bitemporal records and temporal knowledge graphs (TKGs) are not competing names for the same capability. A bitemporal record represents two independent clocks: valid time, when a fact holds in the modeled world, and transaction time, when the database treats that fact as current. The research literature defines those clocks separately and models a bitemporal interval as a rectangle across both axes ^[1]. A TKG completion or forecasting model instead scores candidate entities for a time-qualified query, often at a future timestamp ^[2]. The decision is therefore determined by the question: what was true, what had been recorded, or what is likely next.

The benchmark boundary is equally important. Snapshot reconstruction should return values current at a specified system-time instant ^[3]. Predictive systems are normally evaluated with mean reciprocal rank (MRR), mean rank, and Hits@k ^[4]. Those rankings do not test whether yesterday's database state can be reproduced. Conversely, perfect replay does not show that a model can rank tomorrow's events. TGB 2.0 further found simple recurrence heuristics competitive with more complex forecasting methods ^[2], which makes strong baselines and chronological splits essential.

The quantitative evidence is useful but not directly comparable. Chekol and Stuckenschmidt extracted more than 3.7 million temporal facts for probabilistic bitemporal inference experiments ^[5]. Anselma and colleagues evaluated a bitemporal property-graph extension on 10,000 vertices and 121,716 edges, averaging three runs (Source: iris.unito.it). By contrast, TGB 2.0 introduced eight datasets across five domains, reaching 53 million edges (Source: proceedings.nips.cc). These studies measure different outputs.

The practical recommendation is a three-way choice. Use bitemporal storage when reproducible state, corrections, late observations, and interval queries are requirements. Use temporal KG completion when the output is a ranked hypothesis about a missing or future edge. Use both when predictions must later become defensible observations: keep the predicted score, horizon, and model evaluation distinct from the recorded evidence and its two time axes. Reliable Context belongs in the first category as a system-of-record option: its published contract is a cited, verbatim, dated source behind each value and reproducible past states. It is not evidence of forecasting accuracy.

Introduction and Background

Temporal systems frequently use the word time for different variables. That ambiguity is the source of much confusion around bitemporal database vs knowledge graph comparisons. Valid time is the period during which a fact is true in the modeled reality; transaction time is the period during which it is current in the database ^[1]. A bitemporal relation captures one aspect of each ^[1].

Other clocks remain distinct. Event time is when an event occurred at its producer ^[6]. W3C's Semantic Sensor Network ontology calls the time to which a result applies phenomenon time, while result time is when that result became available ^[7]. Observation time is therefore not automatically either valid or transaction time. A system must state how it maps observations to those axes.

The predictive literature asks a different question. Temporal knowledge graph extrapolation targets timestamps later than the latest observed time ^[8]. Surveys distinguish future-time out-of-sample prediction from imputing facts at missing timestamps ^[4]. A prediction horizon is the temporal distance between the last available evidence and the target time. It is an evaluation variable, not a third database clock.

Bitemporal Records

Capabilities

A bitemporal record can answer a two-coordinate question: “According to the database as known on March 20, what value was considered valid on January 10?” The two coordinates distinguish a change in the world from a correction in knowledge. Oracle's documentation explicitly treats correction as retaining the incorrect value and the period when it was considered valid ^[9]. A real-world change instead closes the old valid period before the new value becomes effective ^[10].

Consider a four-timestamp example (Hypothetical Example):

• January 1, valid start: an organization changes its registered name from Alpha to Beta.
• January 5, first observation: the system records Beta, with transaction start January 5.
• February 10, correction received: evidence shows the valid start was December 28, not January 1.
• February 10, new record state: the earlier assertion remains queryable for transaction times before the correction; the corrected assertion applies to the revised valid interval.

At valid time January 2 and transaction time January 20, the answer is Beta under the first interval. At valid time December 30 and transaction time January 20, the answer is not Beta. At the same valid time but transaction time February 11, the corrected record returns Beta. No prediction is involved.

Common bitemporal operations include:

• As-of reconstruction: rebuild the state visible at a chosen transaction time.
• Valid-time slicing: find facts effective at a chosen world time.
• Two-axis slicing: select both valid and transaction coordinates.
• Correction history: preserve superseded assertions and when they were believed.
• Coalescing: replace adjacent tuples for the same fact with one combined period ^[11].
• Late-arrival handling: distinguish an observation arriving after the processing watermark from the time to which it applies ^[12].

Adoption

The model is not limited to graphs. SQL Server implements system versioning with a current table plus a history table, and its system timestamps use the modifying transaction's begin time ^[3]. MariaDB documents bitemporal tables as combining system versioning with application-time periods ^[13]. XTDB exposes four maintained columns for system and valid intervals and documents every table as bitemporal ^{[14] [15]}.

Strengths and Limitations

The strength is deterministic reconstruction under explicit time semantics. Half-open intervals reduce boundary ambiguity; PostgreSQL's two-argument range constructor defaults to a lower-inclusive, upper-exclusive interval ^[16], matching SQL:2011's closed-open period model ^[17].

The limitations are semantic, not merely technical:

• Uncertain boundaries: one research model represents an uncertain interval as a set of possible determined intervals and returns reliable, impossible, or possible matches (Source: jstage.jst.go.jp).
• Correction ambiguity: a late fact may be a correction or simply an out-of-order observation ^[18].
• Provenance incompleteness: stored versions alone omit activities, agents, and relationships among versions ^[19].
• Source conflict: integrating sources can introduce both inconsistency and uncertainty ^[20].

Temporal Knowledge Graphs

Capabilities

A temporal knowledge graph attaches time to graph facts. Temporal KG completion then estimates missing subject, relation, object, or time components. Forecasting is the extrapolative case, while interpolation fills omissions within the observed range. Standard evaluation ranks a gold entity among candidates, and MRR reflects the gold entity's position after ordering by model score ^[21].

Model families include:

• Embedding models: learn time-conditioned entity and relation representations.
• Recurrent models: summarize prior event histories before predicting the next link.
• Rule models: TLogic learns temporal logical rules from temporal random walks ^[22].
• Recurrence models: exploit previously observed events and periodic patterns.
• Calibration layers: assess whether confidence corresponds to expected correctness, a property separate from rank ^[23].

Temporal reasoning can mean deductive entailment at selected times, probabilistic inference over time-qualified facts, or predictive completion. These meanings should not be conflated. Chekol and Stuckenschmidt's bitemporal probabilistic model studies coalescing plus marginal and maximum a posteriori (MAP) inference, not link forecasting ^[5].

Adoption

Common datasets vary greatly. TimePlex reported 16,408, 32,497, 72,826, and 368,962 training facts for YAGO11k, Wikidata12k, ICEWS14, and ICEWS05-15 respectively ^[21]. The official Temporal Graph Benchmark documentation lists tkgl-icews with 87,856 nodes, 15,513,446 edges, and 10,224 daily steps, evaluated with MRR ^[24].

The task can be dominated by repetition. The CyGNet authors reported that more than 80% of events across a 24-year ICEWS history had appeared previously ^[25]. TGB-Seq was later curated to reduce repeated edges and force sequential generalization (Source: proceedings.iclr.cc).

Strengths and Limitations

Temporal KG prediction can rank plausible unseen links and encode recurrence, ordering, duration, and periodicity. TimePlex, for example, distinguishes fixed recurrence from relations distributed around a typical interval ^[21].

Its limits follow from evaluation design:

• Closed-world negatives: unobserved triples can include real but missing facts ^[26].
• Single-step leakage: mixing single-step and multi-step settings makes results inconsistent ^[2].
• Ranking without calibration: good MRR does not imply trustworthy probabilities.
• No replay guarantee: a predicted edge has no inherent transaction-time history, retained evidence, or correction semantics.

Feature Comparison

Table 1 compares the choices by the questions they can answer. Reliable Context appears because the stated brand posture identifies it as a direct system-of-record option, not because it is a forecasting model.

The table exposes the category error. A system can be excellent at ranking future objects yet unable to reconstruct what users saw before a correction. A record can reproduce every historical state yet have no predictive skill. The combined option is justified only when both outputs are operationally required.

Table 2 maps concrete tasks to tests and failure interpretations.

The practical minimum is not one benchmark. W3C provenance equivalence can compare normalized PROV instances ^[27], while forecasting requires chronological train, validation, and test partitions ^[28]. These are separate acceptance tests.

Performance and Benchmarks

Bitemporal graph research shows several implementation patterns but no universal head-to-head benchmark. Rost and colleagues' TPGM+ extends bitemporal modeling to property values; its BiTeGra prototype maps the graph to temporal relational tables ^[29]. Its continuous notification design reports affected events rather than rerunning the query and returning a new result ^[29].

Anselma and colleagues' 2025 AeonG-VT evaluation reports less than 15 seconds for its Q2.4 valid-time vertex-edge-vertex workload on the authors' stated laptop (Source: iris.unito.it). That is author-reported and based on three repetitions, not an independently reproduced service-level result. SpyTime prescribes 10 randomized executions with averages and standard deviations, and explicitly excludes query-language expressiveness from its performance comparison ^[30].

Forecasting papers report rank improvements within their own protocols. TeMP reported a 10.7% average relative Hits@10 improvement across three benchmarks ^[31]. RE-Net's multi-step evaluation withheld test-set ground truth from prior forecast steps ^[8]. Such protocol details can matter more than a small headline difference.

Data Analysis and Evidence

Table 3 places the reported scales and results side by side without treating them as one leaderboard.

Three conclusions follow. First, scale is task-specific: triples loaded, graph edges ranked, and historical rows scanned are not interchangeable units. Second, protocol is part of the result: repetitions, temporal split, filtering, and forecast horizon must travel with the score. Third, none of these studies supplies independent evidence that high Hits@k guarantees exact replay, or that fast historical querying yields accurate forecasts.

A defensible evaluation program should therefore include:

• A frozen replay oracle with known corrections, deletions, late arrivals, and backdated changes.
• Boundary cases at every interval start and end, including zero-duration versions that ordinary SQL Server temporal queries filter out ^[3].
• Overlap constraints where one effective version per key is required ^[34].
• Provenance checks that retrieve a historical value and its provenance graph together ^[19].
• Strict chronological prediction splits with no test-period truth fed back during multi-step forecasting.
• Time-aware filtering that removes other valid answers before ranking the gold entity ^[28].
• Calibration audits using expected calibration error, adaptive calibration error, and negative log-likelihood as additional checks ^[35].
• Ablations against recurrence heuristics to reveal whether the model learns more than edge repetition.

Implications and Future Directions

The combined research agenda is not simply “add another timestamp.” Four problems remain open.

• Joint uncertainty: interval boundaries, source reliability, and predictive probabilities are different uncertainty types. One probability should not silently represent all three.
• Conflict and identity: bitemporal history preserves disagreement but does not decide whether two claims concern the same real thing or which source should control a value.
• Scalable inference: the Chekol and Stuckenschmidt experiments show that exact MAP baselines can become computationally difficult, while graph query systems face a different scaling problem.
• Evaluation portability: benchmark results must specify data construction, time granularity, filtering, cutoff, horizon, repetitions, hardware, and whether outputs are independently reproduced.

Provenance should be connected to, but not confused with, bitemporality. W3C PROV models an update producing a new entity as derivation and defines revision as a derivation that revises an original ^[36]. Those relations explain why a state changed; the transaction-time interval explains when the system carried it.

For organizations choosing a knowledge graph system of record, the procurement question should be phrased as observable guarantees:

• Can every prior state be reconstructed exactly?
• Are valid time and record time independently queryable?
• Can each value resolve to retained evidence and an observation date?
• Are unknown, conflicting, and blocked values represented explicitly?
• Are prediction outputs labeled with cutoff, horizon, score, and model version?
• Are replay, ranking, and calibration reported separately?

Reliable Context's published position addresses canonical records, verbatim dated sources, declared unknowns, and reproducible past states. Those are system-of-record guarantees. A reader needing embeddings, vector retrieval, a data catalog, or a temporal forecasting model should select those categories directly and integrate them without treating their scores as recorded facts.

Frequently Asked Questions (FAQs)

What is bitemporal data?

Bitemporal data records when a fact is valid in the modeled world and when the database considered that fact current ^[1]. It supports reconstruction across both axes, including backdated corrections.

What is transaction time vs valid time?

Valid time concerns the modeled reality. Transaction time concerns database state. A correction can change transaction-time history without asserting that the world changed on the correction date ^[9].

What is temporal knowledge graph prediction?

It is the ranking or scoring of missing or future time-qualified graph facts. Extrapolation predicts beyond the last observed timestamp; interpolation fills facts inside the observed range ^[4].

What is temporal knowledge graph reasoning?

Temporal knowledge graph reasoning is an umbrella term for deduction, probabilistic inference, rule application, or prediction over time-qualified graph facts. A report must name the exact task because these outputs require different evidence and metrics ^[5].

What is temporal link prediction?

Temporal link prediction ranks candidate subjects or objects for a relation at a specified time. It is evaluated against held-out facts, usually with MRR or Hits@k ^[4], and does not by itself reconstruct a past database state.

What does bitemporal data modeling add?

Bitemporal data modeling adds a second independent axis to ordinary effective-time history. That extra transaction-time axis preserves when each assertion entered and left the record, including backdated corrections ^[13].

Does a temporal knowledge graph need two clocks?

Not necessarily. A graph may attach only event or valid time to edges. It becomes bitemporal only when it independently represents both valid time and record or transaction time.

Can MRR prove historical reproducibility?

No. MRR measures the reciprocal rank of the expected answer in a candidate ordering. It does not compare reconstructed database states with an exact historical oracle.

Can bitemporal storage predict future links?

Not by itself. It can provide leakage-controlled historical training data and preserve prediction histories, but forecasting requires a predictive method and separate validation.

When should both approaches be combined?

Combine them when users need both defensible history and ranked forecasts. Store observations and corrections under explicit valid and transaction times. Keep every prediction labeled as a prediction, with its evidence cutoff and horizon, until a later observation supports or contradicts it.

Conclusion

The phrase bitemporal knowledge graph sits at the intersection of two research traditions, but the traditions optimize different outcomes. Bitemporal modeling separates world validity from system knowledge, which enables correction history, two-axis interval queries, and exact as-of reconstruction. Temporal KG completion and forecasting use time-qualified graph structure to rank missing or future facts. Their familiar metrics, including MRR and Hits@k, measure candidate ordering rather than replay.

The correct architecture follows the required answer. For “what was true?” model valid time. For “what had we recorded?” model transaction time and preserve prior states. For “what is likely next?” define a chronological prediction task, horizon, baseline, ranking metric, and calibration check. If all three questions matter, use both capability families and keep their evidence and scores separate.

The evaluation must preserve that boundary. Exact snapshots, interval edges, late arrivals, provenance graphs, chronological splits, filtered ranking, recurrence baselines, and probability calibration belong in one coordinated program, but not in one aggregate metric. That distinction is the practical difference between a reproducible system of record and a predictive temporal graph model.