If you have a URL that can be used for a resource that you are  
describing in metadata, resolvers can do a better job providing  
services to users if it is put in the openurl. The only place to put  
it is rft_id. So let's not let one resolver's incapacity to prevent  
other resolvers from providing better services.

If you want to make an OpenURL for a web page, its url is in almost  
all cases the best unambiguous identifier you could possibly think of.

Putting dead http uri's in rft_id is not really a very useful thing to  
do.

On Sep 14, 2009, at 1:45 PM, Jonathan Rochkind wrote:

> Eric Hellman wrote:
>> http://catalog.library.jhu.edu/bib/NUM identifies a catalog record-  
>> I  mean what else would you use to id the catalog record. unless  
>> you've  implemented the http-range 303 redirect recommendation in  
>> your catalog  (http://www.w3.org/TR/cooluris/), it shouldn't be  
>> construed as  identifying the thing it describes, except as a  
>> private id, and you  should use another field for that.
>>
> Of course. But how is a link resolver supposed to know that, when  
> all it has is rft_id=http://catalog.library.jhu.edu/bib/NUM  ??
>
> I suggest that this is a kind of ambiguity in OpenURL, that many of  
> us are using rft_id to, in some contexts,  simply provide an  
> unambiguous identifier, and in other cases, provide an end-user  
> access URL  (which may not be a good unambiguous identifier at  
> all!).   With no way for the link resolver to tell which was intended.
>
> So I don't think it's a good idea to do this.  I think the community  
> should choose one, and based on the language of the OpenURL spec,  
> rft_id is meant to be an unambiguous identifier, not an end-user  
> access URL.
>
> So ideally another way would be provided to send something intended  
> as an end-user access URL in an OpenURL.
>
> But OpenURL is pretty much a dead spec that is never going to be  
> developed further in any practical way. So, really, I recommend  
> avoiding OpenURL for some non-library standard web standards  
> whenever you can. But sometimes you can't, and OpenURL really is the  
> best tool for the job. I use it all the time. And it constantly  
> frustrates me with it's lack of flexibility and clarity, leading to  
> people using it in ambiguous ways.
>
>
> Jonathan

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

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