 |
 |
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/