As of July 23, 2015:
HYDRADAM2 FUNCTIONAL REQUIREMENTS
HydraDAM1 was self deposit, self contribute descriptive metadata. HydraDAM2 will focus more on self discovery using pre-created descriptive and technical metadata.
IU will be using this as the preservation DAM system for their institutional digitization project. Technical metadata will be created by the digitizing vendor. Descriptive metadata has already been created for some content using Avalon or IUCAT so HydraDAM2 needs to be able to ingest the metadata that exists.
As the preservation and mezzanine files plan to be ingested into the HPSS system via HydraDAM2, there needs to be fixity audits periodically scheduled to verify file integrity.
WGBH will be using HydraDAM2 for search and discovery of their digital assets that are stored on offline LTO tape and spinning disk hard drive. Current infrastructure at WGBH doesn't allow for moving batches of large files across a network using an HSM efficiently. Technical metadata is created as part of the digitization process or when the media file was created in a camera, or transcoded. Files are preserved on LTO tape on a local machine. That metadata is then stored in a Filemaker database. Descriptive metadata is created as part of the production process and stored in a separate Filemaker database. HydraDAM2 will be able to ingest a combination of those two databases' records for technical and descriptive metadata as well as allow for search and discovery.
In both cases, proxy files are created already, so that function could be stripped out entirely, as well as web-based self deposit if we should choose. However, as WGBH begins to ingest born digital files from production units, the need to create proxies still exists, but needs to be able to happen as a batch process and not become a bottle neck function in ingestion of files. (Hence WGBH has determined that proxy creation is better served outside the system and ingested along with the original file and metadata.)
The only processing that needs to be done on the installed HydraDAM server is fixity checking.
- Develop application based on existing HydraDAM
- Updated Sufia build with Fedora 4 (HDM-136)
- Utilize Portland Common Data Model (HDM-9)
- Application must be able to configure for 1) Offline storage (LTO, Hard Drive) or 2) HSM Storage (HPSS) (HDM-7)
- Documentation for install as well as use by non-technical staff members
- Implement HydraDAM2 offline storage configuration at WGBH (HDM-7)
- Implement HydraDAM2 HSM storage configuration at IU (HDM-7)
- Ingest into the repository technical and descriptive metadata records without media file (HDM-10)
- Ability to attach media file after the ingest of technical and descriptive metadata (HDM-154)
- Function to turn off proxy file creation (HDM-8)
- Ability to point to proxy files from an external node
- (hsm storage)Allows download of proxy, mezzanine, or master files
- Allow for scheduled updates, manually or automatically, of the metadata records via IUCAT, Avalon(IU) or PIM/MARS/DAM(WGBH)
- Repository search based on both technical and descriptive metadata
- HSM staging status notification
- Fixity checking of HPSS stored files
- Fixity checking of metadata files and Fedora relationships
- Fixity checking takes place as part of file operations, as a one-off user/administrator action, or on a scheduled basis
- Ability to specify what kind of digital file fixity check is processed (MD5, SHA1, SHA256)
- Faceted Solr searching on technical and descriptive metadata
- Export the Fedora repository for backup
- Support for exporting metadata to different schemas.
- Reportable user statistics (views, downloads)
- Reportable system statistics (# objects, # files, storage used, fixity check status)
- Access permission groups for users via login
- Login via single sign-on (CAS and/or Shibboleth)
- Access restrictions for metadata and files (proxy/mezzanine/master) can be based on LDAP / Active Directory groups
- Shopping cart for inquiry, or batch download (HDM-155)
- "Publish" files to Avalon for access