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
>>
>