Temporal Data and Complete History

FERIN provides complete historical tracking through the concept plane, where concept relationships track both concept evolution and concept version relationships. Every change is recorded for point-in-time reconstruction and lineage tracing.

The FERIN Temporal Model

Temporal data in FERIN is managed through the concept plane, which provides rich concept semantics for tracking relationships between concepts and between concept versions over time.

Concept Plane

  • Concepts — abstract ideas that evolve over time
  • Concept versions — specific realizations at points in time
  • Concept relations — connections between concepts
  • Concept version relations — connections between versions

Content Plane

  • Register item classes — schemas defining structure
  • Register items — instances of concepts
  • Changes — records of all modifications

The concept plane maintains the temporal and semantic relationships, while the content plane stores the actual data instances. This separation enables independent evolution of meaning and representation.

Concept Version Timeline

Each concept has one or more concept versions, connected through relations. The #> relation indicates "has version" and #=> indicates "current version."

Example: Concept X Timeline

t₁Add Concept
Concept X #> Concept X v1.0
t₂Add Concept Version
Concept X #> Concept X v1.1
Concept X v1.1 !> Concept X v1.0
t₃Split
Concept Y #> Concept Y v1.0
Concept Z #> Concept Z v1.0
Concept Y v1.0 |> Concept X v1.1
Concept Z v1.0 |> Concept X v1.1
t₄Merge
Concept Q #> Concept Q v1.0
Concept Q v1.0 |> Concept Y v1.0
Concept Q v1.0 |> Concept W v1.0
t₅Invalidate
Concept Q v1.0.status.validity → invalid

FERIN Relation Notation

FERIN uses specific notation for concept and content relations. These relations enable temporal tracking and lineage reconstruction.

SymbolRelationTemporal Purpose
#>has versionLinks concept to its versions; links version to sub-versions
#=>current versionPoints to the current version of a concept
!>supersedesIndicates replacement; superseded version is no longer current
|>has partIndicates composition; used in splits and merges
(@...)instance ofLinks realization to its definition

Point-in-Time Queries

Because all relations and statuses can have temporal constraints, the register can be reconstructed at any point in time by:

  1. Filtering concept versions by their validity period
  2. Following relations that were active at that time
  3. Resolving the current version relation as it existed then

Query: State at t₃

  • Concept X: published (has version v1.1)
  • Concept Y: published (has version v1.0)
  • Concept Z: published (has version v1.0)
  • Concept W: published

Query: State at t₄

  • Concept X: superseded by Y, Z
  • Concept Y: superseded (merged into Q)
  • Concept Z: published
  • Concept W: superseded (merged into Q)
  • Concept Q: published (has version v1.0)

Query: Lineage of Concept Q

Q |> [Y, W] |> Y |> X

Split and Merge Operations

Complex transformations—splits and merges—are tracked through concept version relations. These are critical for reference data that evolves through organizational, political, or scientific changes.

Split Operation

One concept becomes multiple concepts.

CSCzechoslovakia
→
CZCzech Republic
SKSlovakia

FERIN Notation

CZ |> CS
SK |> CS
CS.status.publication → superseded

Query: "What replaced CS?"

Follow |> relations to find CZ and SK

Merge Operation

Multiple concepts become one concept.

EUR-AT
EUR-BE
EUR-DE
...
→
EUREurozone

FERIN Notation

EUR |> [EUR-AT, EUR-BE, EUR-DE, ...]
EUR-AT.status.publication → superseded
EUR-BE.status.publication → superseded
...

Query: "EUR codes in 2002?"

Query temporal constraint on relations to find pre-merge entries

Change Records

Every change in FERIN creates a change record that captures sufficient information to replay the change history. This enables point-in-time reconstruction of any register object.

Change Record Components

Object Identifier

Permanent identifier for this change

Action

The operation performed (add, modify, invalidate, etc.)

Affected Objects

Links to modified concepts, concept versions, register items

Change Content

New, replaced, or removed content

Timestamp

When the change occurred

Actor

Who performed the change (per governance process)

Example: Change Record for Split

Change: uuid:550e8400-...
Action: split
Affected: Concept CS, Concept CZ, Concept SK
Content:
  - Concept CS.status → superseded
  - Concept CZ created
  - Concept SK created
  - CZ |> CS
  - SK |> CS
Timestamp: 1993-01-01T00:00:00Z
Actor: Control Body decision CB-1992-47

Temporal Constraints

Relations and statuses can have temporal constraints indicating when they apply. This enables precise historical queries.

Validity Period

A status or relation applies during a specific time range

CS.status.validity
  applies: until 1993-01-01

Effective Date

A relation becomes effective from a specific date

CZ |> CS
  applies: from 1993-01-01

Multiple Intervals

Complex temporal patterns with multiple periods

Concept.status
  applies: [1990-01-01 to 1995-12-31,
            2000-01-01 to 2005-12-31]

Regulatory Compliance

FERIN's complete history through change records satisfies regulatory requirements for audit trails, immutability, and point-in-time reconstruction.

Regulatory RequirementFERIN Implementation
Immutable audit trail

Every change must be recorded and tamper-evident

  • Change records with object identifiers
  • Timestamp and actor metadata
  • Before/after content in change records
Retention period

History must be preserved for specified duration

  • Defined in register specification
  • Change records preserved indefinitely or per commitment
  • Deletion status marks content removed, not destroyed
Point-in-time reconstruction

Reconstruct state at any historical date

  • Temporal constraints on relations and statuses
  • Change records enable replay
  • Concept version history preserved

Commitment-Based History Access

Access to historical data is governed by the register's commitments. Different stakeholders have different access rights.

Full Transparency

All changes visible, all versions queryable

Open standards registries, public reference data

Limited Transparency

Current + N previous versions only

Commercial registries, subscription services

Regulatory Read-Only

Full history, immutable, access-logged

Compliance audits, regulatory oversight

Internal Only

Full to internal users, limited to external

Proprietary reference data, competitive data

Related Topics