Re: URI persistence Was: Use Case: BetaNYC 3/5

Hoi Makx,


> 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.
>
Indeed but I'm afraid this is inevitable. There is a shortage of unique
identifiers so these get commonly re-used, think of phone numbers that gets
re-assigned or entries in classification trees that get new meaning
associated. I fully agree this is not desired and that we should argue this
is not a good idea but in the mean time we can not ignore this
*will*happen. Not sure what the implications will be for the documents
produced
by this group, if any, but we can keep an eye on it.

  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.
>
Yep. Keeping the archivists aside (I'm not sure I fully agree with you
there), I think we would be both happy seeing a line such as "the entity
publisher ensures the URI is available for at least X years" in the BP. As
for the previous problem, there is no way to ensure this will work out as
promises only engage who believe in them. But, at least, this will make
data publishers aware that if they publish something they should think of
making that stable for some time. Even if the said time spans out of their
period of control (c.f. political mandate, project duration, ...).


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

Christophe

-- 
Onderzoeker
+31(0)6 14576494
christophe.gueret@dans.knaw.nl

*Data Archiving and Networked Services (DANS)*

DANS bevordert duurzame toegang tot digitale onderzoeksgegevens. Kijk op
www.dans.knaw.nl voor meer informatie. DANS is een instituut van KNAW en
NWO.


Let op, per 1 januari hebben we een nieuw adres:

DANS | Anna van Saksenlaan 51 | 2593 HW Den Haag | Postbus 93067 | 2509 AB
Den Haag | +31 70 349 44 50 | info@dans.knaw.nl <info@dans.kn> |
www.dans.knaw.nl


*Let's build a World Wide Semantic Web!*
http://worldwidesemanticweb.org/

*e-Humanities Group (KNAW)*
[image: eHumanities] <http://www.ehumanities.nl/>