Retain current functionality to transfer accessioned objects from DOR to Preservation Core, to maintain spinning disk copies as Moab objects, and to record them in a tracking data store.
Retain Moab as internal versioned object schema on online disk copy.
Add initiation of archive/replication as an asynchronous process to minimize processing time for ingest and thereby accessioning, since objects are locked from changes while in accessioning.
This is an an analysis of what the robots currently do and what changes are required to use the new Preservation Core Catalog. The overall purpose of the ingest workflow is to
receive and validate a new or versioned object from DOR in the form of a bagit bag
create a new Moab object (v1) or add a new version sub-directory to an existing Moab object
record the object in an inventory (formerly Sedora, formerly Archive Catalog, now PCC Inventory)
(new) initiate asynchronous archive/replica process
clean up and tell DOR Ingest is done.
Note that this currently happens in more than 5 workflow steps so that specific errors can be reported and acted on, and steps rerun without repeating work.
Current workflow steps and recommendations (to the extent this analysis can):
(1) start-ingest - not a robot, rather a pro forma bootstrap step, instantiated as "completed" to satisfy prereqs for first robot step.
Seems to be a no-op. We used to create a stub in original tracking datastore called Sedora (hence obsolete reference to that in the code). The only think it appears to do now is check that it's not already completed. Workflow update likes are commented out.
These seem to be fairly self-explanatory and need no functional change. It is actually the admin policy that is being verified, not the agreement, so a name change could clarify that.
Recommend: no functional change; optional name change and code-references updated from agreement to APO.
This is where the Moab object is placed into the Moab directory. Not a clear name since "deposit" is not clearly defined in the context of "ingest", which has a couple more steps to go.
Recommend: no functional changes; would like to change name to create-moab for clarity.
Goals
This is an an analysis of what the robots currently do and what changes are required to use the new Preservation Core Catalog. The overall purpose of the ingest workflow is to
Note that this currently happens in more than 5 workflow steps so that specific errors can be reported and acted on, and steps rerun without repeating work.
Current workflow steps and recommendations (to the extent this analysis can):
(1) start-ingest - not a robot, rather a pro forma bootstrap step, instantiated as "completed" to satisfy prereqs for first robot step.
(2) register-sdr code
(3) transfer-object code
(4) validate-bag code
(5) verify-agreement code
(6) complete-deposit code
(7) update-catalog code
(8) create-replica code
(9) ingest-cleanup code