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

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

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

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

[log in to unmask]
http://go-to-hellman.blogspot.com/