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
with.
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.)
kc
Quoting Kyle Banerjee <baner...@uoregon.edu>:
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
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
