Ontochronology

The Problem: Time as an Afterthought

Every knowledge graph has temporal data. Almost none of them can query it well.

The dominant pattern is time as a qualifier: a triple like (:Napoleon :heldPosition :Emperor) gets a start date and end date as metadata hanging off it. This works for point lookups — “was Napoleon emperor in 1810?” — but it fails catastrophically for the queries that actually matter:

• What was the complete state of the world at time T? → Full graph scan, filter every triple’s qualifiers.
• What changed between T1 and T2? → Two full graph scans, diff the results.
• Which entities were co-present during this interval? → Scan everything, filter, group.

These queries are expensive because time is organized around triples instead of triples being organized around time.

The Insight: Time as a Leading Index Key

Loka already maintains three index orderings over every triple — SPO, POS, and OSP — so that any access pattern hits an index. Ontochronology adds a fourth ordering with time as the leading key:

With TSPO, “give me the complete world state at time T” is a single range scan on the first key component. No joins. No filter passes. No graph traversal. Every triple valid at T just falls out.

Not Always a Clock

The “T” in TSPO is not necessarily a UTC timestamp. It is an ordered scalar — any value that can be sorted and range-scanned. The B-tree doesn’t care what the bytes represent. It only needs a total ordering.

The axis type is a database-wide setting configured at creation time. You do not mix frame numbers and UTC timestamps in the same TSPO index — that would make range scans meaningless.

# Database creation with non-default axis
loka create movie.sdb --temporal-axis=integer    # frame/scene numbers
loka create scripture.sdb --temporal-axis=float  # chapter.verse as float
loka create events.sdb                            # default: UTC timestamp

Three Ways to Say When

Every triple can carry up to three temporal signifiers. None are required — some facts are intrinsically atemporal. A triple can have any combination, and can have multiple valid time intervals.

Assertion time is the crutch. In a perfect world, every fact would have known start and end times. But for most historical data, most extracted data, and most real-time observations, we don’t know when a state began or ended. We only know it was observed at a certain time.

Precision, Not Confidence

Timestamps carry a precision level derived from their format:

"1977-10-29"^^loka:temporal
→ day precision

"1909"^^loka:temporal
→ year precision

Precision is not confidence. A fact with year-level precision isn’t “less certain” — the granularity is genuinely part of the truth claim. “Born in 1909” is as certain as “died October 29, 1977” — we just don’t have a more specific date.

RDF-star Representation

Temporal data uses RDF-star annotations — statements about statements:

# Assertion time only (the crutch)
<< :building_42 :locatedIn :MainStreet >>
    loka:assertedAt "1847"^^loka:temporal .

# Full valid-time interval
<< :napoleon :heldPosition :Emperor >>
    loka:validFrom "1804-05-18"^^loka:temporal ;
    loka:validTo   "1814-04-11"^^loka:temporal .

# Open-ended (still true)
<< :alice :worksAt :Acme >>
    loka:validFrom "2023-01-15"^^loka:temporal .

# Atemporal (no temporal annotation at all)
:water :chemicalFormula "H2O" .

SPARQL+ Temporal Operators

New operators scope graph patterns to specific moments or intervals:

AT_TIME — Point-in-time query

# Who was where at 10am on March 14th?
SELECT ?person ?location WHERE {
  AT_TIME("2024-03-14T10:00:00"^^xsd:dateTime) {
    ?person :locatedIn ?location .
    ?person rdf:type :Suspect .
  }
}

DURING — Interval query

# Who was at the courthouse during the hearing?
SELECT ?person ?location WHERE {
  DURING("2024-03-14T09:00", "2024-03-14T11:00") {
    ?person :locatedIn :Courthouse .
  }
}

WORLD_STATE — Complete snapshot

# Everything that was true at this moment
SELECT ?s ?p ?o WHERE {
  WORLD_STATE("2024-03-14T10:00:00"^^xsd:dateTime) {
    ?s ?p ?o .
  }
}

TEMPORAL_DIFF — What changed?

# What changed between scene 3 and scene 4?
SELECT ?change ?s ?p ?o WHERE {
  TEMPORAL_DIFF("scene_3_end", "scene_4_start") {
    ?s ?p ?o .
    BIND(loka:changeType AS ?change)
  }
}

Composition with Vector Search

# Find semantically similar documents about people
# who existed at a specific time
SELECT ?doc ?entity WHERE {
  AT_TIME("2024-06-01"^^xsd:dateTime) {
    ?entity rdf:type :Person .
    ?doc :mentions ?entity .
  }
  VECTOR_SIMILAR(?doc :hasEmbedding "..."^^loka:f32vec, 0.85)
}

Use Cases

The Dimensional Spectrum

Ontochronological indexing is one instance of a general pattern: promote the query axis to a leading index key. The same approach extends to coordinates, provenance, and confidence:

Architecture

Ontochronological features are purely additive:

• Existing SPO/POS/OSP indexes are unaffected
• Existing HNSW vector indexes are unaffected
• Existing SPARQL+ queries work unchanged
• Databases without temporal data pay zero cost
• The TSPO index is only built when temporal predicates are present

Three new reserved predicates trigger temporal indexing:

The query planner treats TSPO exactly like it treats SPO, POS, OSP, and VECTOR — as an access path with cost estimates. Temporal queries that benefit from TSPO get routed there. Queries that don’t simply ignore it.