@carly.robinson We think about persistence a lot! Have you seen Andrew Treloar’s '5 persistencies?" (see here). It’s a really helpful breakdown of the different ways in which a PID system is (or should be) persistent. We have used it to audit the DOI System.
The first thing to think about is the persistence of the identifier as a thing. We believe that PIDs should never be deleted although there may be edge cases for which it is justified (e.g. GDPR). However for the vast majority of DOIs we think there are broadly speaking two situations:
Either the DOI should never have been minted in the first place, in which case we would resolve it to a tombstone page that says that
It was minted in error and a correct DOI exists, then we use aliasing to point to the correct one
The persistence of the binding between identifier and object is obviously very important. We believe that a PID must resolve to something otherwise what is the point? We have processes to check that DOIs do resolve to where they should - although this is much harder to do in practice than you might think. In the unfortunate event that a (valid) PID no longer resolves, we think there should be some sort of “tombstone” page that displays useful information (e.g. the metadata).
The persistence of the object itself is tricky for a PID provider. In an ideal world, we would only work with people who can guarantee the persistence of the objects they manage! In practice, all we can realistically do is to set policy and share best practices, and try to mitigate with metadata.
Finally, there is the persistence of the PID service / infrastructure. We distinguish between disaster recovery and business continuity, Dealing with disaster recovery is relatively straightforward: think back-ups and archiving services such as CLOCKSS or PORTICO. It’s best practice for any information service provider.
Business continuity is harder. What should happen in the event a PID service provider is unable to continue offering services for a reason such as funding being withdrawn or bankruptcy? This is much harder problem than you might think - there is a lot of embedded know-how in organisations that is very hard to archive or escrow. Obviously the best way is to make sure it never happens or that there is some kind of fall back, or in the worst case, people close to the failed entity have the right to restart afresh.
So we believe the way to deal with this is to consider it as a business risk and to mitigate this risk. So for instance, our not-for-profit status protects us from a predatory takeover, we also have explicit terms in our agreements in the event of bankruptcy to protect the service and allow a smooth transition, we maintain cash reserves so we can meet our financial liabilities, and so on.
I hope this is helpful
It’s an ongoing discussion point for us and I’m more than happy to share out thinking with you and others who are interested.