Open kieranjol opened 2 years ago
@kieranjol we've talked about this but are currently split on whether or not we should clear this up sooner or later because of potential impact on 2.0. i know that's a non-answer but i wanted you to know we aren't ignoring you.
Thank you so much for the reply! I’m glad that it’s being discussed!
We discussed this on the editors' call today. The intention of the text in section 4.3 Storage hierarchies, a sub-section of 4. OCFL Storage Root and thus in the context of an OCFL Storage Root is:
OCFL Object Roots MUST be stored either (as the terminal resource at the end of a directory storage hierarchy or as direct children) of a containing OCFL Storage Root.
There are certainly also uses of OCFL Objects that might happen outside of an OCFL Storage Root. For example, one might transfer and OCFL Object to or from a repository, one might assemble an OCFL Object outside of a Storage Root and then move it in, and I'm sure other cases too. Perhaps a clearer wording would be:
Within an OCFL Storage Root, OCFL Object Roots MUST be stored either as direct children of the OCFL Storage Root, or as the terminal resource at the end of a directory storage hierarchy.
May need to tighten up language to make clear that OCFL objects are independently validatable. No substantive changes required though.
Hi,
I'm reading through 1.1 and it's wonderful! Am I correct in thinking that a Storage Root is optional but highly recommended if you want to achieve the goal of rebuild-ability? It seems that the key section is
4.3 Storage hierarchies
, and the lineThis makes me think that a valid OCFL object can exist without a Storage Root as long as it's the 'terminal resource'? I'd never heard the term 'terminal resource' before, but I'm guessing that it just means that the OCFL object is the final set of files/folders at the end of a hierarchy?
If storage roots are optional, should this be stated as an explicit
SHOULD
somewhere in the document?Best,
Kieran O'Leary National Library of Ireland