Deaccession Dataset - Delete Files but Keep Tombstone Metadata Record

Currently, a user or administrator can deaccession a dataset, make the files publicly inaccessible, and create a tombstone metadata record. However, in this situation, the files from that dataset are not deleted, they're still available to administrators or dataset creators/owners. In other words, the storage associated with those files is still in use.

A Super User can use an API call to delete a published dataset, but this also deletes the tombstone metadata record and essentially removes all evidence of the dataset ever existing.

In planning for long-term preservation, repositories may wish to select some datasets or Dataverse collections for deletion after a certain period of time (e.g., 10 years) as per their Collections Development policies. Others may wish to move the data to long-term storage via digital preservation processes (e.g., Archivematica). In either case, there may be a need for the repository to delete the files being stored in their Dataverse repository but keep either the active or tombstone metadata record.

Deletion of files (but not metadata records) from Dataverse may become more of an issue when and if repositories encounter storage space limitations or unmanageable expenses. However, the purpose of collections development and long-term preservation selection means that not all datasets are worth keeping over the long term and may require deletion. In these situations, a metadata record that not only proves the dataset once existed but allows the PID to 'persist,' is vital.

Read the existing deaccession flow and the Super User API path for deleting a published dataset. Define how file deletion should preserve either active or tombstone metadata, including the persistent PID and evidence of existence. Done means files are removed while the selected metadata record remains available.