Sean McGrath blogged several interesting issues having to do with naming and identifiers this past week. The title of his post goes straight to the heart of this important issue: A URL producer/consumer contract. It is this social contract between information providers and consumers that is at the heart of the success of the Web. We use the Web not with an expectation of perfection, but with the realistic hope that when we click, we ‘go’ somewhere useful. Mostly this works, and when it fails, it fails gracefully (back up… go somewhere else… low cost failure).
Our tolerance for the failures is a product of their frequency and impact. In general, links to resources that are expected to be persistent are managed more carefully, and so fail less frequently. The history of efforts to reduce such failures through technology is tortuous and beyond the scope of this post, but what success as has been achieved falls largely in the category of tools that make easier the job of fulfilling the social contract that Sean’s note alludes to.
Sustaining links to important resources has everything to do with the commitment of organizations, and only to a small extent with a particular technology. Tim Berners-lee suggests that ‘cool URLs don’t break,’ but what could be cooler than his early web-presence having to do with the design and deployment of the Web? You won’t find them at CERN anymore. While Web historians may relish the challenge of reconstructing these early and delicate threads, they just aren’t accessible to most of us in their original context, and this is in part due to the fact that Tim and his cohorts had other important things to occupy their attention. CERN, which as an organization might have been expected to be interested in their curation, wasn’t. There’s all that physics to do afterall!
The single important predictor of persistence of identifiers and their resources has to do with the organizational commitment of the managers of content. It’s a social contract. The best we can hope for from technology is for it to make it easier for us to meet those commitments: tools that make management of URI collections easier and cheaper. PURLs are a step in that direction, but not a wholistic solution. More on this directly….