[tdwg-tag] LSID Sourceforge URL & LSID Best Practices

[Bob Morris]

Ah, I take your point.  However, it is not about the persistence of
the URI qua URI, but rather of the "actionability" (e.g.
resolvability) in the sense of the recent GUID report.

There are separate issues about the persistence of the identifier
itself. Some organizations permit their employees to use their DNS
names for various purposes only during the length of their employment,
after which they are required to remove all trace of that use of the
name from the internet, whether such removal is technically feasible
or not. If I recall correctly, German federal government employees are
subject to that requirement.  Even when there is no such requirement,
I should think that an organization that is the registrant of a DNS
name is likely to assert that it owns that name in most legal
jurisdictions, and can take whatever legal or technical actions it
wishes to control its use.  For example, if you produce a URI
containing the string creativecommons.org today, even with permission
of the owner of that domain name, it is quite possible that said
owner, or someone else with one or another ownership of the name
"creativecommons.org", might tomorrow be able to enforce on all users
of your URI that they stop using it.



On Tue, Sep 1, 2009 at 10:02 AM, Jonathan Rees<jar at creativecommons.org> wrote:
> On Sun, Aug 30, 2009 at 12:29 AM, Bob Morris<morris.bob at gmail.com> wrote:
>> On Fri, Aug 28, 2009 at 11:52 AM, Jonathan Rees<jar at creativecommons.org> wrote:
>>> ...
>>> The fact that ICANN and DNS work as well as they
>>> do prevents anyone from working on an administratively decentralized
>>> alternative.
>>>
>>
>> Umm, I would say that DNS is a giant success story about
>> administratively decentralized technology, but my parsing of this
>> sentence makes me believe that you think it is not administratively
>> decentralized but should be.  I suppose only the TLD servers have
>> their DNS records administered of necessity by a single agency, and
>> those provide substantial redundancy.
>
> Sorry I was not clear. Yes, DNS/ICANN is a success story for
> decentralization. I was not referring to the system as a whole but
> rather to individual domain names. If the owner of a domain disappears
> or reorganizes, then all users of its URIs are screwed - the
> well-known 404 problem. This phenomenon is what I've been calling an
> "administrative single point of failure" resulting from
> "administrative centralization", in contrast to "technical single
> point of failure". No amount of technical replication can address this
> vulnerability. Just saying that a URI is "persistent" does not make it
> so, and we know that domains go south in spite of the best intentions
> of those who originally create and disseminate its URIs, and in spite
> of the availability of technical replicas (at other locations) of the
> data that users need.
>
> The only alternative to DNS/ICANN is some alternative to it (sorry) -
> say, if domain D goes away but a copy of the needed information exists
> at E, then configure clients somehow to resolve D to E instead of to
> what ICANN tells you. This is what I've been calling "administrative"
> redundancy, which has a distinctly different character from mere
> technical redundancy. My point was just that even though such consumer
> choice would be wonderful, in principle, and resembles the way that
> historically robust systems such as the Linnaean system and libraries
> work (and that would be required in order for many kinds of URN to
> work), it is a fantasy - it's very unlikely to come about, because
> DNS/ICANN works so well. (Same argument applies to handle system.)
> Consumers are left with no power, and putatively-persistent-URI
> creators, in selfless service to consumers, have to voluntarily take
> on the burden to just "try very hard" to make domains used in URIs be
> well-behaved in perpetuity.
>
> Jonathan
>



-- 
Robert A. Morris
Professor of Computer Science (nominally retired)
UMASS-Boston
ram at cs.umb.edu
http://bdei.cs.umb.edu/
http://www.cs.umb.edu/~ram
http://www.cs.umb.edu/~ram/calendar.html
phone (+1)617 287 6466