Archival Metadata Standards for Transcriptions

This is a working guide to the archival metadata standards that govern transcribed documents — what each one describes, which layer it belongs to, and how to combine them without asking one standard to do another's job. For cultural heritage professionals making holdings findable and durable, getting these layers straight is the difference between a record that lasts and one that quietly loses information.

Archival metadata is not a single standard but a layered ecosystem, and transcribed documents sit at the intersection of several layers at once. The essential distinction is functional. Description records what a document is — its provenance, creator, place in a collection. Transcription encoding records what it says — the text, with its deletions and expansions. Preservation metadata records how the digital object is maintained over time. No one schema handles all three. Choose standards by the concern you are actually addressing, and expect to combine descriptive standards like DACS or EAD3, an encoding standard like TEI P5 for the transcription itself, and PREMIS for preservation — each doing the job it was designed for.

This guide walks through those layers in the order they matter for a transcribed document, names the standard that owns each one, and flags the misconceptions that most often send projects down the wrong path. It sits within the broader practice of digitizing and describing collections, where metadata choices constrain — and are constrained by — every other step in the workflow.

Why "one standard for everything" is the wrong mental model

The most persistent error in describing transcribed material is expecting a single schema to cover it end to end. It cannot, because the standards were built by different communities to solve different problems. The finding-aid tradition (ICA, SAA) describes archival hierarchy: fonds, series, file, item. The text-encoding tradition (the TEI Consortium) captures editorial phenomena down to the character. The preservation community (Library of Congress, ISO) tracks fixity, events, and provenance of the digital file. These are complementary layers, not competing options.

Two consequences follow. First, a mature description of a transcribed document routinely uses three or four standards at once — and that is correct practice, not redundancy. Second, most of the recurring confusion in the field comes from treating a standard as if it belonged to a layer it does not. The sections below are organised by layer for exactly this reason.

Layer one: describing the document (descriptive standards)

Descriptive standards answer what is this, who made it, where does it sit in the collection. They govern the finding aid and the catalogue record.

ISAD(G) — the ICA's General International Standard Archival Description (2nd ed., 2000) defines 26 elements across seven information areas. ISAAR(CPF) (2nd ed., 2003) is its companion for authority records describing the creators of records — corporate bodies, persons, families.
DACS — the Society of American Archivists' Describing Archives: A Content Standard, the US content standard aligned with ISAD(G) and ISAAR(CPF); the 2022 version is current.
RAD — Library and Archives Canada's Rules for Archival Description, the Canadian equivalent.
Records in Contexts (RiC) — the ICA's successor conceptual model. RiC-CM v1.0 was published in 2023, with the RiC-O ontology reaching v1.1 in May 2025. RiC reconceives archival description as linked data rather than a hierarchy of finding aids.

A word of caution on RiC. It has, at the conceptual level, superseded ISAD(G) and ISAAR(CPF), and legacy descriptions built on those standards remain perfectly valid. But production-level uptake is thin: the deployments that exist are pilots — Archives Portal Europe, national-archive research projects — and no industry-wide adoption measurement is available. Treat RiC as the direction of travel, not as a requirement your institution has fallen behind on.

Layer two: encoding the description (structural encoding standards)

Where the descriptive standards above define content, encoding standards define the machine-readable structure that carries it.

EAD3 (v1.1.2, released June 2023, maintained by the Library of Congress with the SAA) is the XML finding-aid format derived from ISAD(G). EAC-CPF 2.0 (2022) is its authority-record counterpart, encoding creators.
MARC21 / MARCXML and MODS (v3.8) serve the bibliographic side; MODS is the richer XML schema.
METS binds descriptive, structural, and administrative metadata to the actual files — a wrapper rather than a description standard in its own right.

On EAD2002-to-EAD3 migration: no consolidated statistic exists. Repository disclosures suggest large national institutions have migrated while smaller repositories and some aggregators remain on EAD2002. If you are a small institution still on EAD2002, you are in ordinary company.

Layer three: encoding the transcription itself (TEI, ALTO, PAGE)

This is the layer that most directly concerns transcribed documents, and the one where the description-versus-transcription distinction earns its keep. EAD describes the collection; TEI encodes what the page actually says. They are complementary, not interchangeable — a point worth stating plainly, because conflating them is one of the most common mistakes in the field.

TEI P5 — the Text Encoding Initiative's P5 Guidelines — is the scholarly standard for the transcription text. It is an XML vocabulary for editorial phenomena at character level: deletions, additions, expansions of abbreviations, unclear readings, and manuscript description through the `<msDesc>` element. If you are producing a scholarly edition of a transcribed manuscript, TEI is where the editorial intelligence lives. Its cost is a genuine learning curve: the schema is large, projects typically use only a subset, and inter-edition inconsistency is a well-known consequence. Tooling like oXygen mitigates this but does not remove it.

ALTO XML and PAGE XML are a different animal, and the confusion here is worth correcting directly: neither is a description standard. ALTO (Library of Congress) is a layout format holding word- and line-level bounding-box coordinates alongside recognised text — it is OCR/HTR output, not a description of archival material. PAGE XML (PRImA Research, University of Salford) plays the equivalent role for HTR ground truth and layout export. Both answer where on the image is this text and what does it read, not what is this document.

The practical upshot: a single transcribed page can legitimately generate a TEI edition (for scholarship), an ALTO or PAGE file (as machine output preserving coordinates), and an EAD entry (in the finding aid) — three standards for one page, each serving a different consumer. No consolidated registry tracks which projects use TEI editions versus machine outputs for the same material, so do not assume one implies the other.

Where the transcription comes from — and why the source text matters here

Before any of this encoding applies, the transcription has to exist and has to be faithful. This is where the choice of transcription method has downstream metadata consequences that are easy to underestimate. A metadata layer is only as trustworthy as the text it describes, and the difference between OCR and HTR is not academic when the source is a manuscript hand or historical print — the distinction between the two determines what actually lands in your TEI `<supplied>` and `<abbr>` elements.

The specific risk is silent normalisation. General-purpose OCR is engineered for clean modern type; on early-modern material it tends to read the long s as f, split or drop ligatures, discard scribal and typographic abbreviation marks, and "correct" archaic orthography that was never an error. General-purpose LLMs introduce a subtler and more dangerous failure: they produce fluent, plausible readings that are wrong, and plausibility is precisely what makes a fabricated transcription hard to catch in review. Either failure mode corrupts your metadata at the source — you end up encoding, describing, and preserving a text that does not match the page.

This is where a purpose-built transcription tool earns its place in the pipeline. Leo's ATR-1 model is trained on images of historical documents to transcribe what is on the page rather than smooth it into modern prose: it preserves strikethroughs, marginal additions, editorial expansions, and archaic spelling rather than resolving them silently — which is exactly the material your TEI encoding needs to represent faithfully. On a randomised 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, ATR-1 scored roughly 5% character error rate — 61% fewer errors than the next-best model tested — with the full comparison across Transkribus, Claude, Gemini, and GPT documented in the benchmark. Leo exports to TEI (XML) directly, alongside Word, PDF, and HTML, so the faithful base transcription carries forward into the encoding layer rather than being retyped. It does not, however, produce ALTO or PAGE output, nor does it handle the IIIF or preservation layers below — those remain the province of the tools built for them. As users correct transcriptions, those corrections feed back into the model, so accuracy improves across releases. The point stands regardless of method: the text entering your metadata stack should be verified against the page.

Layer four: preservation metadata (OAIS and PREMIS)

Preservation is a distinct concern with its own standards, and one misconception here has real consequences: a transcription derivative needs preservation metadata of its own. When a transcription is a separately managed digital object, it is itself an Archival Information Package — it requires metadata describing its representation, the events that produced it (the HTR run, a fixity check), and its provenance.

OAIS (ISO 14721, third edition ISO 14721:2025) is a reference model, not a metadata schema. It defines roles (Producer, Management, Consumer) and information packages (SIP, AIP, DIP). You implement its concepts; you do not "fill in OAIS fields." The 2025 edition introduces preservation-watch concepts, though vendor conformance documentation has not yet caught up.
PREMIS — the Preservation Metadata: Implementation Strategies Data Dictionary, v3.0 (2015, still current) — is the schema that implements preservation metadata in practice, covering objects, events, agents, and rights.
MIX (NISO Metadata for Images in XML, v2.0) holds technical metadata for the image files themselves.

For a transcription pipeline, the practical rule is: record the provenance of the transcription as an event. Who or what produced it, when, from which source image, and against which model or process — this is exactly the information a future user needs to judge whether to trust the text.

Layer five: controlled vocabularies and dates

Interoperability rises sharply when names, places, subjects, and dates are drawn from shared authorities rather than free text.

Names and subjects: LCNAF (over 11 million name authority records), VIAF (aggregating national-library authority files), and LCSH for subjects.
Places, concepts, and artists: the Getty vocabularies — AAT (over 500,000 terms), TGN (over 2.7 million places), and ULAN. Known coverage gaps for non-Western, pre-modern, and indigenous material are real and not formally documented.
Languages: ISO 639, which is not one standard but several parts — ISO 639-1 (two-letter), 639-2 (three-letter), 639-3 (all languages), 639-5 (families). Pick the part your use case requires.
Dates: for historical material this matters more than it first appears. ISO 8601 handles ranges and some approximation, but the cultural-heritage community typically adopts EDTF — the Extended Date/Time Format (LC, 2019) — which extends ISO 8601 with qualifiers for uncertain and approximate dates: the `?` for uncertainty, `~` for approximation, and masked digits for unknown values. For a will "dated 159[?]" or a letter "circa 1640," EDTF lets you record the uncertainty as data rather than losing it to a guess.

Layer six: delivery and discovery

The final layer moves description and images outward, to users and aggregators.

IIIF — the International Image Interoperability Framework — defines APIs for image delivery, presentation manifests, and content search (Image, Presentation, and Content Search APIs, all at v3.0 / 2.0). A frequent misconception is that IIIF stores metadata; it does not. It delivers images and references your descriptive metadata, which still lives in EAD, MODS, or TEI. IIIF is well established — the consortium reports over 130 institutions implementing it — though Content Search API uptake specifically is uneven.
Aggregator profiles: the DPLA Metadata Application Profile and Europeana's EDM, harvested via OAI-PMH. DPLA aggregates over 53 million items; Europeana over 58 million.

Here lies the most consequential misconception of all: Dublin Core is not full description. The 15-element Dublin Core set is a deliberate minimum for cross-domain discovery and harvesting — exactly right for feeding an aggregator, wrong as your primary descriptive standard. When EAD3 or MODS is flattened to Dublin Core for harvesting, archival-specific granularity collapses, typically into a single `dc:description`. The qualitative loss is well documented; no published study quantifies it. The rule: describe richly in EAD/MODS/TEI, and map down to Dublin Core for discovery — never the reverse.

Putting the layers together

A single transcribed manuscript, fully handled, touches every layer: a DACS-compliant description encoded in EAD3; a TEI P5 edition of the transcription with its expansions and deletions marked; possibly an ALTO or PAGE file preserving the machine output and coordinates; PREMIS metadata documenting the transcription as a preserved object with its own provenance; authority-controlled names and EDTF-qualified dates; and IIIF delivery with a Dublin Core crosswalk for the aggregators. That is not over-engineering. It is what it takes to make a transcribed document findable, citable, trustworthy, and durable.

Most institutions will not implement all six layers at full depth, and they do not need to. Small repositories often implement the descriptive and discovery layers well and rely on national or aggregator infrastructure for preservation — a reasonable division of labour. The discipline that matters is knowing which layer a given standard belongs to, so that you never ask Dublin Core to do TEI's job, or expect IIIF to be your catalogue. Get the layers straight, keep the transcription faithful to the page, and the standards stop competing and start doing the work each was built for.

Frequently Asked Questions

What are the archival metadata standards for transcribed documents?

Transcribed documents draw on a layered set of standards rather than one schema, because each layer answers a different question. Descriptive standards — ISAD(G), DACS, RAD, or the newer Records in Contexts — record what a document is and where it sits in a collection. Encoding standards like EAD3 and MODS carry that description in machine-readable form. TEI P5 encodes the transcription text itself, while ALTO and PAGE hold machine output and coordinates. PREMIS handles preservation, controlled vocabularies govern names and dates, and IIIF plus Dublin Core manage delivery and discovery. Each does the job it was built for.

What is the difference between description and transcription in archival metadata?

Description records what a document is — its provenance, creator, and place in a collection — while transcription encoding records what it says, the actual text with its deletions, additions, and expanded abbreviations. These are complementary layers, not interchangeable ones. EAD describes the collection; TEI P5 encodes what the page reads at character level. Conflating them is one of the most common mistakes in the field. A single transcribed page can legitimately have both: an EAD entry in the finding aid and a TEI edition of its text, each serving a different consumer.

Is Dublin Core enough to describe an archival collection?

No — Dublin Core is a deliberate minimum for cross-domain discovery and harvesting, not a primary descriptive standard. Its 15-element set is exactly right for feeding an aggregator but wrong as your main description. When richer formats like EAD3 or MODS are flattened to Dublin Core, archival-specific granularity collapses, often into a single `dc:description` field. The working rule is to describe richly in EAD, MODS, or TEI and map down to Dublin Core for discovery — never build up from Dublin Core as your foundation. Doing the reverse loses information that the fuller standards were designed to preserve.

Do ALTO and PAGE XML describe archival documents?

No — neither ALTO nor PAGE is a description standard. ALTO, maintained by the Library of Congress, is a layout format holding word- and line-level bounding-box coordinates alongside recognised text; it is OCR/HTR output. PAGE XML, from PRImA Research at the University of Salford, plays the equivalent role for HTR ground truth and layout export. Both answer where on the image is this text and what does it read — not what is this document. That descriptive question belongs to EAD, MODS, or DACS. Treating a machine-output format as a description standard is a common and correctable mistake.

Does a transcription need its own preservation metadata?

Yes — when a transcription is a separately managed digital object, it is itself an Archival Information Package and needs preservation metadata of its own. It requires records describing its representation, the events that produced it — such as the HTR run and fixity checks — and its provenance. PREMIS is the schema that implements this in practice, covering objects, events, agents, and rights, while OAIS provides the reference model behind it. The practical rule for a transcription pipeline is to record its provenance as an event: who or what produced it, when, from which source image, and against which model — the information a future user needs to judge whether to trust the text.