Support in-place migration of existing digital objects to OCFL objects

[julianmorley]

The spec should be written to support the migration of an existing storage root that contains objects that can be converted to OCFL format. This will be an in-place, gradual migration where there will be a period of time where a storage root will be declared to conform to the OCFL spec, but contains objects that are not yet OCFL-compliant alongside objects that are compliant.

For example, Stanford has many storage roots with Moab-based digital objects; forklift migration of this content is problematic. It would be desirable to declare an existing Moab storage root as OCFL-compliant, and convert the Moabs to OCFL over time.

[zimeon]

@julianmorley - In the scenario you imagine above, what would stop an OCFL tool that is looking for OCFL objects from descending into Moab objects? I'm wondering whether you could add a 0=moab_x.y declaration to each object, and whether the spec could say something about never descending past an 0=something file, ignoring any where the type/version is not recognized. Or maybe one should rely on regular enough layout/disposition to avoid confusions?

[awoods]

Assuming Moab object roots are mutable, putting in a Namaste to prevent OCFL traversal is conceivable.

In the general case, if OCFL allows for mixed content in its storage hierarchy, non-fruitful traversals will be expected.

[julianmorley]

OCFL v1 spec allows for the overlay of an OCFL object hierarchy on top of a Moab object.