How do you translate descriptions and operational documentation for Oxford Common File Layout objects without renaming the files that preserve their history, breaking inventory references or accidentally changing a version’s contents? OCFL 1.1 is a published specification for storing digital objects in a structured, predictable and application-independent form. Its directory layout and inventory JSON allow repositories to reconstruct objects across versions. That design makes OCFL valuable for long-term preservation, but it also means that casual changes to apparently readable file paths can destroy the connection between a preserved file and its recorded identity.
People looking for OCFL localization, Oxford Common File Layout translation, OCFL inventory.json guidance, digital preservation metadata translation, OCFL version directories, manifest digests, logical file paths or storage-root validation usually need an answer to a simple question: which text may be translated and which text must remain byte-for-byte correct? Human descriptive metadata, usage notes and public labels may need new language editions. Structural keys, digests, object identifiers, version markers, paths and conformance declarations do not become safer or more accessible when their syntax is rewritten as prose.
This longform guide explains the decisions that help archives, universities, cultural heritage institutions and technical translation teams publish multilingual descriptions around OCFL objects while retaining storage integrity. It draws on the OCFL 1.1 specification, updated in November 2024 as version 1.1.1, and the companion implementation notes. We will separate preservation data from language-bearing content, work through common failures and show what should be verified before a localized release. Readers do not need to be programmers, but technical changes must always be checked against the authoritative specification and repository policy.
Why translation makes preservation structure worth understanding
Imagine a university library preserving a digitized diary, its OCR transcript, a catalogue record and translations of the transcript. A reader wants the translated text. An archivist wants to know precisely which files were stored in each version and whether those bytes remain intact. Both needs matter, but the language edition and the inventory serve different purposes. The public might see one elegant page while the OCFL object contains several related files. Reliable preservation depends on keeping those relationships reconstructable even after an application, staff team or storage provider changes.
Forty-four decisions for OCFL localization and preservation integrity
1. OCFL describes objects at rest
OCFL primarily specifies how digital objects are laid out and described on storage so their versions can be reconstructed without depending entirely on one application. It does not prescribe the curatorial meaning of every file or the language of every catalogue record. Start translation work by identifying what belongs to the OCFL storage structure and what is an object payload or descriptive metadata file. Translating a museum essay inside an object may be legitimate; translating the layout keys that tell a parser where the essay’s bytes are stored is not. The boundary must be explicit before any editor opens an inventory.
2. Storage root and individual object are distinct
A storage root contains OCFL objects and has its own structure and conformance declaration. Each OCFL object has a separate identity and inventory. A translator should not call both simply ‘folder’ in instructions when the distinction determines a validation action. An operator checking root integrity is not necessarily verifying every object inside it, and validating one object does not establish that the entire storage root conforms. Use precise terminology in multilingual runbooks so staff know which level a command addresses. Clear language prevents a local repair from unintentionally affecting unrelated objects.
3. The conformance declaration is controlled syntax
OCFL uses a specific conformance declaration filename and content to indicate specification version. The name may look like an abbreviation a translator could improve, but it is part of the storage contract. Never translate or paraphrase the declaration inside the OCFL hierarchy. Human documentation can explain what it means and which version is required. A repository may include additional explanatory files where allowed, but those should not replace the official declaration. Before publication or migration, compare the object and root declarations to the version expectations of the validation software.
4. The object identifier is not a localized title
An object inventory contains an id that identifies the OCFL object in its own context. It may be a URI, an institutional identifier or another durable value compliant with the specification. An English-like segment does not justify translating the identifier as part of an international edition. Titles and descriptions can exist in language-specific metadata, but the object identity must remain stable across them. A change in display title should not create a new preserved object unless the repository has an explicit model reason to do so. Stable identifiers are the bridge between historical versions and present-day discovery.
5. Version directories are not chapters
OCFL object versions use a defined directory convention such as v1 and v2. These labels indicate stored versions; they do not mean chapter one and chapter two or first and second editions of the intellectual work in an ordinary bibliographic sense. Translate their explanation, not the directory names. The numbering follows technical rules that a parser expects. If a guide refers to the latest version, clarify whether it means the newest OCFL object state or the most recent edition of a book held within the object. Those may be different facts, especially when the same digital item contains multiple editions.
6. The head pointer has operational meaning
The inventory identifies a head version representing the current state in that inventory. A human reader may call it latest, but this does not mean an editor can casually change the pointer to another version to make a preferred translation appear. Such changes affect reconstruction of the object. Documentation should explain which version is being examined and how the repository safely creates a new version. If a user requests restoration of older content, the workflow may add a new approved version rather than silently rewriting historical directories. Follow the institution’s implementation procedures and OCFL rules.
7. The inventory is a reconstruction map
The inventory.json file records identifiers, digest information, a manifest and versions with their logical states. It enables tools to understand how stored bitstreams contribute to each version. A translation of the keys in this JSON would be like translating column names in a machine protocol without telling the parser: the information becomes unreadable to compliant software. Translate annotations held in permitted natural-language fields or associated metadata files, not the structural schema. A visually readable file is not necessarily safe to edit as ordinary prose. Reviewers should know whether a string is an identifier, path, description or controlled value.
8. Manifest versus version state
A manifest relates content digests to stored file paths, while a version’s state relates those digest identities to the logical files that users see in that version. This separation is a core design feature. If an editor changes the readable logical filename but forgets the state mapping, the version may not reconstruct as intended. If an editor renames a physical content path without updating the permitted inventory relationships through the proper process, validation can fail. Translate metadata describing what a file is, while letting approved repository software manage structural renames and new versions. Natural language is not a substitute for state management.
9. Logical paths versus content paths
A logical path represents a file’s name and location within a version of the digital object. A content path identifies where the preserved bitstream is actually stored inside the OCFL object. They can differ, allowing renames and deduplication without rewriting existing content. A translation team might want a localized file name for a reading interface. That can be a valid new representation or an approved logical change, but not an uncontrolled filesystem rename. Determine whether the user sees a presentation label, a logical path or a storage path before editing. Each has different consequences.
10. Do not rewrite inventory digests
A cryptographic digest is a calculated value representing content bytes under an algorithm. It is not a descriptive code that can be improved by replacing letters or formatting it according to local typography. Preserve digests exactly. The digestAlgorithm field has a technical role, and validation expects values and associated content to agree. If a translation changes file bytes, the resulting object needs correct versioning and new calculated digests through appropriate tooling. The translator’s objective is a faithful new language file, not the manual manipulation of evidence that claims it is identical to an earlier file.
11. Fixity and meaning are separate
A successful fixity check supports the conclusion that bytes match their expected digest. It does not establish that a translated description is accurate, or that a preserved document is historically true. Conversely, an excellent translation can be stored incorrectly and fail integrity validation. Build two review tracks: technical validation of object structure and bitstreams, and editorial validation of meaning, attribution and permission. A complete release needs both. Describe them clearly in all languages so a dashboard never uses the single word ‘verified’ to imply checks it did not perform.
12. The optional fixity block
The inventory can include additional fixity information beyond the content-addressable manifest. That may help retain legacy checksums or support other integrity practices. These records should not be treated as a translation memory or a field for editorial commentary. Keep digest types and values unchanged, and let preservation tools assess supported algorithms. A localized report can explain which checks were run, which were unavailable and what result was observed. Avoid declaring that an untested legacy digest has been verified simply because the inventory contains it. Presence of evidence and successful testing of that evidence are different.
13. A new translation changes bytes
Even when two language editions convey the same scholarly meaning, their files are not byte-identical. A translated PDF or XML record therefore cannot be inserted as though it had the digest of the original document. It should be stored as a distinct appropriate file or version according to repository policy, with fresh technical metadata. Maintain relationships between language versions in descriptive metadata rather than pretending their binary content is interchangeable. This distinction is central for digital preservation: semantic equivalence may support intellectual access, but the system must still know exactly which bytes belong to each preserved object state.
14. Prior versions should remain reliable
OCFL is built to support reconstructing earlier object versions. The ability to look back matters when a translated description is corrected, a rights statement changes or a format migration takes place. Do not rewrite old version directories simply to make every historical display match today’s terminology. A preservation system may store new metadata in a subsequent version while retaining the earlier one. Editorial corrections can be explained to users separately. If older text contains a mistake, preserving that record can support accountability, provided access and privacy policies are respected. History should be amended through controlled process, not silently replaced.
15. Renaming a file is a managed event
A file might be renamed to improve accessibility or follow a new institutional naming convention. Within OCFL, that is not merely a matter of clicking Rename in a file manager. Logical-path changes can be represented through correct version state while underlying content may remain deduplicated. A translator should propose readable file names without performing unreviewed structural modifications. The preservation team should decide whether the change belongs in a new version, an external display layer or a separate derivative. Test reconstruction of both old and new states to confirm that the rename did not make content disappear.
16. Deduplication is not identity confusion
OCFL can reuse the same stored content for several logical paths or versions when the bits are identical. That is a storage efficiency, not proof that the files have the same descriptive role. Two records can share a static logo but appear in different contexts. A translation team should not merge metadata or remove entries solely because digest values match. Conversely, a translation that changes a few words produces different bytes and may no longer deduplicate with the original. Distinguish content equivalence from bibliographic or curatorial identity. They are related questions but answer different operational needs.
17. Metadata belongs with preserved content
OCFL encourages approaches that make an object reconstructable even if the original repository application disappears. This often means including enough descriptive, technical, structural and preservation metadata with content. Translation may enrich access metadata, but should not remove essential information that future readers need to understand the source. A multilingual description might summarize a manuscript beautifully while omitting the provenance, original language and file format needed to interpret it. Consider what a future archivist could recover from the stored object without today’s database. Human readability and machine integrity should reinforce each other.
18. Meaningful distinctions in metadata
An administrative note may describe rights, a structural map may describe file order, and a descriptive record may explain the content. These should not be translated as if they are interchangeable narratives. If a metadata package contains rights terms, seek appropriate legal review. If it describes file order, preserve exact referents and sequence. If it includes a historical quotation, retain the evidence and its language context. Translators should classify fields by their job before writing. That categorization prevents a seemingly elegant rewrite from changing an access rule, erasing file organization or misattributing a claim.
19. Language identifiers and alternate versions
An object may contain a source-language transcript, a translation and an accessible-language adaptation. Each has its own function. Preserve language identifiers in a standard form used by the repository and distinguish a translation from an original text. A summary is not a full translation, and a phonetic transcription is not the same as a semantic rendering. When storing several language derivatives, document their relationship in descriptive metadata rather than relying on filename suffixes alone. A future reader should be able to see who produced each version, what source it used and whether it underwent review.
20. Unicode and filename behavior
Different operating systems can represent apparently identical characters differently. File paths may also be sensitive to case and normalization. A translator adding accented or non-Latin characters to a filename should not assume that every storage backend will treat them identically. Follow OCFL path rules and repository implementation guidance, and test round trips across the supported environment. It is often safer to keep canonical storage paths stable while showing localized names in user interfaces. Do not introduce filesystem features or naming practices that compromise portable object reconstruction simply to make a directory look linguistically natural.
21. Filesystem case sensitivity
OCFL requires preserving case distinctions in file paths, even if some local machines or clients have case-insensitive behavior. Two filenames differing only in capitalization may be distinct in the preserved object. A translation that normalizes case can therefore cause collisions or mismapped content. Technical documentation should warn that interface display conventions cannot determine path identity. Before a migration, test how the destination storage handles case, Unicode and prohibited characters. Copying files successfully is not enough if their original path identities cannot be reconstructed under the inventory’s mapping.
22. No symbolic-link shortcuts
Filesystem symlinks and hard links are not portable features of OCFL storage hierarchies. A technician might propose using links to provide localized filenames without copying bytes, but that workaround can violate storage expectations and fail on another platform. Use the defined inventory mechanisms and approved presentation layers instead. Explain this distinction in practical language for staff accustomed to ordinary desktop folders. A preservation object is not merely a collection of convenient aliases; it is a structured package whose paths and content relationships should be verifiable in different technical environments.
23. Extensions require governed meaning
OCFL supports extensions, but their structure and purpose need to be defined according to its rules. A translation team should not invent a new extension name to hold miscellaneous language content without technical review. If a multilingual repository needs a new field or workflow, decide whether existing descriptive metadata files are sufficient, whether a documented extension is appropriate or whether the change belongs outside the OCFL object. Extensions can add flexibility, but undocumented local invention undermines portability. A future reader must be able to understand what additional folders and metadata mean.
24. Logs and operational history
Operational logs can record actions around an OCFL object, but their purpose differs from a version’s reconstructed logical state. A translated log entry must preserve who did what, when and with what outcome. Do not change ‘validation failed’ into ‘validation performed’ or ‘attempted migration’ into ‘completed migration’. Logs may contain sensitive operational information, so publication and privacy rules still apply. A future investigation may need to distinguish a successful change from a failed attempt. The best translation retains technical state words and references to affected versions while making the event understandable.
25. Storage-root hierarchy choices
OCFL can be deployed on different storage technologies, and repositories may use hierarchy extensions or local disposition strategies. A translated explanation should describe the actual implementation rather than suggesting that every institution has the same folder tree. Root-level and object-level contents have different rules. A system might distribute objects across a nested layout for performance; those path choices are not equivalent to curatorial collection categories. Avoid assigning historical meaning to storage directory names unless the source documentation supports it. A storage map supports retrieval; a catalogue map supports intellectual discovery.
26. Cloud object storage and local disks
OCFL is intended to support diverse storage infrastructure, including systems that present hierarchical namespaces rather than ordinary desktop folders. A translator should not overpromise that a repository can be managed safely with a standard file browser. Object-store consistency, API behavior and version handling may require specialized tooling. The correct explanation focuses on logical paths, inventories and validation, not the user interface of one storage vendor. This matters for internationally distributed institutions where a guide translated from desktop terminology may be followed by an operator using remote or cloud storage.
27. Migration between storage systems
A digital repository may move OCFL objects to new disks, cloud storage or another institution. The key preservation question is whether their structure and content can still be validated and reconstructed. Translation of migration reports must preserve source, destination, status and exceptions. ‘Transferred’ is not the same as ‘verified’; ‘verification complete’ requires evidence. Keep original identifiers, digest values and path semantics intact unless a documented conformant migration deliberately changes them. A multilingual runbook should instruct staff to test representative objects with several versions, long paths and non-Latin metadata before declaring success.
28. Migration of file formats
A repository may create a new representation of a file because its format is aging or difficult to access. That is not the same as moving the unchanged bits to another storage device. A migrated PDF, image or audio file generally has different bytes, and must be described and versioned accordingly. Translate labels such as original, preservation master, access copy and migrated derivative with precision. The object history should reveal which representations existed at each stage. A public description can be concise without hiding whether a file was transformed or merely relocated.
29. Preservation masters and access copies
The file served to a visitor may be a compressed or redacted derivative, while the repository keeps a higher-quality preservation master. These versions or related resources require distinct roles and permissions. A translation that calls the public preview ‘the original preservation file’ may misrepresent quality and availability. Make clear which object the language applies to. When an institution adds subtitles, OCR or a translated transcript for accessibility, those derivatives can improve access without replacing the source master. Record their provenance and language context so future users understand the relationship.
30. Rights and restricted content
An OCFL object may contain material that cannot legally or ethically be published openly. The storage specification does not grant a licence or override privacy restrictions. Translate rights metadata and access notices with specialist review, including distinctions among preservation custody, reading-room access and public download. A new language derivative can have its own rights considerations. Never conclude that a file is free to reuse simply because it exists in a validated preservation object. Technical conformance and permission to distribute are separate judgements, each requiring its own evidence.
31. The object inventory is not a catalogue entry
The inventory tells software how to reconstruct versions and locate bits. It does not necessarily contain a visitor-friendly description of the cultural object. A translator looking for a title inside inventory.json might wrongly treat the id as the item’s name or the head timestamp as its creation date. Instead, find the appropriate descriptive metadata file or external catalogue record. This distinction allows preservation structures to remain stable while language editions evolve. If descriptive metadata is missing, record that gap rather than inventing a title from structural information that was never meant to answer the question.
32. Content changes and version policy
OCFL intentionally does not decide every institutional rule for when a new version must be made. A repository therefore needs an explicit versioning policy for metadata corrections, translations, migrations and access derivatives. Translators should understand whether their work creates a new object file, a new version or an external display layer. Ask that question before approval. An unauthorized replacement of a file in place can destroy preservation history even when the new prose is more accurate. Versioning decisions belong to the steward of the repository, with editorial input recorded separately.
33. Atomic updates and failures
Writing a new OCFL version involves more than adding a directory name. Repository tools must ensure that inventories, digests and content reach a consistent state, including when a process is interrupted. A translated operations guide must distinguish prepared, writing, validated, committed and failed states. If a task stops partway through, it should not tell an operator that the new version is complete. Follow the OCFL implementation notes and local transactional procedures. Fault testing is important because the most severe corruption can arise not from ordinary translation but from an unreviewed retry after a partial write.
34. Reconstruction of earlier states
A key reason to keep versions is to reconstruct what an object contained at a particular time. Test that an older version still yields its expected files after a new translation or metadata update. Avoid assuming that a filesystem diff of two directory trees tells the complete story, because logical states can reuse older bitstreams through manifest references. A human-friendly audit report should identify the selected version and the reconstructed logical paths. When a translation changes a file, its history should be observable rather than disguised as an original file that always had the new wording.
35. Validation codes and error messages
OCFL validation tools can report structural, digest and path problems. A localized dashboard should translate the human explanation, not alter the underlying error code or its technical referent. A message saying a digest mismatch occurred must not become a generic warning that the text is difficult to read. Connect each error to the relevant object, version and path. If a validator cannot check one optional digest algorithm, communicate the limitation instead of declaring success. Accurate error wording helps preservation staff distinguish corruption, incomplete copying, unsupported features and editorial issues.
36. Sample objects and edge cases
A quality test set should include an object with several versions, renamed logical files, reused content, multiple languages, long paths and a file updated after translation. Also include damaged or deliberately inconsistent examples to confirm that validation catches them. Do not rely solely on a minimal object that has one file and one version; it does not exercise the relationships most likely to break. Compare the reconstructed states with approved fixtures, then review the visitor-facing language separately. Technical edge cases are not optional luxuries in preservation, where an error may remain hidden until the original software is unavailable.
37. Relationships to PREMIS and descriptive standards
OCFL provides a storage structure, while PREMIS focuses on preservation metadata such as objects, events, agents and rights. Other metadata standards can describe the intellectual content or institutional workflow. These can complement OCFL without becoming the same thing. A translator should not use a PREMIS preservation event name as though it were an OCFL version directory, or treat a bibliographic title as a content path. Document what each system owns and how identifiers connect across them. When a new language edition affects both a preservation event and a descriptive record, update each through its proper approved workflow.
38. Relationships to BagIt and transfer packaging
BagIt is commonly used for packaging and checking transfers, while OCFL structures objects at rest across versions. A bag delivered to a repository is not automatically an OCFL object simply because both include files and manifests. A translation of transfer documentation must not make that claim. If a repository ingests a bag into an OCFL object, record the transformation, identifiers, verification and any retained original package. Distinguish receipt, unpacking, validation and long-term storage acceptance. Good terminology prevents operators from assuming that successful transfer alone meets their preservation obligations.
39. Relationship to synchronization protocols
ResourceSync can help a destination learn about remote resource availability or changes; OCFL determines how an object is stored and versioned once managed by a repository. Neither system replaces the other. A user-friendly translation should distinguish a remote resource update from a local OCFL object version. An upstream title correction might trigger a synchronization event and a later preservation ingest, but the two timestamps and identifiers have different meanings. Keep this chain explicit. When troubleshooting, first ask whether the issue is discovery, transfer, ingest, inventory or public rendering.
40. Human documentation for international teams
A strong multilingual operations manual can introduce the storage root, object, inventory, manifest, versions and state using plain examples before showing commands. Do not require every archivist to read source code to understand why a rename is dangerous. At the same time, never translate executable JSON keys or shell paths inside a code example just to achieve linguistic consistency. Keep technical tokens exact and explain them in nearby prose. For non-Latin scripts and right-to-left reading environments, test that code blocks remain selectable and preserve character order in editors and browsers.
41. Approval roles and accountability
A translator can certify clarity of wording, but not independently approve structural changes to a preservation object. A developer can validate JSON, but not decide whether an art-historical attribution or rights notice is true. Assign approvals to language, preservation, descriptive metadata and rights specialists. Record which file versions were reviewed and which validation tool was used. When a change crosses several responsibilities, require a clear handoff rather than a vague instruction to ‘check with the team’. Distributed international repositories work better when an operator knows exactly who can authorize each kind of alteration.
42. Release workflow and traceability
Before a language update is published, archive the approved source text, translation review, preserved file identifiers, new checksums, object version details and validation results. Reconstruct the relevant object states and compare them with the expected files. If an error is found, document the correction through the repository’s version and access policies instead of silently overwriting a previous state. Notify downstream consumers of material metadata changes as appropriate. A successful release does not mean all records are translated; it means that translated parts are accurate and the preservation evidence remains usable.
43. The simplest durable mental model
Think of an OCFL object as a well-documented set of preserved versions, not a folder that can be edited casually. The inventory maps exact bits to the logical files present in each version. Human-readable descriptions can evolve and gain new languages, but that work must be recorded as new appropriate content rather than rewriting structural truth. If you remember only one rule, ask what a string is doing before translating it. A title invites explanation; an identifier establishes identity; a digest checks bytes; a path locates data; a version preserves history. Keeping their jobs distinct is the foundation of safe multilingual preservation.
Ten worked failures and precise repairs
A translator renames the manifest key
An editor opens inventory.json, sees the term manifest and replaces it with a translated equivalent. The file remains valid JSON but no longer follows the expected OCFL inventory structure. A preservation tool cannot reconstruct the object correctly. Repair the structural key using the official specification, validate the inventory and confirm the affected object versions reconstruct as expected. Put the translation in documentation explaining what the manifest does. The underlying lesson is that a human-readable computer term can still be a required exact interface name, not a phrase awaiting localization.
A translated PDF keeps the old checksum
An archive creates a Portuguese translation of a report but copies the original report’s digest into a new file record because the documents have the same meaning. The bytes differ, so fixity validation fails. Treat the translated PDF as distinct content with a correctly calculated digest and appropriate version relationship. Preserve the original file and its checksum. Semantic equivalence is a judgement about content, while a digest is a test of specific bytes. Confusing them undermines the basic evidence that digital preservation provides.
A file is renamed directly on disk
A technician changes a path in the filesystem to improve its readability but does not update the inventory and logical-state mapping. The file appears present in an ordinary browser while the object fails OCFL validation. Restore the consistent state through approved object tooling, not further ad hoc edits. If a localized filename is truly required, create an appropriate new version or public presentation label under repository policy. Test both the current and earlier version reconstruction. Visible directory neatness is not evidence of a valid preservation structure.
A rights notice changes without an object update
A museum discovers that a digital image may not be redistributed, yet the preserved descriptive metadata and public catalogue still say unrestricted use. A staff member changes only the website translation and assumes the preservation record is corrected. Review which files are authoritative and whether a controlled new OCFL version is needed. Preserve the previous state, add the approved corrected rights information and ensure the public access layer follows it. Legal communication, stored evidence and public display must be aligned through an accountable correction rather than an undocumented text substitution.
An older version is overwritten to remove an error
A manuscript transcript contained a mistranscribed word in its first preserved version. The translation team rewrites that version to match today’s corrected text, destroying the historical record of the earlier transcription. The appropriate remedy is normally an approved correction in a subsequent version, with explanatory metadata and retained earlier content where policy permits. Verify that the older state remains reconstructable and the current public view points to the corrected version. The ability to explain what changed is part of preservation value, not merely an administrative burden.
Storage-root validation is mistaken for file verification
A dashboard shows that the storage root layout is recognized. Its translated status message says every file in the repository has been checked for corruption. That is a much stronger claim than the observed operation supports. Separate root structure validation, object inventory validation and content fixity checking. Report which objects were sampled, whether all referenced bits were read and which algorithms were supported. A concise honest status message might say root structure validated, with content fixity verification still pending. Technical truth should survive translation into ordinary language.
Two paths collide after case normalization
A migration copies OCFL objects to a filesystem that treats two differently capitalized names as the same path. The destination silently overwrites one file, even though the source inventory correctly distinguishes them. Identify the collision before migration, choose a compliant storage strategy and test full object reconstruction. A translator should not normalize filenames for stylistic consistency; case can be part of file identity. The incident demonstrates why technical localization must consider operating-system behavior rather than just the readability of labels.
A symbolic link is added for a language edition
A developer wants users to browse the same file through English and Arabic filenames, so adds a symlink inside the OCFL hierarchy. This convenient desktop solution is not portable under OCFL’s storage rules. Remove the unsupported link and implement language-specific display labels or an approved versioned file relationship. Validate the object after repair. A multilingual interface should not require compromising the preserved representation. The stronger design serves language access through applications while protecting the neutral, verifiable storage arrangement.
A transfer package is called a preserved object
A repository receives a BagIt package, checks its transfer manifest and translates the receipt as ‘fully preserved in OCFL’. In fact ingest into the OCFL storage root has not occurred. Correct the workflow status to received or transfer-verified, then document creation and validation of the OCFL object when that happens. The original package may remain useful as transfer evidence but is not automatically a compliant object at rest. Human-facing status words should describe the exact completed stage, not the institutional aspiration for later preservation.
A newer edition is mistaken for an OCFL version
A library stores a digitized first edition in v1 and later adds a translation of a second edition in v2. The public interface says v2 means the book’s second edition, even though v2 identifies an OCFL object state and could contain multiple intellectual editions. Separate bibliographic edition statements from storage version labels. Use descriptive metadata to identify the translation and source edition accurately. The same conceptual boundary applies to images, recordings and software: preservation versioning records changes to a stored object, not necessarily the historical sequence of the work itself.
A release checklist that protects both meaning and bytes
Identify the storage root and object version before making changes. Confirm the official conformance declaration, object identity, inventory, manifest, logical states and expected digests. Use approved software to add language-bearing content as appropriate, not uncontrolled changes to older versions. Reconstruct sampled historical states, verify the new current state and review human-facing translations for accuracy, source attribution, rights and accessibility. Record any incomplete validation honestly. A trustworthy multilingual preservation release is one in which future users can still tell which files existed, where they came from, how they changed and what each language edition claims.
Frequently asked questions
What is OCFL?
The Oxford Common File Layout is a specification for structured, transparent and versioned storage of digital objects intended to support long-term access and management.
What is inventory.json?
It is the machine-readable inventory that records object identity, content digests, manifests and version states needed for reconstruction.
Should inventory keys be translated?
No. Structural JSON keys, content paths, digests and controlled version markers must continue to satisfy the OCFL specification.
Can descriptions be translated?
Yes, when they are genuinely human-language metadata or content, with appropriate new files or versions and preservation review.
Is a logical path the same as a stored content path?
Not necessarily. The inventory separates logical file names in a version from the physical content paths used to store bitstreams.
Does a matching digest prove a translation is correct?
No. It checks bytes against an expected digest; linguistic and scholarly accuracy need separate review.
Does OCFL define rights to reuse a document?
No. Rights and access policies belong to the institutional governance and relevant metadata, not to storage conformance alone.
Is v2 always the second edition of a book?
No. v2 denotes a version of an OCFL object, not necessarily a bibliographic edition of the work it contains.
Can I rename files inside an object with a file manager?
Not safely as an uncontrolled change. Use approved versioning and inventory-aware tooling that preserves conformance and earlier states.
What is the first release test?
Validate the OCFL structure and referenced content using compatible tools, then verify reconstructed states and the editorial accuracy of translated material.
Primary sources and related guides
Consult the Oxford Common File Layout Specification 1.1 (updated 7 November 2024), the OCFL implementation notes, and the official OCFL release notices. The November 2024 patch is version 1.1.1; storage-root and object declaration rules continue to use v1.1 as specified. These official resources determine conformance.
The adjacent eduKateSG guides address PREMIS preservation metadata, ResourceSync repository transfer and BIBFRAME library descriptions. Each describes a different layer; none authorizes editing OCFL inventory structures merely to improve translated labels.