E2 · Publication Volume 24

Temporal Semantics

event time, valid time, transaction time and model effective date

Learning objectives

• Explain why event time, valid time, transaction time and model effective date require explicit semantic modelling.
• Design identities, relations and constraints that preserve temporal semantics across exchange.
• Separate hard release gates from diagnostic metrics and interpretation choices.
• Produce a bitemporal correction history and reproducible model cut-off policy from synthetic evidence.

The lesson is complete only when the learner can defend both the model and the release decision. A neat schema without evidence, tests or declared limitations is an unverified design. The assessed artefact must make assumptions visible and distinguish source assertions from derived conclusions.

Decision context

For every entity and claim, decide which temporal axes affect interpretation. Use explicit intervals for lifecycle and validity, explicit instants for events and immutable transaction history for corrections. A file modification time is operational metadata, not a substitute for domain time.

Start with a decision record: name the intended use, the evidence required, the consequence of error, the accepted uncertainty and the role authorised to accept residual risk. Then ask whether the proposed model can answer the decision question without relying on filename conventions, row order, undocumented defaults or someone’s memory. This prevents technology selection from concealing a missing semantic requirement.

The same record may be fit for one use and unfit for another. A rapid exploratory view can tolerate conditions that a released exchange package cannot. Fitness is therefore stated against a use, contract version and quality gate rather than attached permanently to the data.

Core concept

One timestamp rarely answers every temporal question. Event time says when something happened; valid time says when a claim applies to the world; transaction time says when the system recorded it; model effective time says which state a model represents. Keeping them separate makes late data and corrections auditable.

The working scope is event time, valid time, transaction time and model effective date. For each item in that scope, distinguish the thing itself, the label used by a source, the claim made about it and the record that carries the claim. Identity is not a display name; a value is not its unit; an observation is not a model; current is not the same as valid. These distinctions create explicit places for correction, uncertainty and competing interpretations.

A good semantic design can be explained as a set of sentences before it is encoded. Each sentence identifies a subject, a property or relationship, an object or result, and the context under which the claim holds. Physical tables and files are then projections of those sentences, not their source of meaning.

Semantic model

Represent validity with half-open intervals [t_s,t_e) so adjacent states meet without overlap. Store event time with precision and offset. Transaction history records asserted-at and superseded-at instants. A model release declares its effective date and the cut-off policy used to select source observations.

Test every proposed record against seven questions: What has identity? What type is it? Which property or relationship is asserted? Which spatial and temporal context applies? Which state or qualifier modifies the assertion? Which evidence supports it? Which version and activity produced the stored representation? Missing answers become explicit contract gaps.

Normalisation is used to separate independent facts, not to maximise the number of tables. A compact nested object can be semantically sound if the same identities, constraints and provenance remain explicit. Conversely, a highly normalised database can still be ambiguous when relationships and units exist only in documentation or application code.

Constraints and invariants

| Invariant | Executable or review test | | --- | --- | | Temporal property is named | Do not use a generic date field for multiple meanings. | | Offsets and precision are explicit | Reject ambiguous local timestamps at exchange boundaries. | | Validity intervals do not conflict | Apply overlap rules per entity and property family. | | Corrections append history | Never rewrite the transaction time of the original assertion. |

An invariant is a condition that must remain true across storage, export, correction and reprocessing. Implement it as close to the authoritative boundary as practical and repeat the check at exchange boundaries. Record rule identifier, version, severity, evaluated scope, observed value and outcome so a failure can be reproduced.

Hard gates protect identity, semantic validity, required provenance and authorised use. Diagnostic checks reveal unusual values or patterns but require interpretation. Never convert a diagnostic threshold into deletion or correction without a reviewed rule and preserved source evidence.

Quantitative reasoning

Latency is L = t_{transaction} - t_{event} when the two timestamps are comparable. Report its distribution and negative values, which may indicate clock, offset or semantic errors. Temporal completeness reports missing axes separately; a transaction time cannot compensate for a missing event time.

Every reported ratio states its numerator, denominator, exclusions and evaluation time. Stratify results by source, entity type, contract version or processing run where aggregation could hide a local failure. Counts accompany percentages so a seemingly large change based on a tiny denominator remains visible.

Precision is part of meaning. Do not add decimal places merely because a storage type permits them, and do not round identity, interval or coordinate fields without a declared tolerance and test. Quantitative summaries support a release decision; they do not replace semantic review.

Evidence and uncertainty

Timestamp precision is evidence. A date-only field must not be promoted to midnight precision, and a historical estimate must carry its uncertainty or granularity. Clock source, time-zone conversion and cut-off policy belong in processing provenance where they affect ordering.

Build an evidence packet containing preserved source reference, acquisition or assertion context, applicable method, validation results, reviewer decision and links to derivatives. Classify uncertainty as observational, semantic, structural, parametric or policy-related where that distinction changes treatment. “Unknown” is a valid state when the evidence cannot justify a stronger claim.

Contradictory evidence remains available. The model may select one current assertion, but the reason, competing assertion and effective time are retained. This makes later reinterpretation possible without pretending the earlier evidence never existed.

Interfaces and storage

Use an interoperable timestamp profile with explicit offset and agreed precision. Exchange interval boundary conventions and open-ended representation in the contract. Preserve source text when parsing legacy dates so a corrected parser can reproduce the transformation.

Design an interface from the logical contract outward. Specify identifiers, types, cardinalities, units, value states, coordinate and time references, version negotiation, validation behaviour and structured errors before choosing a serialisation. The physical representation then declares its mapping to those logical elements.

Storage optimisation may partition, compress, index or cache data, but it must not change identity or silently remove context. A derived representation points to immutable inputs and a processing manifest. A cache carries freshness and contract-version information and is never treated as the only evidence copy.

Governance and access

Define the authoritative role for each temporal property. Operational ingestion may assign transaction time, while the observing process supplies event time and a review process approves corrected validity. A model release policy states how late-arriving or backdated records are treated.

Governance is expressed through named roles, review states and versioned decisions, not through references to a particular organisation. Define who may propose, validate, approve, supersede and withdraw each governed resource. The audit trail records the role and event while avoiding unnecessary personal data.

Apply least-necessary access to source evidence and derivatives. Access controls must not erase identifiers, lineage or quality metadata needed to understand an authorised release. When policy is unresolved, quarantine the output with a precise reason and escalation route.

Integration checkpoint

The diagram summarises the control flow for this lesson. Read it from source evidence through semantic structure and validation to a decision-ready artefact. Each arrow should correspond to a declared relationship or transformation; each boundary should have a contract; each released node should have an identity, version and provenance pointer.

Integrate the lesson by adding a bitemporal correction history and reproducible model cut-off policy to the evolving synthetic data package. Verify that earlier artefacts still resolve and that the new model does not overwrite observations, identifiers, values or versions introduced in previous lessons. Record every changed assumption.

Synthetic worked example

A synthetic survey was observed on day 4, loaded on day 7 and corrected on day 10 with validity back to day 4. The learner stores the event, first transaction, correction transaction and validity separately. A model effective on day 8 uses the first assertion; a rerun after day 10 may use the corrected assertion under its declared cut-off policy.

Work the example in four passes:

1. Preserve the received records and write the intended decision without correcting anything.
2. Identify entities, claims, context, uncertainties and policy constraints; mark every unresolved item.
3. Apply the versioned rules, create derivatives and record the exact transformation plus validation evidence.
4. Issue an accept, reject or quarantine decision and show how an independent reviewer can reproduce it.

Because the example is entirely synthetic, its values demonstrate method only. The important result is the chain from received evidence to justified decision. If a required fact is absent, the worked solution records the gap rather than manufacturing a plausible value.

Practice task

Create a bitemporal history for six synthetic corrections. Use half-open validity intervals, retain transaction history, calculate ingestion latency and reproduce the dataset as known at two past transaction times and as valid at two domain times.

Use the following acceptance criteria:

• All required identifiers and references resolve to declared types.
• Every transformation preserves the received evidence and records its derivation.
• Invalid, unknown and inapplicable states remain distinct and machine-testable.
• The output identifies the contract, vocabulary and processing versions used.
• A second reader can reproduce the validation result without private knowledge.

Submit the source snapshot, authored contract or model, validation output, derivative, manifest and a short decision record. A screenshot alone is insufficient because it cannot demonstrate the exact input, version or rule execution.

Common failure modes

• One field called date mixes event and transaction meaning.
• Local time is exchanged without an offset.
• A correction rewrites history instead of superseding it.
• A model version lacks an effective date or source cut-off policy.

These failures share a pattern: convenient representation is mistaken for verified meaning. Diagnose the earliest boundary at which an assumption became implicit. Correct by restoring source evidence, making the assumption a versioned field or rule, rerunning dependent transformations and superseding—not overwriting—the affected release.

Do not repair a failure by adding an undocumented default. A blocked result with a specific missing dependency is safer and more reusable than a complete-looking result whose meaning cannot be reconstructed.

Review questions

1. How do event, valid and transaction time differ?
2. Why are half-open intervals useful?
3. What does negative ingestion latency suggest?
4. How can a past model release be reproduced after corrections?

For each answer, identify the governing invariant, the evidence needed to evaluate it and the appropriate release behaviour when the invariant fails. A strong answer distinguishes scientific uncertainty from missing semantics and distinguishes a recoverable warning from a hard contract violation.

Sources and further reading

• RFC 3339, an interoperable date-and-time representation with explicit offsets.
• W3C PROV-O, a formal vocabulary for entities, activities, agents and derivation.
• W3C DCAT 3, dataset, distribution, service and catalogue metadata.
• DataCite Metadata Schema 4.7, resource identity, related identifiers, rights and version metadata.