For most types of digital objects to be ingested, the repository should have written criteria, prepared by the repository on its own or in conjunction with other parties, that specify exactly what digital object(s) are transferred, what documentation is associated with the object(s), and any restrictions on access, whether technical, regulatory, or donor-imposed.
The level of precision in these specifications will vary with the nature of the repository’s collection policy and its relationship with creators. For instance, repositories engaged in Web harvesting, or those that rescue digital materials long after their creators have abandoned them, cannot impose conditions on the creators of material, since they are not “depositors” in the usual sense of the word. But Web harvesters can, for instance, decide which metadata elements from the HTTP transactions that captured a site are to be preserved along with the site’s files, and this still constitutes “information associated with the digital material.” They may also choose to record the information or decisions—whether taken by humans or by automated algorithms—that led to the site being captured.
Evidence: Transfer requirements; producer-archive agreements.
ICPSR is pretty flexible with regard to its deposit requirements. The business rules behind our Deposit Form web app allow one to submit content for deposit at ICPSR with little more than a working title for the deposit and a signature. Of course, the Deposit Form also has many, many fields for collecting additional descriptive metadata, but those fields are not required (although we do appreciate all of the descriptive metadata we can get).
On the back-end of the deposit our business rules require us to create, collect, and store the following information about each file in the deposit:
- Original name from the deposit
- MIME type
- Unique ID (that we create and assign)
- Fingerprint and the method used to collect the fingerprint (currently MD5 hashes)
- Date of deposit
- Identity of the depositor