Retiring a Catalog Record Without Losing the Identifier
How to withdraw a catalog record on purpose, keep its identifier, and tell that withdrawal apart from a rollback.
- 01 Name the record
- 02 Put it in a release
- 03 Keep the identifier
- 04 Leave an explanation
Retirement is a planned withdrawal
Retiring a catalog record means the record leaves the active public set on purpose, and the identifier remains. The record is not “fixed” by deleting the handle. People and other records may still hold that handle. If it vanishes, they cannot tell a typo from a decision.
This is not a rollback. A rollback returns a release to a previous named set because that set was wrong or unsafe. The release page is where the return point is chosen. Retirement is a change you meant: the record should no longer be offered, and the handle should explain that. Putting a retirement through the release log is still required. The log is how a later reader sees that the withdrawal was in a named set, not a stray delete.
The permission to retire is separate from the permission to edit a public name. The source-of-truth page already asks for that split. A person who can correct a title is not, by that fact, allowed to withdraw the record.
This diagram scrolls sideways on a narrow screen.
Keep the identifier and say what a visitor finds
W3C Best Practice 27, in the Data on the Web Best Practices recommendation of 31 January 2017, says that when removing data from the web, preserve the identifier and provide information about the archived resource. The intended outcome is that the URI still dereferences to the resource or redirects to information about it. The section around that practice says a bare deletion is a poor result: a “not found” response does not tell the reader whether the absence is permanent or temporary, planned or accidental.
The recommendation then separates two cases. If the resource is gone entirely and is not available by any route, it points publishers toward an HTTP 410 response, whose meaning in the cited HTTP specification is that the resource is intentionally unavailable. If the resource has been archived, it points publishers toward a redirect to a page that says where the archive is and how to ask for it. The illustration uses a superseded dataset, not a shop record. The boundary matters. Best Practice 27 is about data on the web and about dereferencing a URI. It does not describe the status column in your database.
Where the catalog identifier is a public URI, follow that outcome: the URI still leads to the record’s explanation, to a replacement, or to a clear statement that it is gone on purpose. Where the identifier is only an internal code, write the same two outcomes in your own words. Do not pretend that an internal status value is an HTTP code. Do not drop the code and reuse it for a different record. Reuse is how a retired handle starts naming something else. The page on catalog record identifiers is where that stability is set.
This table scrolls sideways on a narrow screen.
| Change | Question | What remains |
|---|---|---|
| Rollback | Was a previous release the return point? | The previous release identifier, and a log line for the withdrawal |
| Retirement | Should this record leave the active set on purpose? | The record identifier, plus an explanation or a replacement |
| Merge | Are two records the same thing? | One survivor, chosen by the duplicate rule, and the other handle still explained |
| Reuse of the handle | May this identifier name a new record? | No, if it was ever public or ever stored as a reference |
Write the explanation as a fact, not a story
The explanation names the record identifier, the date or the release that retired it, and whether a replacement identifier exists. If a replacement exists, name it. If it does not, say that no replacement was assigned. Do not invent a successor to make the page look finished. Do not estimate impact, and do not name a customer.
A merge from the duplicate guide can end in a retirement of the non-surviving handle. The survivor decision happens on that page, under the ownership rule. This page only receives the result: the non-surviving identifier is retired, and it points at the survivor or at an explanation. It does not reopen the question of which row was right.
Keep the retired record readable to the people who operate the catalog for as long as the log cites it. A public page can show less than the internal record. It should not show nothing. “Gone” with the identifier and the release name is enough. A blank error is not.
Put retirement in a named release
Retirement uses the same stages as any other catalog change. Intake is the decision and the permission. Check confirms the identifier exists, that this actor may retire it, and that a replacement, if any, is a real record. Release names the set and writes the log. A retirement applied by a direct edit, outside a release, will not have a return point and will not have a version of the rules.
Rollback of a bad retirement is a new release that restores the previous status, not an invisible undelete. If the public URI spent a day explaining that the record was withdrawn, the log should show both the withdrawal and the restoration. Best Practice 27 does not forbid that sequence. It forbids losing the identifier in the middle of it.
What this page does not claim
Best Practice 27 does not require every private catalog to speak HTTP. It does not choose how long you keep an archive, and the one-year holding period in its example is that city’s policy, not a rule for you. It does not decide which of two duplicates survives. The status split between rollback and retirement, the ban on reusing a public handle, and the contents of the explanation are this publication’s method.
When a record should be retired
When is retirement the wrong tool?
When the previous release was simply wrong and you want that set back. That is a rollback. Retirement says the record should stay out of the active set even after the next good release.
When needed: A bad import you intend to undo, rather than a record you intend to withdraw.
When do you name a replacement?
When one exists and its identifier is already in the catalog. Link the retired handle to that identifier. If you are still deciding, retire nothing yet, or retire with an explicit note that no replacement was assigned.
When needed: A successor record that is already real.
When can the identifier be dropped?
This method does not offer that case for a handle that was public or that other records stored. An internal code that was never published and never referenced can be retired under a local rule you write yourself. Write the rule before you use it. Do not borrow it for public handles.
When needed: A code that never left the system that minted it.