My last two posts were motivated by Sean McGrath’s piece on
URLs and the social contracts they imply. So, too, this one.
Sean argues for the network-value of a naming convention for URLs, namely, the inclusion in URLs-of-permanent-intent of the string ‘purl’. When I first read his post, my egocentrism led me to think he was alluding to the PURL system, launched by OCLC a dozen years ago in response to our frustrations with the ground-hog-day character of the URN meetings in the IETF. We launched PURLs with an expectation that they would be widely adopted and deployed by all right-thinking Web managers (we had a LOT of silly ideas like that…). PURLs have never been as widely deployed as were our hopes, but they are still alive and growing, and remain both useful and an instructive data point in the evolution of the Internet naming architecture.
One reason I was so ready to conclude that Sean was talking about PURLS is his argument:
I am thinking of nothing more complicated than a social naming convention. What if permanent URLs contained the fragment '/purl/' for example? Would that not do the trick? As a consumer, I look at example.com/purl/info12.html and can immediately infer that it is a good candidate for bookmarking.
From a URL consumer's perspective, this would be very handy I think. From a URL producer's perspective, it would also be very handy. In effect, it would allow URL producers to send out signals to the world. One signal would be: 'this URL is a good bookmark candidate. We won't be changing it and even if we change our systems internally, we will make every effort to ensure that this link will continue to work.'. The second signal would be 'This URL is not a good bookmark candidate. Bookmark it at your own risk.' Simply leaving '/purl/' out of a URL would send the latter signal.
No
new technology added! An approach predicated
on the URL-equivalent of a smilie, a token that says that someone
is looking after this identifier. It is
an important component of the added-value that we envisioned for PURLs, as it
happens. People will see http://purl.og/.... and say... hey, a URL for the long haul. OK… we’re not exactly talking
a firestorm of adoption. But the point was true
then and true today.
Back to
permanence and persistence. As I harbored
the delusional notion that Sean was
singing about our PURLy fates, I thought… “oh… he got the P part wrong
(invoking the word permanent rather than persistent)” It would appear, in fact, that he had arrived independently at a
related acronym.
The distinction is small, but important. What can permanence mean in a technological world where only one of twenty students in a masters level information science class recognized the phrase NCSA Mosaic? (Well, it means that change is unrelenting and they don’t listen to big band music much either). And follow this link (top of the Google search set), if you think I'm blowing smoke:
NCSA Mosaic Home Page
Creation and history of the browser. All versions available for download.
archive.ncsa.uiuc.edu/SDG/Software/Mosaic/
I feel unlucky.
Even in
the hallowed halls of LibraryLand, we are (justly)
reluctant to talk about preservation in terms longer than the odd millennium. Much of the discussion surrounding business models
for digital preservation has to do with service contracts and the cost of assuring the integrity of a given bitstream for a given interval. It is NOT permanence we’re talking
about. It is persistence. And the definition refers to a business
process more than it does to a point in the past or future.
If you
have an identifier used for tracking the progress of a laptop from its point of
manufacture in Shanghai to your doorstep, the business process that is
identified (a shipment of a consumer good) is concluded in a period measured in
hours or days (mine took 40 hours). Soon
after, the identifier is so much digital chaff, duty done. But certainly
persistent in the context of its intended use.
If we’re talking about cultural heritage assets, we have expectations measured in centuries. In either case, the success of the identifier is tied to the life cycle of the asset or process, not to a calendar. Thinking of our identifiers in these terms helps avoid staring towards a vanishing point. Sometimes.
Embedding "purl" in an identifier is no more than wishful thinking on the part of the namer. It matters, but very little -- certainly not more than inserting "urn", "hdl", or "doi" in front of an identifier.
Whenever I think about the amazingly difficult task of achieving persistence, I think less about making it work than about not making it fail:
1. Non-opaque identifiers are sure political problems for our descendants -- does your organization understand this simple maintenance reality?
2. If what matters is organizational commitment and services, what conventions do your URLs obey to connect users to services and commitments? As Stu knows, ARK identifiers are URLs defining such conventions.
3. A big attraction of id schemes such as "hdl" and "doi" is the concept that you might publish a resolvable identifier that doesn't contain your own hostname. But why buy into a complex and special-purpose id technology that will become an albatross to carry foward when for $60 a year you could join or form a consortium that rents a hostname (not yours!) and runs a trivial redirect-rule-driven web server for all consortium members to publish URLs under?
Achieving persistence is a long journey that depends alot on luck. We'll never be able to guarantee persistence, but it's helpful to enumerate the great ways to screw it up.
Posted by: John Kunze | January 31, 2006 at 06:51 PM