This document is to clarify the differences between the ideas of "deleting" a resource from Fedora and "purging" a resource from Fedora.
Delete
When you delete a resource from Fedora it is replaced by a "tombstone" that is returned when you try to access the resource.
The tombstone serves two purposes, the first is identify that a resource did exist at this URI but is no longer there and the second is to stop the reuse of the URI. Some of the reasons for this design decision come from the Tim Berners-Lee article Cool URIs don't change.
At the OCFL layer a tombstone is indicated as a change in the Fedora Header File for the deleted resource. Fedora uses these sidecar files to track information the application needs for each resource. Nothing is removed when the object is "deleted" instead the sidecar file fcr-root.json file is updated to change the value of the "deleted" key from "false" to "true" (as well as the "lastModifiedDate" value)
.
└── ocfl-root/5ce/631/395/5ce63139564a3a617705f0169f200433debd2dd4b63b3fb583a5fe9f7de76539/
├── 0=ocfl_object_1.1
├── inventory.json
├── inventory.json.sha512
├── v1/
│ ├── inventory.json
│ ├── inventory.json.sha512
│ └── content/
│ ├── fcr-container.nt
│ └── .fcrepo/
│ └── fcr-root.json
└── v2/
├── inventory.json
├── inventory.json.sha512
└── content/
└── .fcrepo/
└── fcr-root.json
Purge
You CANNOT purge a resource that is part of an Archival Group. All resources inside an archival group share the same OCFL object with the actual archival group object. You can only purge the archival group object, which removes all parts of the archival group.
It is understandable that in some situations you might want to completely remove a resource and rebuild it. In this situation you need to "purge" the object from your repository. To do this you make a "delete" request to the tombstone itself.
You can find the tombstone's URI by checking the headers returned on the deleted resource.
> curl -ufedoraAdmin:fedoraAdmin -i http://localhost:8080/rest/test-resource HTTP/1.1 410 Gone Date: Fri, 14 Jul 2023 14:27:19 GMT Set-Cookie: JSESSIONID=node01k1ft2kt2jxez1glanmybctn124.node0; Path=/ Expires: Thu, 01 Jan 1970 00:00:00 GMT Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Thu, 13-Jul-2023 14:27:19 GMT; SameSite=lax Link: <http://localhost:8080/rest/test-resource/fcr:tombstone>; rel="hasTombstone" Content-Type: text/plain Content-Length: 89 Server: Jetty(9.4.44.v20210927) Discovered tombstone resource at /test-resource, departed at: 2023-07-14T14:26:46.319886Z
The Link header in the above response with the rel of hasTombstone gives you the address of the tombstone for the requested resource.
A tombstone only allows a DELETE method, no other interactions are allowed.
Sending a DELETE request to the tombstone of an resource completely removes that resource.
In contrast to a delete, a purge completely removes the resource from your OCFL file-system. It also removes any empty parent sub-directories up to the OCFL root directory (called "ocfl-root" by default).
For example looking at the OCFL root directory of a repository with only the deleted resource "test-resource" before the purge:
.
└── ocfl-root/
├── 0004-hashed-n-tuple-storage-layout.md
├── 0=ocfl_1.1
├── 141 <- the repository root resource
├── 5ce <- the deleted resource "test-resource"
├── extensions
├── ocfl_1.1.md
├── ocfl_extensions_1.0.md
└── ocfl_layout.json
After purging the resource "test-resource", the OCFL root looks like this:
.
└── ocfl-root/
├── 0004-hashed-n-tuple-storage-layout.md
├── 0=ocfl_1.1
├── 141 <- the repository root resource
├── extensions
├── ocfl_1.1.md
├── ocfl_extensions_1.0.md
└── ocfl_layout.json
Because no other resources in the repository were stored within the "5ce" directory in this example, the entire directory structure was removed. See Fedora OCFL Object Structure#StorageHierarchyLayout for details of how these subdirectories are named.
