Design

1. Driving principles:
   1. Minimizing change to the user via the API
   2. OCFL-isms not bleeding into Fedora API
   3. Rebuildability
   4. Compliance with OCFL
   5. Retain URLs of migrated Fedora resources
   6. Performance
   7. Reducing complexity of implementation

Fixity service

Transaction service

Query endpoint

Versioning

1. Support for both:
   1. version an object on-demand (manual versioning)
   2. version an object on-change (auto-versioning)
2. Support for toggling auto-versioning on/off
3. Note: Actively edited objects not captured in an OCFL version directory

Bulk ingest

To flavors of pointing a Fedora instance at an OCFL backend.

1. via OCFL
2. via Fedora OCFL

https://docs.google.com/document/d/15QwmyNFMopJW4MHxQNTiOGh_WXsOPr9-yzctGLCgT5k/edit

Import / Export   (Migration)

https://docs.google.com/document/d/1nvUDar1DbexdU3oTRGxzcZGG3qxsD2HWQbGyyRJIgDE/edit#

Mapping between LDP and OCFL

Opt-in model

1. Fedora resources may be created with an optional "archive" interaction model provided via headers.  

2. New resources created via POST or PUT to the archive will be LDP contained by the archive and will be stored within the OCFL object representing that archive.

3. If a resource is created without the "archive" model, new resources created via POST or PUT will be LDP contained by the archive, but will be stored as separate OCFL objects.

Notes/Implications

1. At creation time, you establish what you want and then stay in that model. Changing the model would require additional migration tooling.
2. Requires 3 interaction approaches: atom (implicit), archive, part (implicit)

Architecture

1. Retaining HTTP layer of existing Fedora codebase
2. Replacing ModeShape persistence with OCFL storage
3. Optimizing reads/lookups with an internal database
   1. proposed database model: https://docs.google.com/document/d/1MsMfhae3thmNdoFtnTUnII3mr_-OkllRs9PvgnY1fDY/edit

Scaling

• stateless Fedora instances
• database can be clustered and scaled
• file system ->  cloud object store

Performance

1. Many members: performance should improve significantly since list of members will be supplied by a database index (which should support a degree of in-memory caching).  No loading of modeshape nodes required.
2. Ingest speeds: 

ModeShape replacement

OCFL persistence

1. Support for both OCFL objects:
   1. created by Fedora
   2. pre-existing, created by another application

Fedora-specific details

1. /content/.fcrepo directory
2. Hashing (SHA256) on LDP path of resource