Is a METS-bagger workflow possible in MIK?

[MarcusBarnes]

Is a MET-bagger workflow possible in MIK similar to the METS-Bagger tool? The METS-Bagger tool was a Python script that I helped develop for normalizing existing digitized content into standardized packages wrapped in BagIt to help with monitoring file fixity.

This issue is to help me determine how flexible MIK architecture is while potentially also improving the METS-Bagger tool flow with the additional features currently present in MIK.

Initial Toolchain description: Input: source files on disk metadata: METS XML including FITS metadata Output: Bags with expected structure with METS.xml metadatafile. Potential Postwritehooks: zip the bags

Note that this issue is not attached to a specific milestone since it's an extension of the original use-case of MIK. If you are particularly interested in this issue, please add a :thumbsup: in the comments section to help gauge community interest.

[mjordan]

:+1: but there would be an issue with writing a file like FITS output to a package and then performing post-write hook operations on the package like copying it, zipping it, or generating a Bag from it because post-write hook scripts are executed as background processes. Even though we can control the order that post-write hook scripts are initiated, we can't (and probably don't want to) block a script from executing until a preceding one has finished executing.

But, if the MIK writer was designed to generate a package like the one created by METS-Bagger, we might have better luck. In fact, couldn't we use multiple writers at one time? For example, one to generate CONTENTdm newspaper issues like the one we currently have and another to generate METS-Bagger packages? We'd have to associate specific post-write hooks with specific writers but that would be possible.