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
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.
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
[log in to unmask]