Kyle, I like your approach, just not sure how best to make it happen.
What I dislike about purls (of all brands) is that they hide from you
some key information -- mainly, who is the maintainer of the URL. When
I see http://id.loc.gov/.... I know that I'm looking at an ID
maintained by LoC, and therefore I assign it a certain level of trust.
When I see http://purl.org/... I don't know who I am really dealing
I know that Kunze had a solution for this in his Ark spec, but it
unfortunately isn't used. (There is a way to query the URI/URL for
information about the minter/maintainer.)
Quoting Kyle Banerjee <[log in to unmask]>:
>> 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
> 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
> 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.
[log in to unmask] http://kcoyle.net