Object storage layout disposition hint

[awoods]

Should we allow for a Object storage layout disposition hint, along the lines of '1=pairtree_1.0', etc

[ahankinson]

I think we should allow this, but it should not be part of the OCFL specification. IOW, if the Pairtree spec provides a way of communicating the storage layout disposition, we should not prevent this but we should not invent one as part of our activities.

[zimeon]

I think we are really rather short of Use Cases to motivate decisions about storage layout, from a quick look I see only Rebuildability as having direct influence. Should we try to flesh out the use cases a bit?

[zimeon]

Have attempted to write up the use case I have for this: OCFL/Use-Cases#31

[zimeon]

Here is the kind of spec I have in mind:

4.2 Root Object Disposition Declaration

The OCFL Storage Root MAY include an object disposition declaration identifying the arrangement the storage root conforms to. If present, the declaration MUST be an empty file in the base directory of the OCFL Storage Root, formatted according to the NAMASTE specification, giving the identifier of the object disposition declaration in the filename. The filename must be constructed with a leading one-equals (1=) string, followed by URL encoded URI identifying the object disposition. The URI SHOULD resolve to a description. For example 1=https%3A%2F%2Fconfluence.ucop.edu%2Fdisplay%2FCuration%2FPairTree declares that the object disposition conforms to the Pairtree specification.

[ahankinson]

👎 I think this raises more questions than it solves.

[neilsjefferies]

There are comments/examples in the Implementation Notes. At the moment, there is no statement about the form of hints other than that they are nice-to-have. I do suggest maybe having a documentation OCFL Object referenced in the storage root. That can then hold as much hint material in easily readable form as you want, along with exposing it to preservation checks.

[ahankinson]

I propose we close this issue, as it as been handled in the implementation notes and #214

[awoods]

Linking this to #214 makes sense. I would suggest we hold off on closing this issue until #214 has been resolved/merged.