The original question was whether it's a good idea to use OpenURL for
a URL persistence application.
Issues with using PURL are that
1. it only works with one website- PURL paths don't travel, though
there have been proposals to get around this.
2. There's not a really good way to package metadata with the PURL
If there was some standard other than OpenURL that would do the trick,
then we'd probably not be looking at OpenURL- there I agree with
You can't maintain a tr.im url or a bit.ly url, by the way. Those
services can't support post-creation modification of the target url,
because if they did, they'd get killed by spam.
On Sep 14, 2009, at 4:14 PM, Joe Hourcle wrote:
> My interpretation of the part of Jonathan's response that you quoted
> was basically, don't use OpenURL when you're just looking for
> persistant URLs.
> The whole point of OpenURL was that the local resolver could
> determine what the best way to get you the resource was (eg, digital
> library vs. ILL vs. giving you a specific room & shelf).
> If you're using OpenURLs for the reason of having it work with the
> established network of resolvers, don't get cute w/ encoding the
> information, as you can't rely on it to work.
> From what I've seen of the thread (and I admit, I didn't read every
> message), what's needed here is PURL, not OpenURL.
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
[log in to unmask]