If you need to translate PREMIS 3.0 preservation metadata, explain digital archive events in another language, or localize a preservation dashboard, the most important distinction is between the wording used to describe evidence and the evidence itself. A translated event label may help a curator understand that a file passed a fixity check. It must not change the digest, the event outcome, the date or the person or software responsible.
This longform guide shows how to work with PREMIS Objects, Events, Agents and Rights while protecting the historical record of digital preservation. It covers identifiers, relationships, actions, outcomes, software environments, fixity, format information, representation levels, migration history, rights statements, controlled vocabularies, XML mapping and multilingual audit interfaces. It is intended for librarians, archivists, repository developers, translators, preservation managers, students and readers trying to understand why preserving evidence is different from merely storing files.
The PREMIS Data Dictionary for Preservation Metadata, Version 3.0, maintained by the Library of Congress programme, provides a model for recording information necessary to support digital preservation. Its four entities are Objects, Events, Agents and Rights. The version 3.0 dictionary and supporting documentation are the reference for semantic units. An institution’s implementation profile determines which data it actually records, which fields it displays, and how its workflows create events. Translation should respect those decisions rather than treating every visible string as free prose.
Preservation metadata tells a story that must remain true
Consider a museum with a born-digital photograph made twenty years ago. The original file has been copied between storage systems, checked repeatedly for corruption and converted to a more accessible format. A curator opens a repository dashboard in French and sees messages about each step. The labels may be translated, but the events themselves must still describe the actions that really occurred. If a failed fixity check becomes a successful one because of a mistranslated status word, the dashboard tells a false history.
That is the difference between ordinary content translation and evidence-preserving localization. The user needs a readable explanation of what the system did, but the underlying event record needs to remain an accountable statement. Protect source values, keep their provenance and use controlled mappings for labels and messages. When the source evidence is uncertain or incomplete, the translation should also make that uncertainty visible.
The four PREMIS entities have different jobs
An Object is something being preserved or represented in the preservation environment. An Event is something that happened to an object or is otherwise relevant to preservation actions. An Agent is a person, organization or software agent associated with events or rights. Rights describes permissions or constraints pertinent to preservation activities. Together they support accountable information about what is held, what happened, who was involved and what actions are allowed.
The data model provides structure, not a guarantee of truth. A repository can store an incorrect agent identifier or an unjustified success outcome in formally well-structured metadata. Translators should not try to correct such records silently. They should preserve the evidence, flag anomalies and distinguish a localized explanation from an authorized change to the canonical event or rights record.
A preservation Object is not always the public item
People often say “the image” or “the book” as if a digital archive held one thing. In practice, there may be a representation of a work, several related files and smaller bitstreams within files. Preservation systems can reason at different levels of object granularity. A readable interface may choose a simple display name, but the underlying identifiers and relationships determine which exact bytes were checked or migrated.
Ask whether an event concerns a representation, a file or a bitstream. A checksum for a preservation master is not necessarily a checksum for its access derivative. A translation that collapses these objects into one generic “document” can make an operational report misleading. Use precise target-language terms and maintain object-type information, especially when reviewing complex formats with embedded resources.
Identifiers are the spine of the preservation record
PREMIS objects, agents and events can carry identifiers and identifier types. These values allow systems to refer unambiguously to the same entity over time. They are not candidates for stylistic translation. An accession number, UUID, repository key or local persistent identifier may look like meaningless text, but changing a character can disconnect years of preservation history.
Preserve identifier types, exact values and relevant scoping information. If an identifier cannot be resolved, record the issue without inventing a substitute. Multiple identifiers for one object may be legitimate and useful, especially across migrations or transfers between institutions. A translated dashboard should show the human-readable role of an identifier in the reader’s language while keeping its underlying value fixed for lookup and audit.
Fixity checks mean more than “the file looks fine”
Fixity information helps establish whether a particular file’s bytes match an expected digest. A checksum is not a linguistic approximation: its algorithm and value must remain exact. A preservation report that translates a checksum label but changes the digest is invalid. Equally, a successful fixity check is not proof that the file is understandable, complete in every cultural sense or the correct version of a resource.
Explain the scope of the check in plain language. The system compared bytes against an expected value at a particular time; that is narrower than guaranteeing all aspects of authenticity. If a source record reports a mismatch, the localized explanation must not soften it to “minor variation” without evidence. Preserve pass, fail, error and unknown statuses according to the actual controlled outcome codes used by the repository.
Object relationships show what changed and what did not
A preservation environment may relate an original file to a normalized derivative, a migrated file, a replacement storage copy or a larger representation. Those relationships help archivists understand why multiple versions exist. Translation must preserve the direction and type of each relationship. A file derived from an earlier one is not automatically identical to it; an access copy is not necessarily the preservation master.
When a user clicks “Previous version” or “Derived from” in a localized interface, the target object must remain correct. Avoid translating relationship codes in place. Instead, map each code to an approved label in the target language, and test a chain of at least three related objects. Confirm that the chronological and logical interpretation survives. The preservation history is meaningful only if its relationships remain trustworthy.
Events are recorded actions, not suggestions
An Event records something that occurred, such as ingestion, validation, migration, fixity checking, virus scanning, replication or another activity defined by a preservation workflow. The eventType value identifies what kind of action occurred. A translator may display a readable action name but should not replace it with a different action because the terms sound similar. “Format identification” and “format validation” are not interchangeable, for example.
When reading an event, look at its type, date or time, outcome, details, associated objects and linked agents. These pieces constrain one another. A successful file migration event should not be described as a successful format validation unless both actually happened. Each event label should be a faithful explanation of the stored action, not an invented narrative of what the system probably did.
Event dates belong to their recorded time context
A preservation event may be timestamped in UTC or another documented representation. Translating a dashboard into a new locale may change how the date is displayed, but the underlying event time should remain stable. A timezone conversion can legitimately change the displayed calendar day. That is different from altering the timestamp. Daylight-saving changes and ambiguous local times make careful display design essential.
Store and transport timestamps according to the system’s established date conventions. Show timezone information when it matters, especially in incident investigations and cross-institution transfers. Never insert the date of translation as the date of an historical preservation action. When the source only provides a date without a time, do not invent hours and minutes. Precision and uncertainty are parts of the event’s meaning.
Outcomes need exact, controlled interpretation
A validation tool may report “pass,” “fail,” “warning,” “inconclusive” or other outcomes defined by its application. These are distinct states. A human-friendly translation should explain the operational meaning of each one without changing the code. A “warning” must not become “safe,” and an “inconclusive” result must not be reported as a failure or success. A translation should never make action sound optional if a critical process actually stopped.
Build a status dictionary based on the repository’s controlled values and approved operating definitions. Test it with real historical records representing every supported outcome, not only successful events. Inspect how colors, icons, accessibility labels and notifications display those statuses. If a repository relies on a translated phrase as a programmatic status code, that design deserves revision: software should consume stable values and display localized explanations separately.
Event details often contain hidden technical constraints
An event detail may record tool output, parameters, source and destination paths, file format versions, validation profiles or exception reasons. Some of this is explanatory language; some is technical evidence. Blind translation can corrupt command-line options, exact error strings or parameter names. A diagnostic code should remain searchable in official documentation even when the human explanation is localized.
Divide details into machine tokens, quoted evidence and interpretive explanation. Keep the first two intact where their exact bytes are material. If a readable translation of an error message is useful, display it alongside the original diagnostic identifier or provide a separately stored explanation. That allows a technician to search logs accurately while a non-specialist understands what happened. Do not remove uncertainty from vague tool output.
Agents include people, organizations and software
An Agent may be a staff member who approved a migration, an institution that owns a repository, or a software program that performed a checksum verification. Their identities, types and roles should be preserved. Translating a product name into a descriptive phrase can make it impossible to know which tool version generated an event. Translating a person’s name literally is usually worse: it can misattribute responsibility.
Use stable identifiers where the source supports them and distinguish display names from authority references. A role label such as “operator,” “approver” or “automated validator” may be localized if its meaning is established. Do not infer that a human personally performed an action merely because their department sponsored the process. Preserve the distinction between a software agent executing work and a person responsible for institutional approval.
Software versions are part of reproducibility
A file may have been processed by a particular release of a migration utility or format-identification tool. Version information can explain differences in output and later discoveries about software defects. It is not ordinary text to translate. A translated interface can explain what the program does, but the tool name, version, configuration and execution outcome should stay accurate.
For complex preservation activities, retain a link to the relevant technical documentation or event details where available. If a translator cannot interpret an unusual configuration token, flag it for a preservation specialist instead of replacing it with an approximate adjective. Reproducibility may depend on a small distinction between two modes. The apparent fluency of a translation is not evidence that the operational meaning survived.
Format identification is not format conversion
A repository may identify a file’s format, validate it against a profile, normalize it, convert it to another format or extract metadata from it. These activities serve different purposes and may be separate events. Confusing “identified as TIFF” with “converted to TIFF” produces a false history. A preservation dashboard needs clear verbs and carefully translated status messages.
Check that the event type and outcome align with the source and resulting object relationships. If an original PDF was normalized into a different PDF profile, the target-language wording should not imply that the original was deleted or that all information remained perfectly equivalent. The repository may need quality review beyond file-format validity. Translate what is known rather than celebrating what has not been demonstrated.
Migration events demand special care
Migration can improve future accessibility, but it may also change the representation of a digital object. An archive might convert a legacy word-processing file to another format, preserving layout reasonably well while losing some interactive features. An event record should identify the action and link original and resulting objects. A translator must not substitute a reassuring statement such as “unchanged file” where the preservation process produced a transformed derivative.
Keep migration details, software versions, outcome codes and source-target relationships intact. If a post-migration review concluded that fidelity was acceptable under a defined policy, preserve the scope of that conclusion. Do not convert a limited success into a universal promise. International audiences deserve the same information about the transformation and its risks as readers of the source-language record.
Repairs and replacements are not the same as clean originals
Suppose a repository detects damaged bits and restores a file from a backup. The resulting file may match an earlier expected checksum, but a repair or recovery action still occurred. A localized interface should report the restoration rather than hiding it under a generic “stored” label. Preservation histories include failures and recoveries because they matter to later trust.
Preserve the incident date, affected object, source of recovery, agent and observed outcome. If the repository’s evidence does not establish that recovery was complete, do not declare it complete. Distinguish restoring exact original bytes from generating a usable replacement representation. For scholarly and legal contexts, these differences can be important. An archive gains credibility by documenting its intervention, not by pretending the intervention was unnecessary.
Rights is a separate entity with separate logic
PREMIS Rights expresses permissions and restrictions relevant to preservation activity. This is not automatically the same as a public Creative Commons licence or a website’s terms of use. A repository may be authorized to create preservation copies without having permission to release those copies publicly. A translation that conflates internal preservation rights with public reuse rights can cause a serious operational mistake.
Identify the basis, scope, actions, restrictions and relevant dates according to the repository’s rights model. Keep rights identifiers and authoritative legal references fixed. Translate explanatory labels carefully, preferably with approved wording. If a statement is ambiguous, require rights review instead of extrapolating. Users should not be led to assume that “preserved by the archive” means “free for everyone to download or republish.”
Rights restrictions must not become permissions
Words such as “may,” “must,” “must not,” “until,” “unless” and “subject to” are easy to gloss over in casual translation. In rights metadata, they can reverse what a repository is authorized to do. A translated statement must preserve the permitted action, the actor, the conditions and the time period. If access is restricted until a specific date, the interface must not imply unrestricted access today.
Separate the machine-readable permission or restriction from its human explanation. Validate the exact underlying code and constraint fields. Review examples at the boundary of an embargo and across different jurisdictions. Translation is not a legal determination; when rights are uncertain, say so and seek an authoritative decision. A rights system should never become more permissive merely because a target-language sentence sounds more natural.
The meaning of “authentic” has limits
A preserved file may pass checksums and schema validation while still having uncertain provenance or missing context. Authenticity is a broader scholarly and evidential claim than technical bit integrity. A PREMIS event can provide important evidence for that claim, but a single successful check does not settle every question about the object’s history. A translator should preserve careful language that distinguishes these levels.
Avoid inflating phrases such as “validated” into “proven authentic” or “verified original” when the source system only recorded a technical check. For digital art, oral histories and scientific records, context may be as important as bytes. Keep limitations visible in explanatory notes and quality reports. Readers should trust a preservation record because its claims are bounded and inspectable, not because every message is reassuring.
Controlled vocabularies need concept-level translation
Repositories may use controlled vocabularies for event types, object categories, relationships and outcomes. The visible English phrase attached to a code is not necessarily the only possible label, but its concept needs to remain the same across languages. Translate a label through the vocabulary’s definition and scope rather than a dictionary lookup. Some near-synonyms denote different preservation activities.
Keep coded values and vocabulary identifiers unchanged. Where authorized multilingual labels exist, use them. Otherwise document a local label and have domain specialists review it. Test mappings bidirectionally: a French or Japanese label should resolve to the same stable concept as the source phrase. Beware of local abbreviations that look identical across languages but refer to different workflows.
XML serialization and semantic meaning are different checks
PREMIS information can be represented in XML and may be linked or mapped through other semantic systems. A document can be well-formed while its event relationships are wrong. Conversely, a preservation application may store its canonical information in a database and generate XML only for exchange. The translator must know which representation is authoritative and which is an export.
When editing XML, protect namespace names, element names, identifiers and schema-defined values. Validate the chosen serialization, then validate entity references and semantic constraints according to local policy. Preserve character encoding and safe escaping for translated prose. Avoid making unsupported assumptions about which element can contain free text merely because it has a human-readable name.
PREMIS alongside METS is a division of responsibilities
METS can help organize digital object packaging and structural relationships. PREMIS describes preservation evidence, including events, agents and rights. A repository may embed or associate PREMIS metadata in a METS-managed package, but translating the METS structural labels does not mean translating the PREMIS event history. These tasks can share governance while retaining different acceptance tests.
Verify that event and object references still identify the correct files within the package. Preserve fixity details even if the package’s human-facing title is localized. Test that a curator can navigate from a file to its preservation history and back without seeing mismatched objects. Readers may encounter localized summaries while specialists need access to the exact provenance evidence. Both views should be consistent.
PREMIS alongside MODS preserves the cataloguing boundary
MODS is primarily descriptive: a title, creator, language or subject helps people find and understand a resource. PREMIS addresses what has happened to preserved digital objects and what preservation actions are allowed. An archive might update a MODS abstract in Spanish without performing any file migration. A new preservation event should not be invented merely because a catalogue description changed.
Maintain separate revision histories for descriptive metadata and preservation records, while linking them when appropriate. If a repository records metadata transformations as preservation-relevant events, follow its stated policy and evidence requirements. Do not assume every editorial update requires a PREMIS event, or that every PREMIS event should appear on a public item page. Different users need different portions of the record.
Case study: a recovered photograph
A digital repository detects a checksum mismatch on a high-resolution photograph. The archivist retrieves a verified copy from a secondary store, records a recovery event and reruns fixity checks. An English dashboard shows the steps. A translated dashboard must not turn “mismatch detected” into “minor formatting difference” or report that the original damaged file was never affected.
Keep the original failed event, the recovery action, the involved agents and the subsequent successful check separate. A public summary might say that the repository detected and recovered from a storage error, but it should not claim perfect continuity without the evidence. This is where preservation metadata becomes an operational and historical account. Translation should make the sequence understandable without rewriting it.
Case study: a video transcoding project
A museum migrates access videos from an older codec to a widely supported format while preserving the original masters. Tool logs record a transcode event, output formats, processing software and review outcomes. A translation that says “converted archival master” could imply the wrong object was changed. Similarly, saying that the conversion was lossless may be false unless the process and checks actually support that claim.
Distinguish originals, new derivatives and their relationships. Retain codec identifiers and tool versions. Translate an operator note only after checking whether it states a technical result or a subjective viewing assessment. Test a sample video with audio, captions and unusual frame-rate behavior. The translated preservation report should indicate what process ran and what evidence of success exists.
Case study: a research dataset with several versions
A university preserves a scientific dataset and releases a corrected version after discovering a labeling error. The revised dataset may have different content and a new persistent identifier; it is not simply a translated copy of the old one. Preservation metadata can help record version relationships and events. A localization project must not hide the correction by giving both versions identical labels without context.
Present the difference between revision of data, translation of documentation and copying of files. Keep dataset identifiers, checksums and lineage explicit. If a translation of the README was added, record it as a separate descriptive artifact or documented metadata change according to policy. A researcher using the dataset needs to know which values were analyzed and whether a published conclusion used the corrected version.
Case study: software agents and a failed validation
An automated validator reports that a deposited file does not conform to a stated format profile. A human operator later reviews it and authorizes restricted preservation despite the failure. Two agents and at least two distinct decisions are involved. If the translated report makes both actions sound like “approved,” it erases the difference between technical conformance and a documented policy exception.
Keep the validation outcome intact, record the later intervention and preserve the responsible agents. A user-facing description may say that the file was accepted under a documented exception, while the detailed history should still show the technical failure. The event timeline matters: an approval is not retroactive evidence that the prior test passed. This example illustrates why preservation localization needs precise verbs.
Case study: an embargoed oral history
An oral-history recording is preserved by an archive but restricted from public access until a specified condition is met. PREMIS rights information may support preservation decisions, while a separate access-control system enforces viewing restrictions. A translator could accidentally turn “preservation reproduction permitted” into “public copying permitted.” The resulting description would mislead users about their rights.
Keep legal grounds and scope distinct. Test the public interface against the actual access permissions. If the conditions depend on consent or institutional policy, use approved language and do not invent exceptions. The correct translation should make it possible to understand why the archive may maintain copies while the audience may not yet listen to the recording.
Case study: preserving a complex website
A web archive captures pages, images, scripts and external dependencies at several dates. The files may be technically intact but some live functions may no longer work. A preservation report can describe capture, format identification, fixity and replay tests without claiming that the original live experience has been recreated perfectly. Translating “replay partial” as “fully restored” would be misleading.
Explain what was captured, what the tests established and what remains uncertain. Preserve event times, tool versions, capture identifiers and relationships between versions. When a researcher switches languages in the archive’s own interface, it should not alter the source-language content of the historical website. The preservation record must distinguish the original web object from modern explanatory layers.
Prepare a preservation-specific translation brief
A useful brief specifies source metadata version, vocabulary authorities, entity identifiers, permitted prose fields, target languages, rights review and validation responsibilities. It explains which statements are audit evidence and which are editorial display explanations. It identifies how incident reports, error messages and software diagnostics should be handled. A general “keep technical terms accurate” instruction is insufficient.
Create a glossary for event types, outcomes, object categories, agent roles and rights concepts. Include definitions, not just translated words. Add deliberately difficult examples: failed fixity, uncertain outcome, partial migration, software error, unknown agent and expired rights restriction. Ask reviewers to explain the operational meaning of the translated phrase. If they cannot, the phrase may be fluent but unsafe.
Build a reference snapshot before localization
Export or record the canonical source preservation metadata with a timestamp and provenance. Count Objects, Events, Agents and Rights statements; capture their identifiers and relationships. Record protected values such as digests, format identifiers, timestamps and source paths. Define expected invariants for every localized output. An authorized correction to canonical evidence should be a separate, traceable action.
A reference snapshot is useful for later updates. When a preservation event is added next month, the translation may need a new label or explanation. Without a source snapshot, the team cannot tell whether a change reflects translation, repository maintenance or an incident. Revision control is especially important for collections transferred between systems or organizations.
Validate the event graph, not only the words
A strong check verifies that each Event still links to the correct Object and Agent, that Rights statements remain correctly scoped and that every preserved identifier remains unchanged. It also compares chronological order, semantic event types and outcomes. A simple line-by-line text diff will produce noise from formatting and word order; a normalized field-level comparison provides clearer evidence.
Then review the human interface. Can the preservation officer distinguish a failed scan from a successful one? Can they identify the agent involved? Can they find the original file and its derivatives? Can they see the rights conditions without interpreting a translated phrase as legal permission to distribute? These questions test the actual professional use of the metadata.
Validation should include negative examples
Most systems are demonstrated with successful preservation events, but meaningful quality assurance must include failure, warning, uncertainty and restricted-action examples. A localization that performs well only when everything went right is not reliable. Build test cases for missing agent identifiers, unsupported file formats, checksum mismatches, mixed success outcomes and rights restrictions with future dates.
Check the wording and interface behavior for each. Do not replace blank source data with a guessed default. Show “unknown” or “not recorded” when that is what the evidence supports. Error and uncertainty messages should remain clear, proportionate and actionable. Good translation is often most valuable during incidents, when ambiguity can waste time or prompt an inappropriate decision.
Human review and authority boundaries
A translator can judge language, but not necessarily whether a preservation event was warranted, a tool result is technically sound or a legal condition is enforceable. Preservation officers, repository engineers and rights specialists should review the parts within their authority. The translator should know whom to consult when an event is ambiguous or a term lacks an established target-language equivalent.
Keep decisions traceable. Record approved terms, rejected alternatives and the reason for uncertainty. If the source data appears inconsistent, escalate a source correction request rather than making an undocumented translation-side fix. This boundary protects both the archive and its readers. Preservation evidence should be corrected by accountable process, not improved by fluent prose.
Common errors and how to repair them
Typical mistakes include translating identifiers, reformatting digest values, converting timestamps without accounting for timezones, confusing a validation event with a migration event and flattening agent roles. Another is making rights statements sound more permissive than their original scope. A more subtle error is treating every technical success as evidence of complete authenticity. Repair begins by identifying the invariant: what exact source claim must survive?
Restore protected values, map controlled codes to reviewed labels, clarify which object an event concerns and rerun the semantic comparisons. Keep source-language diagnostic details available for technical investigation. Where a genuine source-record error exists, document and correct it through the repository’s approved workflow. Translation can illuminate a preservation history, but it cannot substitute for that history.
Frequently asked questions about PREMIS translation
Is PREMIS primarily a catalogue description format? No. It addresses preservation metadata. Descriptive records may be linked to it, but their responsibilities differ.
What are the main PREMIS 3.0 entities? Objects, Events, Rights and Agents. An implementation may represent additional relationships and details according to the dictionary and its profile.
Can I translate an eventType code? Preserve the controlled source value and use an approved localized display label. Do not change the actual event classification.
Can I say a file is authentic because its checksum passed? A successful check supports byte-level integrity relative to an expected value, not every broader claim about provenance or historical authenticity.
Should I translate software logs? Translate explanations where appropriate, but retain exact diagnostic codes, names, versions and evidence needed for reproducibility.
Does permission to preserve a file imply permission to publish it? No. Preservation rights and public access or reuse rights are distinct and may have different restrictions.
How should I translate a failed event? Preserve the actual outcome, degree of certainty and scope. A reassuring phrase that hides failure is not an accurate translation.
What is the best final test? Compare entity IDs, relationships, timestamps, statuses and rights constraints before and after localization, then verify that a preservation professional can interpret the same history correctly.
The professional objective
Digital preservation is a promise to future users that today’s evidence will remain interpretable and accountable. PREMIS helps document the work behind that promise. Multilingual interfaces can make the documentation accessible to more people, provided that translators preserve object identity, event history, agent responsibility and rights boundaries. The record should become easier to read, not easier to misunderstand.
Official standards and related explanations
Consult the PREMIS Data Dictionary for Preservation Metadata, Version 3.0 and the Library of Congress PREMIS programme for definitive semantic-unit descriptions and schemas. For related but distinct responsibilities, see the METS specification, the MODS 3.8 guidelines and the IIIF Presentation API. The existing PREMIS preservation-evidence overview provides a broader conceptual companion.