Catalog Record Identifiers: Keep the Handle When the Record Moves
How to keep a stable identifier for a catalog record, separate it from the label, and say what that identifier must still resolve to.
- 01 Separate the handle
- 02 Reuse or mint
- 03 Keep it stable
- 04 Resolve after change
An identifier names the record
A catalog record identifier is the handle other steps use when they mean this record and not a lookalike. The public name, the source file, and the screen label can all change. The handle should not change with them.
W3C’s Data on the Web Best Practices, a Recommendation of 31 January 2017, says in its data-identifiers section that URIs are dumb strings. They carry no semantics. Their function is to identify a resource. That statement is about identifiers on the web. The editorial rule that travels is narrower and still useful inside a catalog: do not pack the title, the category, or the owning team into the identifier. Those facts belong in fields. If they live in the handle, every rename becomes a broken reference.
The ownership and update rules decide which copy may change a field. They do not mint the handle. Write the identifier rule before the first import, or the import will invent one out of a column that was only a label.
This diagram scrolls sideways on a narrow screen.
Reuse a handle that already identifies the thing
Best Practice 10 says to reuse other people’s URIs as identifiers within datasets where possible. The same section says that if you cannot find an existing set that meets the need, create your own and follow patterns that keep those URIs persistent. The recommendation is about data on the web, so that other datasets can point at the same thing. It is not an order to replace every internal code with a URI on day one.
For a catalog, apply it in this order. If the thing already has a public identifier that you are willing to keep stable, store that identifier and map your local code to it. If it does not, mint a local code that you control, and write the rule that turns that code into the public handle. Best Practice 10 notes that a dataset can keep locally unique identifiers and supply the data that turns them into globally unique URIs. The illustration there is a transport dataset, not a commercial catalog. The part to copy is the split: a short local code, plus a written expansion rule. The part not to copy is the sample path.
Do not mint a second public handle because a second source file arrived. Two handles for one record become a duplicate problem, and the page on duplicate, missing, and conflicting records is where that failure is classified. This page only says: decide reuse before you mint.
Design the handle so it can survive the record’s life
Best Practice 9 says to identify each dataset by a carefully chosen, persistent URI. Its intended outcome is that the dataset, or information about it, stays discoverable and citable through time, regardless of status, availability, or format. Again, the subject is a dataset published on the web. A catalog record is not always a dataset. Where you do publish the record, or a page about it, at a public URI, that outcome is the bar: the handle still finds the record or an explanation after the title changes, the file moves, or the record leaves the active set.
Persistence is a design choice, not a hope. Leave the supplier name, the campaign, and the channel out of the public handle. Those are fields. They change. A handle built from them will be rewritten by the next reorganization, and every stored reference will miss.
A database primary key can be the local code. It becomes a bad public handle if the database recycles keys, or if a migration assigns new ones and the old ones are dropped. If the key is recycled, it is not this record’s identifier. Write that limit next to the key.
This table scrolls sideways on a narrow screen.
| Decision | Question | What to record |
|---|---|---|
| Reuse | Does a public identifier for this thing already exist? | The existing handle, and the local code mapped to it |
| Mint | Who is allowed to assign a new handle? | The pattern, the owner, and the date the pattern started |
| Rename | Did the label change, or the meaning? | Label changes keep the handle. A new meaning is a different record |
| Move | Did the record change system or file? | The public handle stays. The storage location is a field |
Say what the handle must do after the record changes
An identifier that only works while the record is in the active set is a temporary filename. Retiring a catalog record is the page for a withdrawal that is meant to last. The requirement from this page is smaller: the handle’s behavior on rename, move, and withdrawal is written before those events, not invented during them.
Best Practice 9’s outcome mentions status and availability on purpose. A record can be withdrawn and still be citable. Citation needs the same handle. If the only response is an empty failure and the handle is gone, later readers cannot tell a typo from a planned withdrawal.
Internal-only codes can follow a shorter rule, and you should write that shorter rule explicitly. A warehouse key that is never published does not have to dereference on the web. It still should not be reused for a different record. Say which of your identifiers are public and which are local. One sentence that calls every column “the ID” will be read both ways.
What this page does not claim
Best Practice 9 and Best Practice 10 are about datasets and about identifiers on the web. They do not choose a SKU format, a barcode standard, or the primary key of a particular database. Section 8.7 of the same recommendation is where the “dumb strings” wording appears. This page uses that wording so a catalog does not hide meaning in the handle. The patterns, the reuse order, and the split between local code and public handle are the publication’s method.
The recommendation also names redirection services and DOI-style identifiers as ways a publisher can avoid managing a URI space directly. This page does not adopt either of those services. If you use one, say so in your own identifier rule and keep the persistence promise in writing.
When the identifier should change
When does a new label need a new identifier?
It does not. Change the label field. Keep the handle. A new identifier here splits one record into two and leaves the old references pointing at a name you no longer use.
When needed: A rename, a spelling correction, or a language update.
When is a second identifier legitimate?
When it names a different record, or when it is an explicit local alias of the same handle and the alias rule is written down. A second public handle for the same record is a duplicate, not a convenience.
When needed: A new item, or a documented alias that still resolves to the same record.
When can an internal key differ from the public handle?
When both are named, and the expansion from the key to the public handle is written. The key may change in a migration only if the public handle does not, or if every stored reference is migrated in the same change.
When needed: A system move that must not break the published identifier.