URI persistence Was: Use Case: BetaNYC 3/5

Christophe,

 

You mention this issue:

 

*  … think about time-bounded stability of URIs. That is, for how long one resource name can be expected to be stable (how cool that URI will be I don't think "forever" will be a workable answer here) and available (c.f. gov servers shutdown when budget issues arise).

 

 

I think there are actually two issues here. One is the stability of the identifier and what its meaning is, and the second one is the stability/availability of the resource that is identified.

 

On the first issue, I think we should not be afraid to say that it is bad practice to re-assign an identifier to something else – and that rule should really, hopefully, be for eternity. The classic example is the error that was made with country code CS (http://en.wikipedia.org/wiki/ISO_3166-2:CS) which started as Czechoslovakia and then was re-assigned to Serbia and Montenegro. Such a mistake will haunt us forever.

 

The second issue, the lifetime of the resource, is really the stuff of archivists. They are the masters of what to keep and what to throw away. I think that is out of scope for this group.

 

But other than that, I think that any URI persistence policy should essentially be built to support, for example by considering what will happen when stuff moves, organisations merge or go out of business, countries merge, split or disappear, protocols change and what can be done to ensure that you still can get to the resource. That’s not to say that all stuff needs to be maintained forever, but at least it should allow for stuff that is meant to be for ever and that you want to be available in 10, 20, 50, 200 years from now. 

 

I think we can offer lots of best practice advice to people in both these areas.

 

Makx.