The record is accurate.
Then the world changes.
The record does not.
Metadata currentness is the discipline of knowing whether a description that was once correct still matches the resource state that matters now.
This is the second pillar beneath How Metadata Works. The master owns the full description system. This article isolates time: when metadata was observed, when it was asserted, when it became valid, when it stopped being valid, what should trigger a refresh, and how stale copies are repaired downstream.
Quick Read
Metadata currentness is not the same as the metadata record’s last-modified timestamp. A value can be edited today while still describing a world state from three years ago. Current systems need to distinguish event time, observation time, assertion time, metadata modification time and validity time. Some fields—ISBN, accession number, birth date—may be relatively stable. Others—URL, rights, availability, current version, organisational name, attribution or access endpoint—can change quickly. Currentness should therefore be governed by field-specific refresh rules and decision risk rather than one global “fresh enough” threshold.
world state → observation → metadata assertion → valid interval → resource change → stale state → refresh trigger → correction → reindex/API/export propagation → live verification
Correctness Has a Time Index
A museum record says a painting is attributed to Artist A.
That statement was accepted in 2022.
New technical analysis in 2026 supports “Workshop of Artist B.”
The old field was not necessarily fabricated.
It became stale relative to the institution’s current accepted interpretation.
Metadata quality therefore requires a temporal question:
Correct for which world state?
Modified At Is Not Observed At
A cataloguer opens a record today and fixes punctuation.
The database now says:
metadataModified = 2026-08-31
But the rights field may still come from a 2021 review.
The last-modified timestamp describes an edit to the record, not necessarily a new observation of every underlying fact.
One Record Contains Many Clocks
- event time: when something happened in the world;
- observation time: when the system or curator observed the fact;
- assertion time: when the value entered the metadata record;
- modification time: when the metadata record or field was edited;
- valid-from: when the value began to apply;
- valid-to: when it stopped applying or is expected to expire;
- retrieved-at: when a downstream system fetched a copy.
Compressing all of these into one field called date creates temporal ambiguity.
Stable Fields and Volatile Fields Need Different Refresh Policies
An accession number may be designed to remain stable.
An access URL may change during a platform migration.
A licence can expire.
A current office holder can change overnight.
A dataset’s latest release can change monthly.
It is inefficient to refresh every field at the rate of the fastest one—and unsafe to refresh every field at the rate of the slowest.
Currentness Is Field-Specific
A good metadata profile can assign currentness expectations per property:
- stable identifier: verify on creation and integrity events;
- current URL: monitor or recheck periodically;
- rights: recheck on licence expiry or policy change;
- current version: check when publisher announces a release;
- attribution: update on scholarly review;
- availability: verify near the user’s intended action.
The field’s role determines its freshness burden.
Currentness Is Also Decision-Specific
A six-month-old opening-hours record may be fine for historical analysis.
It may be unacceptable for someone deciding whether to travel across the city right now.
The same metadata value can therefore be current enough for one receiver and too stale for another.
freshness threshold = function of volatility × consequence × receiver goal.
Risk Should Shorten the Refresh Interval
A stale subject tag may reduce discovery quality.
A stale access-control field may expose restricted content.
A stale medical dosage field could be dangerous.
The higher the consequence of acting on an outdated value, the stronger the currentness requirement should be.
Expiry Is Stronger Than “Last Checked”
Some metadata is naturally time-bounded.
- embargo ends on a date;
- licence expires on a date;
- temporary exhibition runs through a date;
- API token is valid until a date;
- temporary location applies during renovation.
Where the validity interval is known, store it explicitly rather than asking future users to infer expiry from “last updated.”
Unknown Expiry Is Still a State
Not every value has a known valid-to date.
Do not invent one.
Instead distinguish:
- known current;
- known historical;
- valid until a known date;
- currentness not recently verified;
- currentness unknown.
Uncertainty should remain visible rather than being flattened into a false “current” flag.
DCAT 3 Makes Version Relationships First-Class
The current W3C Data Catalog Vocabulary (DCAT) Version 3 supports resource versioning with relationships such as current version, previous version, version identifiers and version notes. DCAT 3 was designed to remain backward compatible with DCAT 2 while adding versioning and other features.
This matters because “current dataset” and “dataset version 2024.1” are different metadata objects.
Latest Is a Relationship, Not a Property of the Old Record
Version 3 does not become version 4.
Version 4 is a new version related to version 3.
A stable series identity can point to the current version while historical version records remain resolvable.
This avoids rewriting history merely to keep a “latest” link current.
URLs Are Particularly Volatile Metadata
A resource moves to a new server.
The DOI or canonical identifier remains the same.
The access URL changes.
If the system equated identity with location, it now faces an identity crisis.
The Metadata master already owns the distinction:
identifier ≠ location.
Currentness makes the operational consequence clear: locations need refresh rules.
Rights Metadata Can Become Stale Quietly
A licence changes.
An embargo ends.
A contract expires.
A rights holder transfers ownership.
The content file can remain identical while the legitimate-use metadata changes materially.
Rights currentness should therefore be monitored independently of content checksum.
Attribution Can Change Without the Object Changing
A painting remains physically the same object.
Research changes its attribution.
Object identity is stable.
Descriptive interpretation changed.
Metadata Provenance owns who asserted each value and why. Currentness owns whether that assertion is still the accepted one for the present state.
Organisation Metadata Can Drift Through Renaming and Restructuring
A department is renamed.
Two agencies merge.
A company changes legal entity.
A school changes campus.
Current labels, historical names and persistent identifiers should not be collapsed into one overwritable string.
Controlled Vocabularies Have Currentness Too
A subject term can be deprecated.
A concept can be split.
A preferred label can change while the concept identifier remains stable.
Metadata using controlled vocabularies therefore depends on the current state of those vocabularies as well as on the resource.
Schema Currentness and Resource Currentness Are Different
A record can describe the current resource perfectly using an old schema.
Another record can conform to the newest schema while describing a stale resource state.
The fourth pillar, Schema Evolution, owns vocabulary/profile version change. Metadata Currentness owns whether field values still match the world.
Refresh Can Be Event-Driven
Publisher releases a new version.
Rights holder changes licence.
Museum approves reattribution.
Website issues a redirect.
If a trustworthy event source exists, the metadata system can refresh immediately rather than waiting for a periodic sweep.
Refresh Can Be Scheduled
Some sources expose no event notification.
Then periodic revalidation may be appropriate:
- daily for volatile operational fields;
- monthly for moderate-change records;
- yearly for relatively stable descriptions;
- on-demand before a high-consequence action.
The cadence should follow evidence about change rate, not an arbitrary universal interval.
Refresh Can Be Demand-Driven
A rarely used record has not been checked in two years.
A user requests it now for an important decision.
Instead of refreshing every dormant record constantly, the system can revalidate at retrieval time when consequence justifies it.
Refresh-on-Read Needs Latency Budget
Live revalidation improves currentness.
It can also slow retrieval or fail when the authoritative source is unavailable.
A practical system may use:
- cached current value;
- retrieved-at timestamp;
- freshness threshold;
- background or synchronous recheck according to risk;
- explicit stale/unknown state when the source cannot be reached.
A Stale Value Should Not Masquerade as Missing
Old opening hours are not the same as no opening-hours data.
The record may still be useful historically.
Represent:
- value;
- last verified;
- currentness state;
- source;
- whether the value should be acted upon now.
This preserves knowledge without misrepresenting operational certainty.
Downstream Copies Create a Second Currentness Problem
The canonical catalogue is corrected at 10:00.
The search index refreshes at 10:05.
The public API cache expires at 11:00.
An external aggregator harvests nightly.
For several hours, multiple “current” values coexist.
canonical correction time ≠ ecosystem correction time.
Currentness Needs Propagation State
A mature correction receipt can track:
- canonical record updated;
- index rebuilt;
- API cache invalidated;
- export regenerated;
- subscriber notified;
- external harvest observed;
- live retrieval verified.
This turns “we fixed it” into an end-to-end state.
Crosswalks Can Freeze Stale Mappings
Schema A changes.
The crosswalk into Schema B does not.
New records continue flowing through an old mapping rule.
The third pillar, Metadata Crosswalks, owns translation loss; currentness adds the requirement that mapping rules themselves be versioned and reviewed.
“Last Updated” Can Be Misleading UX
A page says “Last updated today.”
Only one spelling error changed.
Users may infer every factual field was reverified today.
Better systems separate:
- record modified;
- field verified;
- resource state observed;
- source retrieved.
Currentness Can Be a Derived State
Suppose a licence field was verified 20 days ago.
Policy says licences must be rechecked every 30 days.
The system can derive:
currentness = within freshness envelope
On day 31, the value can move automatically to “needs revalidation” without deleting the previous statement.
Currentness Should Fail Closed at High-Risk Action Boundaries
If an action requires current legal authority, access permission or safety-critical information and the system cannot establish currentness, the correct state may be:
HOLD — currentness not verified.
This is different from saying the old value is definitely false.
It says the current action cannot rely on it safely.
Historical Systems Need Stale Data Deliberately
Currentness does not mean deleting old state.
Historians, auditors and provenance systems need to know what the metadata said at earlier times.
A robust model distinguishes:
- current accepted value;
- historical values;
- validity intervals;
- revision reasons;
- currentness status.
A Better Metadata-Currentness Model
field value + provenance → observation time → validity rule → volatility/risk profile → refresh trigger → revalidation → current/historical/unknown state → downstream propagation → receiver/action gate
A 30-Lens Metadata Currentness Audit
- Resource: what object is described?
- Field: which value needs currentness?
- Value: what is asserted now?
- Observation time: when did evidence describe the world?
- Assertion time: when did the record receive it?
- Modified time: when was the record last edited?
- Valid-from: when did the value begin applying?
- Valid-to: when does it expire?
- Retrieved-at: when did this copy arrive?
- Volatility: how quickly can this field change?
- Risk: what happens if it is stale?
- Receiver: who is using it?
- Action: what decision follows?
- Threshold: how fresh must it be?
- Source authority: where is current state verified?
- Event trigger: what change notification exists?
- Schedule: what periodic recheck is justified?
- Demand recheck: should retrieval trigger validation?
- Failure: what if source is unavailable?
- Unknown state: can uncertainty be represented?
- Version: is this the current resource version?
- Rights: can access/reuse conditions change?
- Location: can URLs or endpoints move?
- Vocabulary: can controlled terms be deprecated?
- Schema: is field meaning versioned?
- Crosswalk: is translation mapping current?
- Canonical store: where is the authoritative value?
- Propagation: which copies remain stale?
- Historical retention: are superseded states preserved?
- World return: did live verification confirm the metadata at the action boundary?
Laboratory 1: Four Clocks
Create a record with an event date, observation date, assertion date and modification date. Change only the punctuation today. Explain why “last modified today” does not make the underlying fact newly observed.
Laboratory 2: Field-Specific Freshness
Give a record five fields: accession number, URL, rights, attribution and current version. Assign a refresh strategy to each and justify the different cadences.
Laboratory 3: Correction Propagation
Simulate a canonical correction at 10:00, a search reindex at 10:05, API cache expiry at 11:00 and external harvest at midnight. At each time, identify which receiver still sees stale metadata.
For Primary Readers
A class notice says the library closes at 5pm. It was true last term. Ask whether the notice is wrong, old or still current—and how you would check before walking there today.
For Secondary Readers
Separate modified-at from observed-at and explain why fields with different change rates need different freshness rules.
For Advanced Readers
Model metadata currentness as temporal applicability of value assertions under field-specific volatility and decision-risk constraints. A value remains historically valid even after it becomes operationally stale; currentness is therefore a relation among assertion, world state, time and receiver action rather than a permanent property of the string.
Common Misconceptions
- “Recently modified means recently verified.” Record edits and world observations are different clocks.
- “Old metadata is wrong.” It can be historically correct but stale for the present.
- “One refresh interval works for every field.” Volatility and consequence differ.
- “Fixing the canonical record fixes the ecosystem instantly.” indexes, caches and aggregators can remain stale.
- “Unknown currentness means the old value is false.” It means current applicability has not been established.
Research Corridor
- W3C — DCAT 3 — current/previous version relationships, version identifiers, version notes and catalogue metadata.
- DCMI Metadata Terms — date, modified, issued, valid, provenance and relation terms.
- W3C PROV-O — provenance and generation/derivation relationships.
- eduKateSG — How Metadata Works.
Frequently Asked Questions
What is metadata currentness?
It is whether a metadata value still applies to the resource state and decision context for which it is being used now.
Is “last modified” enough to measure freshness?
No. It records an edit to the metadata record, not necessarily a fresh observation or verification of the underlying field.
Should stale values be deleted?
Usually not when historical or audit value matters. Preserve prior states and validity periods while clearly identifying the current accepted value.
Final Thought: Metadata Has to Keep Up With the World It Describes
A description can be perfectly written and perfectly obsolete.
Current metadata is not metadata that was edited recently. It is metadata whose applicability to the present decision has been checked closely enough for the consequence at stake.
METADATA · FOUR PILLAR LEGS
Return to How Metadata Works, or continue through Metadata Provenance, Metadata Crosswalks and Schema Evolution. Return to the Information & Representation Hub.