All of the 'major' PID schemas I'm aware of — DOI, Handle, ARK, PURL — can ensure global uniqueness via the use of namespaces, much like DNS (as you mention). I can't ensure that hostname "ftp" is globally unique, but "ftp.lackoftalent.org" is mine and mine only.

PURLs function in the same way. ARKs, DOIs, and Handles use the same idea but do not use DNS names in their identifiers. Instead, you get DOIs and Handles like 1702.2/stuff-1234, or ARKs like ark:/13030/xyzabc123q, where the "1702.2" and the "13030" are assigned to name assigning authorities. It's a fancy phrase for "namespace."

I'm sure there are PID schemas out there that do not ensure global uniqueness, but it seems most of the major players have already accounted for this.

All of which is not to say there aren't significant problems with our implementation of persistent identifiers. Here are the big two on my mind right now:

1) If your schema relies upon HTTP redirection to access the actual resource (which is true of DOIs, Handles, and some implementations of ARK), the impersistent URL to which your PID redirects will be bookmarked (and cited downstream) by your users. This is a major problem, in my opinion, with PID schemas that redirect rather than proxy.

2) If your organization is already making a commitment to persistence, why do you need another schema (Handles), another piece of software (CNRI Handle server), and so forth when you could just as easily commit to a sane and persistence-minded information architecture? That is, why not make your URLs persistent (as the W3C does and Tim Berners-Lee recommends)? This solves the impersistent bookmark and downstream citation problems.

I'm with you — say "no" to fiefdoms and sandboxes. :)

If you look at the system in place for resolving domain names, there is a distributed system, but there are 13 Root nameservers which sort of govern this and talk to each other and lower level DNS servers in their zones to ensure proper DNS resolution. PID would have to work in much the same way, otherwise we'd all simply playing in our own little sandboxes, right?

I'm not sure I follow the second point, for that matter. What is an authoritative, definitive datasource? It could be that we're using different terminologies but are actually on the same page.

There is no a priori reason to prefer IRC over other forms of chat or communication. I only use IRC because, well, that's where the #code4lib people chat, and I really value that community. Mailing lists, blogs, and forums just aren't the same. Chat seems less formal, and doesn't feel like you're "committing" a statement (such as to a blog post, or a mail message, which will likely be picked up by Google and the Internet Archive and be available to the public in perpetuity).

IRC is also much more immediate. Have a problem you want a quick answer on? Chat is nice for that.

Mostly, for me, it's all about the community. The folks over at #code4lib are a great bunch of knowledgeable, accomplished, and interesting people, most of which encounter the same sorts of issues I do in my career.

I'm a noob to this topic, but I'm interested. Also, can someone explain the appeal of IRC chat to someone who has never used it? Why not use other forms of chat, email lists, blogs, etc.?