The field says:
creator = Jane Tan
That looks precise.
But who entered it?
Was it copied from the title page, supplied by the publisher, inferred by an AI system, imported from another catalogue, or corrected by a curator after new evidence appeared?
Metadata provenance is the lineage of the description itself: who or what supplied a value, from which source, through which activity, at what time, and with what transformations or evidence.
This is the first pillar beneath How Metadata Works. The master owns structured description as a whole. This article isolates value-level lineage: how a metadata statement acquires authority, how that authority can be checked, and how a record can change without pretending its previous state never existed.
Quick Read
A metadata field is a claim about a resource, not truth merely because it occupies a structured slot. Provenance records how that claim entered the system. W3C PROV provides a general model built around entities, activities and agents, including relationships such as prov:wasGeneratedBy, prov:wasAttributedTo and prov:wasDerivedFrom. For metadata, that means a value can carry a lineage from source evidence through extraction, mapping, human review, transformation and correction. Good provenance distinguishes resource provenance from metadata-record provenance, preserves prior values when corrections matter, and gives downstream systems enough context to judge whether a field is authoritative for the decision at hand.
resource evidence → source record → agent/activity → asserted value → transformation → metadata record → correction → current value + preserved lineage
Metadata Is a Layer of Claims
Title.
Creator.
Date.
Rights.
Subject.
Attribution.
Each field is an assertion about the resource.
Structure helps machines process the assertion. Structure does not prove the assertion.
This is why the Metadata master already makes the distinction:
valid metadata ≠ true metadata.
Provenance supplies the missing question:
Where did this value come from, and what happened to it on the way here?
Resource Provenance and Metadata Provenance Are Different
Dublin Core’s dcterms:provenance is defined around changes in ownership and custody of a resource that matter for authenticity, integrity and interpretation.
That is important resource provenance.
But a metadata system often needs an additional provenance question:
Who supplied the value now occupying this field?
A painting can have one chain of physical custody while its current attribution field has another chain of scholarly evidence and editorial action.
Do not collapse the two lineages.
A Metadata Value Can Have Its Own Source
Consider:
dateCreated = 1912
Possible sources include:
- a date printed on the object;
- an accession register;
- a catalogue raisonné;
- a previous museum record;
- an expert estimate;
- automated OCR;
- a user submission.
The same value can have very different evidential weight depending on its source and method.
W3C PROV Gives Us a Useful Grammar
The W3C PROV namespace describes provenance using entities, activities and agents.
- Entity: a thing whose provenance we are describing, such as a metadata record or extracted value.
- Activity: something that happened, such as OCR extraction, schema mapping, human review or merge.
- Agent: a person, organisation or software system associated with the activity or entity.
Relationships such as wasGeneratedBy, wasAttributedTo and wasDerivedFrom let systems express the chain explicitly.
“Was Derived From” Is Not “Was Copied Exactly”
A derived value may have been transformed.
A date string becomes an ISO date.
A free-text author name becomes a linked ORCID identity.
A subject phrase becomes a controlled-vocabulary concept.
A translation is added.
Lineage should therefore distinguish direct quotation, extraction, normalisation, inference, enrichment and correction where those distinctions matter.
Extraction Is an Activity
An OCR system reads a scanned title page.
It produces:
title = The History of Singapore
That field should not silently become equivalent to “the publisher asserted this title.”
A provenance-aware record can preserve:
- source image ID;
- OCR engine/version;
- extraction timestamp;
- confidence score if meaningful;
- whether a human reviewed the output;
- the final accepted value.
Human Review Is Another Activity
A cataloguer sees that OCR read “Sinqapore.”
They correct it to “Singapore.”
The correction should improve the current value without erasing the fact that the value was human-reviewed.
The review itself becomes provenance.
Authority Can Attach to the Agent
A field supplied by an authorised registrar may outrank a public suggestion.
A taxonomic name supplied by a specialist curator may outrank an automated classifier.
A rights statement supplied by the rights holder may outrank an inferred licence.
Provenance does not mean “trust the human.”
It means expose enough responsibility and source context that trust can be judged rather than assumed.
Automated Metadata Needs Provenance More, Not Less
AI can extract:
- titles;
- names;
- dates;
- locations;
- subjects;
- relationships.
The output may be useful at scale.
It may also be uncertain.
Store the model-produced value without model/version/source context and downstream users can mistake a machine inference for a curator assertion.
automation should reduce labour, not erase epistemic lineage.
Confidence Belongs Beside Provenance, Not Instead of It
“Confidence = 0.93” looks scientific.
But confidence in what model?
Calibrated on which distribution?
For which class?
At which software version?
A numeric score without lineage can be less useful than a categorical statement with a clear evidence source.
Evidence and Provenance Are Related but Not Identical
Provenance says where the claim came from.
Evidence says why the claim should be believed.
The two often travel together.
A curator may cite an X-ray analysis.
An automated entity linker may cite a source record and matching rule.
How Citation Works owns the general claim-to-source route. Metadata Provenance owns how that route became attached to this particular field through a maintained record process.
One Record Can Contain Values From Many Provenance Chains
Title from publisher feed.
Subject headings from a librarian.
Coordinates from a geocoder.
Rights from legal staff.
Thumbnail generated automatically.
A record-level provenance statement such as “imported from System A” may be too coarse when individual fields have different origins.
Field-Level Provenance Costs More
Recording provenance per value increases:
- storage;
- model complexity;
- API complexity;
- merge logic;
- user-interface burden.
Not every catalogue needs maximal granularity.
The right granularity depends on consequence.
High-risk attribution, rights, medical, legal or scientific metadata often justifies finer lineage than low-risk descriptive tags.
Merge Is Where Provenance Becomes Essential
Catalogue A says:
creator = Jane Tan
Catalogue B says:
creator = J. Tan
An entity-resolution process concludes they are the same person and writes an ORCID-backed canonical value.
The merged value should preserve its derivation from both source records and the reconciliation activity.
Conflict Is Information
Catalogue A says 1912.
Catalogue B says 1914.
Do not force one value merely because the schema allows only one.
The conflict may reveal:
- different event semantics;
- different evidence quality;
- a genuine scholarly dispute;
- an outdated record;
- a transcription error.
Provenance lets the system preserve the disagreement until it can be resolved responsibly.
Correction Should Create History, Not Amnesia
Yesterday:
attribution = Artist A
Today:
attribution = Workshop of Artist B
For the current public record, the new value may be correct.
For scholarship, audit and explanation, the superseded value and reason for change may remain important.
The system should distinguish:
- current accepted value;
- previous value;
- change date;
- agent/activity responsible;
- supporting evidence;
- whether the old value was wrong, uncertain or simply superseded by a more precise statement.
Revision Is Not Deletion
W3C PROV includes derivation and revision relationships precisely because one entity can emerge from another through an activity.
A revision history lets a record become more accurate without pretending the metadata system always knew the current answer.
Currentness Needs Provenance Too
A value was accurate when observed in 2022.
The resource changed in 2025.
The value is now stale.
The second pillar, Metadata Currentness, owns how observation time, modified time, validity windows and refresh triggers determine whether old provenance is still sufficient for a present decision.
Crosswalks Should Preserve Provenance of Mapping
Source field:
author
Target field:
creator
Who decided they are equivalent?
Under which schema versions?
Is the mapping exact or approximate?
The third pillar, Metadata Crosswalks, owns semantic loss during schema translation. Provenance records which mapping rule produced the target value.
Schema Evolution Makes Old Provenance Ambiguous Unless Versions Are Kept
Field date meant publication date in schema v1.
In v2 it is deprecated in favour of dateIssued and dateModified.
An old record saying “2024-05-01” cannot be interpreted safely unless we know which schema version governed it.
The fourth pillar, Schema Evolution, owns that lifecycle.
Provenance Must Survive Serialisation Changes
RDF today.
JSON-LD tomorrow.
Relational export next year.
Changing syntax should not erase the semantic lineage of the value.
Provenance is part of the metadata model, not decoration attached to one serialisation.
Search Indexes Should Not Become the Provenance Owner
A search index copies a title and creator from the canonical metadata record.
The index can record where the fields came from operationally, but it should not silently become the authoritative place to edit their provenance.
The master remains:
search index ≠ authoritative metadata store.
APIs Should Expose Enough Lineage for Their Use Case
A public discovery API may expose only:
- current value;
- source organisation;
- last reviewed date.
An internal audit API may expose the full event history.
Representation can vary by receiver while the underlying lineage remains intact.
Provenance Can Be Too Detailed to Be Useful
Every keystroke.
Every cache read.
Every internal function call.
That level of trace can overwhelm the actual decision.
Useful provenance captures events that change interpretation, authority, evidence or reproducibility.
provenance granularity should follow epistemic consequence.
Privacy Can Limit Provenance Exposure
An internal curator identity may be needed for audit.
Publishing that person’s private email address is not.
Provenance systems should distinguish accountability from unnecessary personal-data exposure.
Provenance Can Itself Be Wrong
The system says a field came from Catalogue A.
In reality it was manually edited later.
Provenance is metadata too.
It needs validation, access control, timestamps, versioning and audit just like any other important metadata.
A Better Metadata-Provenance Model
resource evidence → source entity → extraction/assertion activity → responsible agent → value → transformation/merge → review → current accepted value + prior states → downstream use → correction feedback
A 30-Lens Metadata Provenance Audit
- Resource: what object is being described?
- Field: which property is under review?
- Value: what is currently asserted?
- Source entity: where did the value originate?
- Primary source: is direct evidence available?
- Agent: who or what supplied it?
- Authority: what role justified that agent?
- Activity: extraction, import, inference, merge or edit?
- Method: how was the value derived?
- Software: which tool/model/version?
- Timestamp: when was it asserted?
- Observation time: when did the evidence describe the world?
- Confidence: is uncertainty represented?
- Evidence: what supports the value?
- Citation: can the evidence be resolved?
- Transformation: was text normalised or mapped?
- Crosswalk: was the field translated from another schema?
- Source version: which record version was used?
- Schema version: which property semantics applied?
- Conflict: do alternate values exist?
- Resolution: who chose among them?
- Previous value: is superseded state preserved?
- Reason: why was a correction made?
- Currentness: is the evidence still applicable?
- Downstream copies: where has this value propagated?
- Privacy: which agent details may be exposed?
- Integrity: can provenance itself be altered silently?
- Granularity: is lineage detailed enough for consequence?
- Auditability: can the derivation be reconstructed?
- World return: does independent evidence confirm the current value?
Laboratory 1: One Field, Four Sources
Create four candidate creator values: one from OCR, one from a publisher feed, one from a librarian and one from a user suggestion. Design a provenance record that lets a downstream reviewer compare them without losing their origins.
Laboratory 2: Museum Reattribution
Begin with “Artist A,” introduce new technical evidence supporting “Workshop of Artist B,” then record the revision without deleting the historical attribution. Which parts belong to object provenance and which to metadata provenance?
Laboratory 3: AI Extraction Receipt
Imagine an AI extracts five fields from a scanned document. Write the minimum lineage needed for a human reviewer to distinguish source evidence, model inference, model version and final accepted value.
For Primary Readers
If a class poster says “The trip is on Friday,” ask who wrote it and where they got the date. The sentence is the metadata value; the answer trail is its provenance.
For Secondary Readers
For every important metadata field, distinguish value, source, agent, method, evidence and update history.
For Advanced Readers
Model metadata provenance as a graph of entities, activities and agents where value assertions are derived, attributed and revised under explicit schema versions. Authority should attach to evidence and governed roles rather than to field presence alone.
Common Misconceptions
- “If a field is structured, it is authoritative.” Structure says how a claim is represented, not why it is true.
- “Resource provenance and metadata provenance are the same.” The object’s custody history and the description’s assertion history can differ.
- “A confidence score replaces provenance.” A number without source, method and calibration context can be misleading.
- “Correcting metadata means deleting the wrong old value.” High-value systems often preserve superseded states and reasons for change.
- “AI-generated metadata needs less provenance because it is automated.” Automation increases the need to preserve source, model and review boundaries.
Research Corridor
- W3C PROV Namespace — entities, activities, agents, attribution, generation and derivation.
- W3C PROV-O — provenance ontology for interoperable provenance descriptions.
- DCMI Metadata Terms — current Dublin Core metadata vocabulary including provenance and version relationships.
- eduKateSG — How Citation Works.
Frequently Asked Questions
What is metadata provenance?
It is the lineage of a metadata statement or record: where its values came from, who or what produced them, which activities transformed them and how they were corrected or derived.
Is provenance the same as citation?
No. Citation points a claim toward a source. Provenance describes the broader process through which a value or record was generated, attributed, transformed or revised.
Should every metadata field have full provenance?
Not necessarily. Provenance granularity should match consequence, audit needs and cost. High-risk or disputed values deserve finer lineage than routine low-risk descriptive fields.
Final Thought: A Field Becomes Trustworthy When Its History Is Inspectable
The catalogue says what it believes now.
Provenance explains how it came to believe it.
The strongest metadata system does not merely present a clean answer. It preserves the route by which that answer became current, corrigible and accountable.
METADATA · FOUR PILLAR LEGS
Return to How Metadata Works, or continue through Metadata Currentness, Metadata Crosswalks and Schema Evolution. Return to the Information & Representation Hub.