I enjoyed this new article by Dorothea Salo. Clear thoughts, written clearly. (Sometimes you don’t even find one out of those two in ‘the literature’; we readers deserve both).
Salo writes, among other things:
Because existing name authority files cover only a fragmentary portion of the universe of article authors, the ability to query them directly can safely be left on the back burner. It might be worthwhile to consider (as EPrints has) leaving hooks for such query functionality, however, in hopes of one or more emerging identity-management solutions covering enough of that universe to be worth the querying.
I would add, not just the ability to query such ‘authority files’, but the ability submit new name ‘headings’ to such identity databases.
Reading Salo’s article, the proper technical solution seems obvious to me (recognizing that ‘obviousness’ is usually a sign that the commenter (me) doesn’t know enough about the domain being discussed) — a name authority file that not only allowed authors, submitters, librarians and repository managers to query an ‘authority file’ integrated seamlessly into their workflow — but also allow them, when not finding the name they want in the file, to automatically submit whatever new name they type in to be included for next time, in this centralized authority file.
Yes, ‘wiki style’. Meaning just about anyone can add a name. (Or at least anyone with access to deposit or manage documents in an participating repository of any sort — which is just about anyone). (And anyone interested can later clean it up, merge it with an existing authority record, for instance). The previous highly controlled expert-editing-only model of authority work has failed, if it worked, it would be working already for the domain Salo’s talking about, but it isn’t, and Salo provides some context to understand why.
So wiki style, yeah.
The technology is not hard. The infrastructure would not be free, but also not cost a fortune.
If only a cooperatively funded library organization existed that could provide such crucial technical infrastructure for library sector projects, provided on a non-profit cost-recovery basis, efficiently and no more expensively than the resources demanded justify.
What, you say, we’ve got an organization with just such a mission, and it’s called OCLC? Hmm, interesting. Wouldn’t it be nice if they were a step ahead instead of five steps behind the current needs of the library sector, and if they really did have a business model capable of supplying services on a lean mean cost-recovery basis.
Bibliographic Wilderness 
Can I have a pony? :)
It does seem sometimes that libraries are perennially fighting the last war. If we get enough uptake on the BibApp (and things are looking quite promising at present), maybe that can form the kernel of greater things — and it’ll be peer-to-peer, so no need to goose a gorilla!
Many thanks for the kind words.
I have said something about these issues in my latest blog post “UMR – Unified Metadata Resources” – http://commonplace.net/2009/04/umr-unified-metadata-resources
I’ve been researching this question for years and there are some surprising difficult issues. Here is example of a prototype that had some slight success: http://alcme.oclc.org/wikid/. Ironically, its main problem was that it was *too* much like a wiki. More recently, I was the architect of the WorldCat Registry, which was designed to support CRUD operations on arbitrary sets of “collections”: http://worldcat.org/registry/Institutions
There are a wide variety of issues that have hindered these “intuitive” efforts and I didn’t really comprehend the reason for these difficulties until very recently. In a nutshell, the problems can all be boiled down to these three:
1. Misunderstanding Web standards
2. Misunderstanding domain modeling
3. Misunderstanding the difference between Real World Objects and Web Documents.
Get any one of those three things wrong, and you are doomed to irrelevance. Unfortunately, even if you get them right it’s likely that nobody will listen because they are too busy building APIs. :-(
Jeff