Question about OCFL interpretation for multiple physical storage backends

[Jakub Růžička]

Dear members of the OCFL community,

I am contacting you to ask for guidance on the interpretation of one specific aspect of the Oxford Common File Layout (OCFL) standard.

 

We are designing an OCFL-based solution that, for security and availability reasons, needs to store the same content on four independent physical storage backends (different technologies / locations). In this context, we have encountered differing views on how OCFL should be correctly applied with respect to these replicas. In particular, we are considering two approaches:

 

Variant A – a single OCFL object created once and distributed
An OCFL object is created once (for example on a logical / staging layer), and its bit-identical form is then distributed to all four physical storage backends. From the OCFL point of view, there is a single object, and the existence of multiple physical copies is handled at an infrastructure / replication layer, outside OCFL itself.

 

Variant B – separate OCFL repositories on each physical storage backend
Each of the four physical storage backends hosts its own OCFL Storage Root / repository, and the same content is written separately into each repository as an individual object. From the OCFL point of view, this results in four distinct objects with identical logical content, stored in four separate repositories.

 

We would therefore like to kindly ask for your guidance on the following two questions:

1. Does the OCFL specification (and its recommended interpretation) assume that, in a multi-backend scenario, Variant A or Variant B is preferable, or are both options acceptable from the OCFL point of view and the difference is purely an implementation detail?
2. If one of these variants is preferred, could you briefly describe why it is more suitable from the perspective of long-term preservation and repository rebuildability?

Thank you in advance for your clarification.

 

 

Best regards,

Jakub Růžička

[Metz, Rosalyn]

Hi Jakub,

First, the editors met today, and we’re excited to hear that you’re working on a project. We’d love to learn more about it.

Second, and more importantly, the OCFL specification has intentionally remained silent on whether Variant A or B is the best option for a repository. Ultimately, the specification describes what the files look like at rest; the decision between A or B is an implementation detail that depends on your repository’s goals or infrastructure.

If you have any other questions, please let me know!

Best,

Rosalyn

On behalf of the OCFL Editors

From: ocfl-co...@googlegroups.com <ocfl-co...@googlegroups.com> on behalf of Jakub Růžička <jakubr...@seznam.cz>
Date: Thursday, December 4, 2025 at 10:21 AM
To: Oxford Common File Layout Community <ocfl-co...@googlegroups.com>
Subject: [External] [ocfl-community] Question about OCFL interpretation for multiple physical storage backends

You don't often get email from jakubr...@seznam.cz. Learn why this is important

--
You received this message because you are subscribed to the Google Groups "Oxford Common File Layout Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocfl-communit...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ocfl-community/3ef6cad9-77a5-4fd3-b07e-42047a4ea0bdn%40googlegroups.com.

[Jakub Růžička]

Hi Rosalyn and OCFL Editors,

thank you very much for your clear and helpful response, and for taking the time to discuss my question during your meeting.

We are currently using OCFL in several projects, at different stages of design and implementation. I will check internally what information we are allowed to share publicly, and if possible I would be happy to follow up with a short overview.

 

We would also be very interested in contributing back to the project where it makes sense (for example by providing implementation feedback, reviewing documentation, or similar).

Finally, please accept my apologies for the duplicate email – that was an error on my side. 

Best regards, Jakub Růžička

Dne pátek 5. prosince 2025 v 0:12:19 UTC+1 uživatel rosaly...@emory.edu napsal: