 |
 |
I hear what Kyle is saying, which reminds me about a UC Berkeley computing professor who made a forceful argument that the best persistent URL was an appropriately constructed "I'm feeling lucky" Google search, and there is certainly something to be said for that. Having said that, I think there is a role for libraries in minting -- and more importantly, consistently supporting -- identifiers for content. And if so, EZID seems like a good tool to do that. Roy On Fri, Jan 14, 2011 at 9:07 AM, Gabriel Farrell <[log in to unmask]> wrote: > Ditto what Kyle said. > > On Fri, Jan 14, 2011 at 12:05 PM, Kyle Banerjee <[log in to unmask]> wrote: >>> >>> We want to use urls in our MARC records and EAD to link to content in our >>> Fedora repository as well as things like web pages on our company's website. >>> What are you folks using out there for this? The Handle System seems to be >>> a good choice, or a purl service. I might also use it to link to Fedora >>> content as well. >>> >>> Ideas, suggestions? >>> >> >> I haven't found anyone who buys my take on this problem, but I'm offering it >> anyway. >> >> IMO, persistent URLs are a lost cause and are often an outright liability. >> Instead of messing with persistent URLs, the emphasis should be on >> persistent identifiers. >> >> Here's the rub -- no amount of indirection or abstraction can alter the fact >> that *people* ultimately say where things are. Purls, handles, and all other >> resolution services must be told where the item actually is in order to >> work. >> >> When this doesn't happen (and it often doesn't as I've encountered plenty of >> dead purls and handles), finding the real item is that much harder because >> you don't even have the original URL which can be a useful access point for >> finding related materials and is even helpful for finding items that moved >> elsewhere. There is also the issue that a resolution service itself is >> dependent on key things that make ordinary URLs unstable such as >> organizational changes. >> >> It's much easier to just embed a unique identifier. As a practical matter it >> doesn't matter much how this is done (though there is some utility in having >> a predictable URL friendly syntax). The item can move anywhere, access >> becomes less dependent on specific technologies, and so long as an indexing >> engine that your discovery interface can connect to has access to the item >> or metadata, you're set. >> >> kyle >> >