1.9 IUCat Extraction

Pertinent to HPT-1344.

The current (curation_concerns) implementation uses this approach:

1. A work's edit form contains an additional checkbox to optionally update with remote metadata
2. The controller includes a module that checks whether parameters indicate:
   • checkbox was filled, on an update action
   • it's a create action (unconditionally)
3. If the check passes, the controller adds a decorator to the work model that monkeypatches its save action to call apply_remote_metadata immediately prior to save
4. That action uses a custom stack using JSONLDRecord and the content of lib/iu_metadata

Under Hyrax 2.1, but the more Hyrax-y approach is to replace step #3 -- having the controller decorate the work model -- with customization to the actor stack that all the controller actions are largely delegated to. The other steps can probably remain essentially the same, although their implementation details differ.

Necessary subtasks include:

1. Add the source_metadata and source_metadata_identifier attributes

• A consideration here is stock Hyrax follows a pattern of required vs optional attributes. What we currently have is a notch more complicated, where at least one of of title or source_metadata_identifier is required -- but neither one, on its own, is strictly a required attribute. This impacts both model validations and the two part (required attributes, then optional attributes) structure of the edit form (below), and how much we might need to override it.

2. Customize the field edit form for source_metadata_identifier to include the option to apply remote metadata
3. Modify the controller to check for create action or update with remote metadata, and pass that along to the actor stack
4. Modify the actor stack with a new actor to pull and apply remote attributes, using the iu_metadata library content or modifications of it

The iu_metadata libraries may benefit from refactoring, both to fit into the Hyrax 2.1 context, and to deprecate the METSRecord content we're not using.

There are a few inter-related questions on how to approach #4:

• Who modifies the parameters with the remote lookup results? The controller, the Environment, or the Actor?
  • If the controller: we can use stock Environment and Actor components
  • If the environment: we probably need to pair this with a modified Actor that knows to call a new method on the Environment to pull in remote attributes
  • If the Actor: do we replace the standard model actor, or insert the remote-data actor afterwards? If we make the form field to indicate remote data update a "virtual attribute" on the model, we may be able to bypass controller modifications.