The Gold Standard of Information | PREMIS Events, Agents, Objects and Preservation Evidence

Digital preservation needs more than a file and a checksum. A future reader may need to know which representation the file belongs to, whether it was migrated, what software ran the action, which outcome was recorded, what rights allowed the action and how the transformed object relates to its source.

PREMIS provides a shared preservation-metadata vocabulary around Objects, Events, Agents and Rights. This guide turns that vocabulary into an evidence practice. It is narrower than the broader preservation-engineering root: the focus is how a repository records actions and relationships so that later custodians can reconstruct and challenge preservation history.

Choose a reading route

Open the full chapter index · Use the field check · Return to the Information root

Chapter contents

Chapters 1–3 · Entity model and scope

1. 1. Use PREMIS as preservation evidence, not a descriptive catalogue
2. 2. Distinguish representation, file and bitstream Objects
3. 3. Record Events as assertions about actions and outcomes

Chapters 4–6 · Identity and linked evidence

1. 4. Create identifiers that survive local system change
2. 5. Use relationships and roles to reconstruct provenance
3. 6. Worked example: document a fictional format migration

Chapters 7–9 · Implementation and controlled extension

1. 7. Separate event outcome from later acceptance
2. 8. Represent Agents and event-specific roles
3. 9. Record Rights that govern preservation actions

Chapters 10–12 · Exchange, governance and audit

1. 10. Use extensions and controlled vocabularies without semantic drift
2. 11. Exchange PREMIS without confusing serialization and meaning
3. 12. Audit preservation evidence as a connected history

PREMIS is designed to support long-term usability of digital objects by recording preservation-relevant facts. It does not replace descriptive, structural, rights-management or discovery metadata systems. Its value appears when a custodian must explain an action, result, relationship or permission years after the original operator has left.

Start with a preservation question: can the repository prove which bytes were received, what checks ran, which derivative was produced, whether the action succeeded and which agent was responsible? Map each needed fact to an entity and semantic unit. Keep descriptive subjects and audience-facing labels in their appropriate schemas rather than forcing everything into PREMIS.

A fictional archive receives a scanned book. The title and creator belong in descriptive metadata. PREMIS records the file objects, ingestion and fixity events, software agent, outcomes, relationships and permission basis needed to preserve and deliver them.

Changed-context transfer check

Transfer the distinction to a research dataset. Decide which fields help discovery and citation and which fields prove preservation actions and custody.

Limit and misconception

A record can be syntactically valid PREMIS while omitting evidence needed by the designated community or local policy. Standard vocabulary does not guarantee adequate preservation.

Evidence practice

Keep a question-to-entity map and a documented boundary with adjacent metadata. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: using PREMIS as a universal container and losing the meaning of specialised metadata. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Next chapter

The Object entity can describe an intellectual entity, representation, file or bitstream according to the implementation and version. A representation is the set of files needed to render or understand an intellectual entity; a file is a named sequence of bytes; a bitstream is contiguous or logically defined data within a file. Choosing the wrong level makes relationships and events misleading.

Inventory what the repository preserves and at which granularity actions occur. If a migration transforms a file, link the file-level inputs and outputs. If validation concerns a representation, record the complete set and dependencies. Use bitstreams only when embedded components require separate preservation treatment.

A preservation package contains a PDF, OCR XML, page images and fonts. The complete access representation depends on several files. A fixity event can target individual files, while a representation-level validation may assess whether all required components are present and usable.

Changed-context transfer check

Apply the levels to a video container with audio, video and caption streams. Explain when stream-level metadata adds value and when it becomes unsupported detail.

Limit and misconception

Granularity should follow preservation responsibility, not the maximum detail a tool can emit. Excessive object fragmentation can make history impossible to navigate.

Evidence practice

Keep an object inventory with declared level, identifier, dependencies and preservation purpose. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: treating one convenient file as the whole representation when required components are separate. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Next chapter

An Event records something that happened to one or more Objects at a time, such as ingestion, fixity checking, validation, migration, normalisation, virus checking or deletion. Event type, datetime, detail, outcome and linked entities together form an assertion. The event should be specific enough that a later reviewer understands what was attempted and what resulted.

Assign an event identifier, controlled event type, timestamp with known precision, event detail describing the action and parameters, outcome information and links to affected Objects and Agents with roles. Separate one action from a workflow summary when different steps can fail independently.

A batch job both validates and migrates a file. Recording one event called “processed” hides whether validation passed before migration and which output belongs to which step. Two linked events preserve the sequence and separate outcomes.

Entity	Core question	Typical evidence
Object	What digital thing is being preserved?	Identifier, level, format and relationships
Event	What happened, when and with what outcome?	Action, parameters, report and status
Agent	Who or what acted?	Person, organisation or software identity
Rights	What permission or constraint governed the action?	Basis, act, term and restriction

Changed-context transfer check

Adapt the pattern to a scheduled fixity campaign covering one million files. Decide what belongs in a batch event and what must remain at object level.

Limit and misconception

An event is a repository assertion, not proof by itself. Logs, reports, checksums and tool versions provide corroborating evidence and should remain traceable.

Evidence practice

Keep the event record, targeted objects, parameters, outcome and linked operational evidence. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: using vague event types or one success flag for a multi-step workflow. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Next chapter

PREMIS identifiers distinguish entities within an implementation. An identifier normally has a type and value whose interpretation is governed locally or by an external scheme. Stability depends on governance: a database key that changes during migration is not a durable identity merely because it is numeric.

Define identifier schemes, uniqueness scope, assignment authority, persistence policy and replacement rules. Keep repository IDs distinct from filenames and storage locations. When systems migrate, preserve prior identifiers as alternate or related values and document the mapping rather than silently overwriting history.

A file moves from one storage platform to another. Its path changes and a new internal row key appears, but the preservation object identifier remains stable. Storage-location metadata changes through a documented event.

Changed-context transfer check

Transfer the rule to a collection merger where two institutions used the same local number. Design a namespaced mapping that avoids accidental identity collapse.

Limit and misconception

Persistent identifiers reduce ambiguity but do not prove two records describe the same intellectual object. Identity decisions still require documented evidence.

Evidence practice

Keep the identifier registry, scope, assignment log and migration crosswalk. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: using a mutable path or database row number as the only object identity. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Next chapter

PREMIS relationships connect Objects to other Objects and link Events and Agents through roles. A relationship should state its type, subtype or role with enough specificity to distinguish derivation, structural dependence, membership and responsibility. Provenance is reconstructed from these links, not from chronology alone.

For every derivative, identify source and outcome Objects and record the Event that connects them. Link the software, organisation or person as Agents with event-specific roles. Avoid creating a generic “related to” edge when the preservation question needs “was derived from”, “is part of” or “validated by”.

A TIFF master produces a JPEG access file. The migration or derivative-creation Event links both Objects, while the imaging tool is an executing software Agent and the archive is the authorising organisation. The JPEG filename alone does not carry this provenance.

Changed-context transfer check

Change the case to a package assembled from several source files. Explain how membership and derivation relationships differ.

Limit and misconception

A dense relationship graph can still be wrong. Direction, role and version must be reviewed, and circular derivation should trigger investigation.

Evidence practice

Keep typed relationship records with source, target, role, event and validation checks. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: inferring provenance from timestamps or filenames while omitting explicit relationship roles. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Next chapter

A fictional repository holds a word-processing file in an ageing format. Policy permits creation of a preservation derivative while retaining the source. The repository selects a tested conversion tool, freezes the input, records pre-action fixity and creates a new preservation Object.

The migration Event records tool parameters, start time, source and output links, executing software Agent and responsible organisation. A separate validation Event tests the output against format and local significant-characteristic rules. The outcome notes one font substitution, so the process is not labelled unqualified success.

The repository retains the source, migrated output, reports and comparison images. Reviewers approve the derivative for preservation use but keep the exception visible. A later migration can trace both lineage and unresolved risk.

Step	PREMIS focus	Evidence kept
Freeze input	Source Object and fixity Event	Digest, timestamp and custody
Convert	Migration Event and software Agent	Tool version, parameters and log
Validate	Validation Event and outcome	Tests, exceptions and report
Accept	Relationship and policy decision	Reviewer, date and retained source

Changed-context transfer check

Change the case to a spreadsheet whose formulas must remain executable. Identify additional significant characteristics and validation evidence.

Limit and misconception

The example is fictional. Real migration acceptance requires format expertise, rights review and repository policy; PREMIS does not prescribe the correct preservation action.

Evidence practice

Keep input and output Objects, migration and validation Events, Agents, reports and acceptance decision. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: recording only the output file and a success label while discarding the source or exception. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Next chapter

An action can complete technically while failing policy, and a tool can report warnings that require human review. Event outcome should preserve what the action reported. Acceptance is a distinct repository decision with its own basis and responsibility.

Design controlled outcomes such as success, partial success, failure and not evaluated, but retain detailed messages and machine reports. State who or what generated each outcome. Record the later acceptance, rejection or quarantine decision separately when policy judgement is required.

A validator exits successfully but reports an embedded font mismatch. The validation Event preserves that warning. A reviewer decides the representation is acceptable for one use but not for authoritative reproduction.

Changed-context transfer check

Transfer the distinction to a checksum scan in which three files were unavailable. Decide how campaign completion and object-level outcomes should be reported.

Limit and misconception

Reducing outcomes to green and red destroys useful uncertainty. Conversely, copying an opaque log without a normalised outcome prevents reliable summary.

Evidence practice

Keep normalised outcome, detailed report, decision owner and acceptance rationale. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: conflating tool completion, preservation validity and institutional acceptance. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Next chapter

Agents may be people, organisations, software or other acting entities. The same Agent can play different roles in different Events, so role belongs with the relationship to the Event rather than becoming a permanent label on the Agent.

Assign stable Agent identifiers and record name, type and version where applicable. Link each Event to Agents using controlled roles such as executing program, implementer, authoriser or validator. Avoid unnecessary personal data and keep responsibility at the right organisational level.

A conversion service version 4.2 executes migration, a repository team authorises the workflow and a curator reviews the exception. These are distinct roles attached to one or more Events.

Changed-context transfer check

Apply the pattern to an automated cloud service that changes versions without notice. Specify what version or environment evidence the repository must capture.

Limit and misconception

An Agent record is not an authentication or accountability system. Access control, signatures and employment records remain separate controls.

Evidence practice

Keep agent identifiers, types, versions and event-role links with privacy review. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: putting all responsibility on a generic username or treating software name as a complete environment. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Next chapter

The Rights entity can record the basis on which a repository may perform preservation actions, along with acts, terms, restrictions and linked Objects or Agents. It supports operational clarity but does not replace legal advice or the full rights-management record.

For each preservation action, identify the rights basis, permitted act, start and end dates, restrictions, documentation reference and applicable objects. Keep uncertainty explicit. Link changes in permission to Events or policy decisions so an expired or superseded basis is not silently reused.

A deposit agreement permits migration and controlled copying for preservation but limits public dissemination. The repository records the preservation permissions without implying a broader licence to publish.

Changed-context transfer check

Change the case to software preservation requiring emulation. List which acts and restrictions need separate review.

Limit and misconception

A PREMIS Rights record describes an institutional assertion. It does not make an unlawful act lawful or settle ambiguous ownership.

Evidence practice

Keep the rights basis, permitted act, term, restriction, source document and review owner. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: treating permission to preserve as permission to provide unrestricted access. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Next chapter

PREMIS supports implementation choices and extension mechanisms because repositories need domain-specific detail. Extensions remain useful only when their namespace, version, ownership and relationship to PREMIS semantic units are governed. Uncontrolled local fields can fracture exchange.

Prefer official or community vocabularies for event types and roles when they fit. For local terms, publish definitions and mappings, version changes and retirement rules. Validate syntax and semantics separately: schema-valid XML or RDF can still misuse a term.

Two repositories both record an event called “normalisation”; one means lossless packaging and the other means format conversion. A vocabulary definition and crosswalk reveal the mismatch before records are merged.

Control	Question	Failure caught
Namespace	Who defines this term?	Name collision
Version	Which meaning applied at event time?	Silent semantic change
Mapping	What equivalence is actually claimed?	False crosswalk
Example	Can another repository reproduce interpretation?	Documentation-only interoperability

Changed-context transfer check

Transfer the problem to a local outcome code used across three systems. Design a mapping that preserves distinctions rather than forcing false equivalence.

Limit and misconception

Vocabulary alignment is not automatic interoperability. Implementers must test examples, edge cases and version transitions.

Evidence practice

Keep namespace, vocabulary version, term definitions, mappings and validation cases. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: adding local fields without ownership or mapping and later assuming identical labels share meaning. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Next chapter

PREMIS can be serialized in XML or expressed through RDF and related models. Serialization determines how records travel; the data model determines what they mean. A successful parse does not show that identifiers resolve, relationships are coherent or events carry adequate evidence.

Declare the PREMIS version, serialization profile, namespaces, local extensions and package boundary. Validate syntax, then test referential integrity, controlled terms, object-event-agent links and required local evidence. Preserve the original exchange package and validation report.

A repository imports schema-valid PREMIS XML whose event links point to unknown Objects. Syntax passes but the preservation history is incomplete. The importer quarantines the record and requests the missing identifiers.

Changed-context transfer check

Adapt the test to an RDF graph in which two URI schemes identify the same software Agent. Explain how reconciliation can preserve provenance.

Limit and misconception

Round-trip success can conceal loss if one system ignores repeatable fields, roles or extensions. Compare meaning, not only byte equality.

Evidence practice

Keep the exchange profile, source package, validation layers, mapping decisions and exception report. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: calling a parsed record interoperable before checking identifiers, relationships and local semantics. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Next chapter

A reliable audit follows an Object through receipt, validation, storage, repair, migration, rights review and dissemination while distinguishing repository assertions from supporting evidence. The goal is not maximum metadata volume but a traceable answer to preservation questions.

Sample objects and traverse their Events, Agents, Rights and relationships in both directions. Recompute selected fixity, inspect reports, test vocabulary versions and verify that deleted or superseded records remain governed. Review who can alter metadata and how corrections are versioned.

A fictional audit finds that migration outputs are linked to sources but tool versions disappeared after a service update. The repository repairs the Agent records, strengthens capture at execution time and documents the correction instead of backdating certainty.

Changed-context transfer check

Design an annual audit for a repository with outsourced storage and in-house metadata. Identify evidence that must cross the organisational boundary.

Limit and misconception

Complete PREMIS records cannot prove repository trustworthiness alone. Governance, security, redundancy, expertise and independent review remain necessary.

Evidence practice

Keep an object-history traversal, sampled verification, correction log and control owner. Label every field as observed, computed, assumed or chosen. Give the record to a second reader and ask them to reproduce the result without the original author explaining what was meant. Differences reveal hidden definitions, missing versions or decision rules that still need to be made explicit.

Deliberately test for this failure: counting populated fields while broken links, unsupported outcomes or mutable histories remain. Record the earliest point at which the process can detect it, the correction applied and whether later conclusions change. A method is transferable only when its controls work on an altered case, not merely on the example used to teach it.

Contents · Previous chapter · Connected articles

Advanced boundary cases

Intellectual entities and aggregations

Version 3.0 supports broader modelling choices, including intellectual entities and aggregation relationships. Use them only when the repository can explain the level, identifier and business requirement without duplicating descriptive systems.

Environment and software dependencies

Usability can depend on operating systems, libraries, fonts, codecs or hardware. Capture the environment at the level needed to reproduce the preservation action, and connect it to the acting software and affected Object.

Corrections and contested assertions

Preservation metadata may be wrong. Correct through versioned, attributable changes; preserve the prior assertion and reason when audit policy requires it rather than silently rewriting historical evidence.

A practical field check

Use this check when designing a PREMIS profile, reviewing an ingest workflow or diagnosing a broken preservation history.

1. State the preservation question and metadata boundary.
2. Identify Object levels and stable identifiers.
3. Split workflows into meaningful Events with outcomes.
4. Link Objects, Events and Agents using explicit roles.
5. Record the rights basis for preservation acts.
6. Version vocabularies, extensions and serialization profiles.
7. Test syntax, references, relationships and evidence separately.
8. Traverse a sample history and preserve corrections.

Run the check as a small workbook

Use linked sheets for Objects, Events, Agents, Rights, relationships, vocabularies and validation exceptions. Keep identifiers immutable and make each event row link to its evidence. A reviewer should be able to reconstruct one object history without relying on the original operator.

Gate	Pass condition	Stop condition
Identity	Object levels and identifiers are stable	Paths or mutable keys stand in for identity
Event	Action, outcome and evidence are distinct	One vague workflow status
Relationship	Roles and direction reproduce provenance	Generic or broken links
Rights	Permitted acts and restrictions are traceable	Preservation permission is assumed

Chapter-by-chapter evidence audit

Chapter	Evidence to keep	Failure to catch
1. Use PREMIS as preservation evidence, not a descriptive catalogue	A question-to-entity map and a documented boundary with adjacent metadata	Using PREMIS as a universal container and losing the meaning of specialised metadata
2. Distinguish representation, file and bitstream Objects	An object inventory with declared level, identifier, dependencies and preservation purpose	Treating one convenient file as the whole representation when required components are separate
3. Record Events as assertions about actions and outcomes	The event record, targeted objects, parameters, outcome and linked operational evidence	Using vague event types or one success flag for a multi-step workflow
4. Create identifiers that survive local system change	The identifier registry, scope, assignment log and migration crosswalk	Using a mutable path or database row number as the only object identity
5. Use relationships and roles to reconstruct provenance	Typed relationship records with source, target, role, event and validation checks	Inferring provenance from timestamps or filenames while omitting explicit relationship roles
6. Worked example: document a fictional format migration	Input and output Objects, migration and validation Events, Agents, reports and acceptance decision	Recording only the output file and a success label while discarding the source or exception
7. Separate event outcome from later acceptance	Normalised outcome, detailed report, decision owner and acceptance rationale	Conflating tool completion, preservation validity and institutional acceptance
8. Represent Agents and event-specific roles	Agent identifiers, types, versions and event-role links with privacy review	Putting all responsibility on a generic username or treating software name as a complete environment
9. Record Rights that govern preservation actions	The rights basis, permitted act, term, restriction, source document and review owner	Treating permission to preserve as permission to provide unrestricted access
10. Use extensions and controlled vocabularies without semantic drift	Namespace, vocabulary version, term definitions, mappings and validation cases	Adding local fields without ownership or mapping and later assuming identical labels share meaning
11. Exchange PREMIS without confusing serialization and meaning	The exchange profile, source package, validation layers, mapping decisions and exception report	Calling a parsed record interoperable before checking identifiers, relationships and local semantics
12. Audit preservation evidence as a connected history	An object-history traversal, sampled verification, correction log and control owner	Counting populated fields while broken links, unsupported outcomes or mutable histories remain

Connected articles across the eduKate ecosystem

Start with the governing route

• The Gold Standard of Information
• The Gold Standard of Education | Learning That Transfers into Life
• How X Works hub

Continue into verified specialist studies

• The Gold Standard of Information Preservation Engineering — place PREMIS inside the wider repository, format, storage and trust system.
• Checksums, Record Identity and Detecting Silent Change — deepen the fixity evidence linked to preservation Events.
• BagIt Profiles, Payload Manifests, Fixity and Transfer Validation — connect preservation metadata to a controlled transfer package.
• Data Citation, Versioned Queries, Fixity and Reproducible Subsets — connect preservation identity to scholarly reuse.
• Canonical Serialization, Deterministic Encoding, Hash Stability and Signature Verification — separate semantic records from deterministic byte representations.

Questions readers often ask

Is PREMIS a file format?

No. It is a preservation-metadata data dictionary and model that can be expressed through supported serializations and profiles.

Does PREMIS replace descriptive metadata?

No. It focuses on preservation entities, actions, rights and evidence; descriptive and discovery metadata retain their own jobs.

Must every workflow step become an Event?

Record steps whose action, outcome or responsibility matters for preservation evidence. Avoid both one vague event and meaningless event noise.

Does a PREMIS outcome prove success?

It records an assertion. Supporting reports, fixity, validation and later review remain necessary.

Can local extensions be used?

Yes, when their namespace, definitions, versions and mappings are governed and tested.

Does complete PREMIS metadata prove a trusted repository?

No. Repository trust also depends on governance, security, storage, expertise, rights and independent controls.

Sources and scope

Library of Congress: PREMIS Data Dictionary for Preservation Metadata, Version 3.0 — official data dictionary, entity model and implementation resources.

PREMIS Data Dictionary Version 3.0 full specification — official detailed semantic units, definitions and examples.

Library of Congress: PREMIS schemas — official XML schema and implementation files.

Library of Congress: PREMIS OWL Ontology for Version 3 — official RDF/OWL representation and mapping guidance.

PREMIS Version 3.0 errata — official corrections to consult when implementing the specification.

The repository, objects, migrations and permissions in the worked examples are fictional. This guide is educational and does not replace repository policy, legal advice, format expertise or conformance testing against the official PREMIS specification.

“Gold standard” describes the educational benchmark explained in this guide. It is not an official accreditation, legal opinion, policy determination or professional certification.

Back to contents · Return to the Information root · Return to the Gold Standard of Education