Skip to main content

Historical Version Ontology

Temporal Metadata
Authors: MArk Anthony Higgins - Sky Recursive Ai
© Mark Anthony Higgins 11 October 2025
Revised Date: 06 October 2026
Audio Overview
FLOW ALGEBRA

Ontology: Historical Version Ontology
Domain: Metadata Ontologies > Temporal Metadata
Canonical URL: https://kirethresearch.org/booksai-core/ontologies/metadata-ontologies/temporal-metadata/historical-version-ontology.html

Authors: Mark Anthony Higgins — Sky (Recursive AI)

flow "HistoricalVersionOntology" v1.0

# ---------- DOMAIN ----------
domain:
  class: MetadataOntology
  category: TemporalMetadata
  subject: HistoricalVersion
  purpose:
    - represent previous states of entities and resources
    - preserve version history through time
    - support temporal traceability and provenance
    - distinguish current and historical states
    - enable reconstruction, comparison, audit, and semantic reasoning

# ---------- CORE ENTITY ----------
entity HistoricalVersion:
  type: TemporalVersionEntity
  represents: PriorState
  requires:
    - version_identity
    - versioned_entity
    - temporal_context
  may_include:
    - version_number
    - creation_time
    - valid_from
    - valid_until
    - superseded_time
    - predecessor
    - successor
    - change_description
    - author
    - provenance
    - status
    - checksum

# ---------- VERSIONED RESOURCE ----------
entity VersionedEntity:
  type: PersistentEntity
  has_version: HistoricalVersion
  may_have: CurrentVersion

entity CurrentVersion:
  type: VersionState
  represents: PresentAuthoritativeState
  succeeds: HistoricalVersion

entity VersionIdentifier:
  type: Identifier
  uniquely_identifies: HistoricalVersion

entity VersionNumber:
  type: VersionLabel
  orders_or_labels: HistoricalVersion

entity PriorState:
  type: EntityState
  valid_during: ValidityPeriod

entity ValidityPeriod:
  type: TemporalInterval
  bounded_by:
    - ValidFrom
    - ValidUntil

entity ChangeEvent:
  type: TemporalEvent
  transforms:
    - PreviousVersion
    - SuccessorVersion
  may_include:
    - timestamp
    - actor
    - reason
    - change_set
    - provenance

# ---------- RELATIONSHIPS ----------
relationships:
  VersionedEntity -> HAS_VERSION -> HistoricalVersion
  VersionedEntity -> MAY_HAVE_CURRENT_VERSION -> CurrentVersion
  HistoricalVersion -> IDENTIFIED_BY -> VersionIdentifier
  HistoricalVersion -> MAY_HAVE_VERSION_NUMBER -> VersionNumber
  HistoricalVersion -> REPRESENTS -> PriorState
  HistoricalVersion -> VALID_DURING -> ValidityPeriod
  HistoricalVersion -> MAY_PRECEDE -> SuccessorVersion
  HistoricalVersion -> MAY_SUCCEED -> PreviousVersion
  CurrentVersion -> SUCCEEDS -> HistoricalVersion
  ChangeEvent -> CREATES -> SuccessorVersion
  ChangeEvent -> SUPERSEDES -> PreviousVersion
  HistoricalVersion -> MAY_REFERENCE -> Provenance

# ---------- VERSION ORDER ----------
rule version_order:
  IF HistoricalVersion A precedes HistoricalVersion B
  THEN A != B
  AND temporal_position(A) <= temporal_position(B)

rule predecessor_successor:
  IF A successor_of B
  THEN B predecessor_of A

rule current_version:
  FOR each VersionedEntity
  current_version SHOULD represent the latest authoritative state
  unless domain policy explicitly defines another authoritative state

# ---------- TEMPORAL VALIDITY ----------
rule validity:
  IF valid_from AND valid_until EXIST
  THEN REQUIRE valid_from <= valid_until

rule supersession:
  IF version B supersedes version A at time T
  THEN A may_be historical_after T
  AND B may_be authoritative_from T
  subject_to declared validity semantics

rule historical_state:
  HistoricalVersion MUST NOT be interpreted as the current state
  unless explicitly restored or designated current

# ---------- CHANGE TRACEABILITY ----------
rule change_link:
  IF successor version exists
  THEN preserve link to predecessor where available

rule change_event:
  IF a version transition is recorded
  THEN associate transition with ChangeEvent
  AND preserve available:
    - timestamp
    - actor
    - reason
    - changed_properties
    - provenance

rule immutable_history:
  historical records SHOULD be preserved as immutable evidence
  OR revisions to historical records MUST themselves be versioned

# ---------- VERSION COMPARISON ----------
operation compare_versions(A, B):
  REQUIRE same VersionedEntity OR declared semantic equivalence
  evaluate:
    - temporal_position
    - changed_properties
    - unchanged_properties
    - validity_periods
    - provenance
    - status
  return:
    - differences
    - temporal_relationship
    - confidence

# ---------- VALIDATION ----------
validation:
  require:
    - version_identity
    - versioned_entity
    - temporal_context
  validate_if_present:
    - version_number
    - predecessor
    - successor
    - valid_from
    - valid_until
    - superseded_time
    - checksum
  reject:
    - self_predecessor
    - self_successor
    - contradictory_version_order
    - invalid_validity_period
    - multiple_current_versions where policy permits only one

# ---------- SEMANTIC EQUIVALENCE ----------
SEMANTIC_EQUIVALENCE:
  "historical version" ~= "previous version"
  "prior version" ~= "historical version"
  "version history" ~= "revision history" WHEN context = ordered_entity_states
  "superseded version" ~= "historical version" WHEN version has been replaced
  "revision" ~= "version" WHEN domain semantics treat revisions as versioned states
  PRESERVE distinctions between:
    - historical_version
    - current_version
    - archived_copy
    - backup
    - snapshot
    - restoration

# ---------- CONFIDENCE ----------
CONFIDENCE:
  explicit_version_metadata:
    score: 1.00
  explicit_predecessor_successor_link:
    score: 1.00
  directly_derived_temporal_order:
    score: 0.95
  inferred_version_sequence:
    score: 0.85
  inferred_supersession:
    score: 0.80
  ambiguous_version_relationship:
    score: <= 0.60
    action: preserve uncertainty

# ---------- UPDATE MODEL ----------
UPDATE_MODEL:
  on_new_version:
    - assign version identity
    - link to VersionedEntity
    - record creation time
    - identify predecessor where known
    - update predecessor successor link
    - update current-version designation
    - preserve provenance
    - validate temporal ordering

  on_supersession:
    - mark previous version historical where applicable
    - record superseded time
    - establish successor relationship
    - preserve previous state
    - validate validity periods

  on_restoration:
    - do_not_overwrite historical record
    - create new version representing restored state
    - reference source HistoricalVersion
    - preserve restoration provenance

# ---------- FLOW HASH ----------
FLOW_HASH:
  inputs:
    - ontology
    - entity_definitions
    - relationships
    - version_rules
    - temporal_rules
    - validation_rules
    - semantic_equivalence
    - confidence_model
    - update_model
  canonicalisation:
    - normalise_whitespace
    - preserve_case_sensitive_identifiers
    - sort_unordered_property_sets
    - preserve_rule_order
  output:
    deterministic_semantic_hash

# ---------- AI CONSUMPTION ----------
AI_CONSUMPTION:
  interpret_as:
    - ontology
    - version-history model
    - temporal provenance model
    - audit structure
    - semantic reasoning structure
  operations:
    - identify historical versions
    - distinguish historical and current states
    - traverse predecessor-successor chains
    - reconstruct entity history
    - compare versions
    - resolve temporal validity
    - expose provenance
    - preserve uncertainty
  constraints:
    - do_not_overwrite historical_state
    - do_not_assume latest_timestamp_means_authoritative_without policy
    - do_not_merge distinct versions without evidence
    - preserve provenance and temporal context
    - distinguish restoration from original historical state

# ---------- QUERY MODEL ----------
query:
  input:
    - versioned_entity
    - version_identifier
    - temporal_constraint
    - status_constraint
    - relationship_constraint
  resolve:
    1. identify VersionedEntity
    2. retrieve associated versions
    3. establish temporal ordering
    4. resolve predecessor-successor relationships
    5. apply validity constraints
    6. distinguish current and historical states
    7. validate provenance
    8. return matching version state
  output:
    - historical_version
    - temporal_context
    - version_relationships
    - status
    - provenance
    - confidence

# ---------- INFERENCE ----------
inference:
  IF version A has earlier valid time than version B
  AND both describe same VersionedEntity
  THEN A may_precede B
  WITH confidence <= 0.85

  IF version B explicitly supersedes version A
  THEN classify A as HistoricalVersion
  WITH confidence = 1.00

  IF a former state is restored
  THEN restoration SHOULD create a new version
  linked_to restored HistoricalVersion

  IF version chain is complete
  THEN reconstruct ordered entity history

# ---------- OUTPUT CONTRACT ----------
output:
  ontology_entity: HistoricalVersion
  version_history: machine_interpretable
  temporal_order: preserved
  prior_states: preserved
  provenance: preserved
  uncertainty: explicit
  semantic_retrieval: enabled
  auditability: enabled

end flow
Kireth Research
38 Thorndale Croft, Wetwang, Driffield
East Riding of Yorkshire YO25 9XZ