When a web address is not enough: permanent identifiers for research
If your organisation publishes research, you already know the quiet problem with links. A report goes up, people cite it by its web address, and then the site is redesigned, the domain moves, or the publication changes hands.
The citation still exists. It just no longer resolves to anything.
That is what a Digital Object Identifier is for. A DOI is a permanent handle that belongs to the work rather than its current location, so a reference made today still resolves in a decade, wherever the record now lives. For a policy research body, it is the difference between publishing on the web and publishing something citable.
The Analysis & Policy Observatory is Australia's open-access repository of public policy and research, holding more than 43,000 resources. At that scale, minting an identifier is a workflow question rather than a technical curiosity.
Done by hand, each one means assembling XML, calling the national service that issues them, and pasting the result back onto the right record.
Our part in the work: a portable Drupal module, built to a date
Media Insights, who have worked with the Observatory for many years, brought us in as their engineering partner to build it. We provided:
- the architecture
- the Drupal(Opens in a new tab/window) engineering
- delivery onto the client's managed hosting through an automated build pipeline
All of it against a specification and a delivery date agreed up front.
We designed it the way you design something meant to outlive its first installation: a portable, installable module with its own settings rather than site-specific code.
The site chooses which content type gets identifiers, and the fields already on it are mapped onto the metadata through the interface, so another site with entirely different field names can install it and map instead of forking it.
For a client, that portability reads as ownership: what you paid for is not welded to the site it was built on.
How it works for the people using it: request, approve, mint
An identifier is permanent, and that shapes everything. Once one is issued and registered with an outside authority, it cannot meaningfully be withdrawn, so minting is treated as a decision rather than a button.
The flow is deliberately short:
- a contributor who has published something requests an identifier for it
- editors see every request on a single dashboard, with the record, its published state and who asked, and mint or cancel from there
- everyone is notified at each transition, including when a request is cancelled, so "no" is a real answer rather than silence
For a client, that reads as accountability: every request has a visible state and an action attached to it.
On a workflow with a human approval step, what goes wrong is rarely technical. It is a request sitting unseen while someone waits and wonders.
Records change after publication, so the module can also submit updated metadata for an identifier that already exists. Correcting the description behind a permanent identifier is what keeps a system accurate instead of frozen on the day it launched.
Built to the standard, not to the site: DataCite metadata in Drupal
The identifier attaches to the landing page for the work rather than to the file, because a citation should point at the catalogue record, not a PDF that may later be replaced.
Behind it, the data model follows DataCite, the international metadata schema the Australian service was built on, rather than a shape that happened to suit the site. Every element has a direct equivalent in the schema, so if a record can be assembled, it can be minted. Services and resellers can change over the years without the model changing underneath them.
A rule we carry into any integration of this kind: whatever an outside authority issues has to survive an ordinary save. An identifier that quietly vanishes when someone updates a record can fail silently, and the loss may not surface until the day someone tries to cite the work.
What it adds up to: a delivered module and a partnership still running
The module was delivered and accepted, and it went into service minting identifiers against published records.
A repository of more than 43,000 resources, and a partnership still producing work nearly a decade later.
The more durable outcome is the relationship. This was the first thing we built with Media Insights for the Observatory, and nearly a decade later that partnership is still producing work drawing on the same catalogue.
A small, tightly specified integration is often the best first project a partnership can have: finite, checkable, and a fair predictor of how the next one will go.
For publishers whose records have to outlive their URLs
Everything on this page is 3 of our services on one tightly specified integration: architecture modelled on an external standard, Drupal development shaped as a portable module, and delivery onto managed hosting through an automated build. Work of this shape, bounded and specified before it starts, is also where AI-assisted delivery earns its place.
If you run a research repository, a university publishing arm, or a government body that publishes evidence, this is the shape the engagement takes: a specification and a delivery date agreed up front, a workflow your editors can actually work, and a module you can take with you.
If you are working out how to get permanent identifiers onto what you publish, or you are minting them by hand today, tell us how you publish.