...
The group members identified, documented, and reviewed the following processes in order to provide background on active services, workflows, and participants across the institution (documentation available on Box, with authentication):
- Digitized Audio
- Course Reserves
- Dataverse/Research Data Sets
- Digitized Books
- Disk Images
- ETD Application (Legacy)
- ETD Application (New/Hyrax)
- The Keep (Ingest Summary for Multiple Workflows)
- OpenEmory
- Still Images (General)
- Still Images (Aeon Requests)
- Digitized Video
The set of process maps expanded on prior work conducted in 2016, and includes both Fedora-integrated as well as repository-related processes for which direct repository integration is not yet available. In reviewing the documented process maps, group members clarified both the current process details, and later, discussed gaps/ideas for future state process improvement.
...
- Harvest of metadata and content files from outside systems (e.g. OpenEmory and its relationship to Emory FIRST; ingest of Bags from an external server for the Keep)
- Multiple methods of descriptive metadata creation for self-deposit and staff deposit are manifested in different metadata editing interfaces (also reflected in the Metadata Implementation Working Groups’ Systems of Record Analysis)
- Process participant roles (now generalized as user profiles) were noted to perform similar actions but with different labels, and their activities occur in different sequences across the process maps
- Activity sequences vary: common/core activities in various workflows occur in different order in the current state. Some workflows also incorporate status tracking for deposit prep activities in data sources outside of the repository
- Certain units deposit objects in a batch and collection-centric context, while others coordinate the deposit of single objects submitted by content creators
- Self-deposit processes contain unique review and mediation steps vs. staff deposit: the ETDs mediation process further contains distinct sub-processes for each of the participating schools
- ETD deposits involve dependencies with graduation and academic program approval for publication/release
- Approvals for “publishing”/visibility vary – sometimes self-deposited objects are immediately made visible, and sometimes they must undergo approval in order to be disseminated
- Some deposit processes are tightly coupled with systems and data sources external to the Emory Libraries, such as Emory Shared Data, Emory Human Resources data, EmoryFIRST; research data is currently deposited into the Odum Institute-hosted Dataverse; some process maps include dissemination to third party platforms such as HathiTrust
...
- DLP implementation teams should coordinate with service owners to adapt existing pre-deposit activities and workflows as needed to work with future repository software: current state repository-related applications may provide more specialized and unit-customized SIP preparation functions than DLP/Hyrax will provide.
- Service owners should also adjust workflows and practices as needed relative to the new Digital Preservation Policy. The Digital Preservation FRG’s SIP Decision Document describes the elements required of a SIP:
- Content deposited to Emory’s preservation repository must include the primary characteristics identified in Emory’s Digital Preservation Policy. Secondary characteristics may be deposited alongside the primary characteristics.
- The Digital Preservation Policy further elaborates on these elements.
- The Archival Information Package (AIP) specification also describes required and optional files and datastreams for inclusion in the preservation object.
- Implementation teams should coordinate with service owners to investigate relationships between self-deposited content across self-deposit workflows (e.g. relationships between ETDs, OpenEmory, and research data created by Emory scholars)
- Implementation teams should investigate Hyrax roadmap for batch-upload capability for importing from spreadsheets
- Monitor impacts for current deposit activities relative to cloud hosting/storage (in scope for the Technology Implementation Working Group and Technical Design Phase)