Since March, I’ve had the opportunity of working with the UC3 team at CDL. I joined part time, you might say, as the project manager for the EZID/DataCite project. (I wear a lot of hats here.) In this role, I’m thinking in a new way about persistence. To begin with, the concept of EZID is to provide researchers (and others) a way to obtain persistent identifiers for their digital objects. As I prepare the website for the launch of our user interface, I’ve been composing an explanation of just what persistent means.
For an identifier to persist, it has to continue to identify the object, to be linked to the object, in a way that will not change if the object is moved or renamed. Persistent IDs mean never having to show a nasty 404 error message again.
The way that EZID approaches this problem is twofold: a) by offering long-term identifiers, and b) by providing a mechanism for the owner of the identifier to update the metadata associated with it. In other words, if you move your stuff to a new storage location, and if you update its address, then the linkage you established persists.
The way I think about persistence, though, extends further than identifiers. This may be a little unorthodox, but it seems to me that the notion of persistence, of continuing steadily in some state or direction, extends to organizational work practices and to institutions.
We certainly ask and respond to questions these days about the health of organizations and institutions, given the poor state of this “recovery” in general and all the bad news about California’s economy, in particular. So how can you tell if a prospective collaboration partner or service provider is likely to be around this time next year, never mind five years down the road? How do you avoid getting a nasty “vendor not found” message?
The answer, of course, is that there are no absolute guarantees. But I think there are indicators. Organizations that follow good practices, such as business continuity planning and establishment of service level agreements inspire a level of some confidence. An additional level of protection can come from what the Data Portability Project folks call a “data portability policy.” This is the idea (in part) of making transparent what data users bring in to a site (or application) and what they can get out.
Somehow, the admission that failure may occur, followed by the laying of groundwork for graceful exit, inspires the ability to continuing steadily in some state or direction, to persist. Do you agree?