 |
 |
That makes sense, thanks. I have certainly spent some time with that openurl reference document. It occurs to me that for external users, it would actually be _preferable_ for them to see both sets of links. Since this link is in fact attached in this case to some data generated _from_ my link resolver, even if you are external there is benefit in going to the link resolver to understand the source of the data you were looking at. But there may not be any good way of achieving that. Hmm. Jonathan Eric Hellman wrote: > If the COinS is wrapping the hard-coded OpenURL link, OpenURL > Referrer Firefox extension will replace the hard-coded link with a > soft-coded OpenURL link, and the result will be what both sets of > users expect. > > http://openly.oclc.org/openurlref/ > > >> I am developing a service to put our link resolver (SFX) information for >> a given title on the OPAC 'details' screen for that title. >> >> In addition to putting the information right on that screen, I'm putting >> an OpenURL link there to our link resolver. To begin with, this is not >> "COinS", because I need it to work for all my users using ordinary >> browsers, it's just a hyperlink hard coded to my link resolver. >> >> But then as I'm finishing this up I realize, hey, why not throw in a >> COinS object too. So I do that, now there's a COinS object sitting next >> to my hardcoded link. But now, if a user has the OpenURL Firefox >> extension installed, the user will end up seeing TWO link resolver >> links. My hardcoded one, and one converted from the COinS. If they are >> from another institution, my hardcoded one will be to MY local link >> resolver, and the COinS-converted one will be to THEIR link resolver of >> choice, which is probably just fine. >> >> But if they are from MY institution, and have chosen my link resolver in >> their firefox preferences, they wind up with two identical link resolver >> links right next to each other. This is kind of annoying, and sometimes >> appears to confuse people slightly. But mainly probably just looks >> sloppy. >> >> Have other people implemented similar things to this, and how have you >> dealt with it? Any suggestions? >> >> Jonathan > > > -- > > Eric Hellman, Director OCLC Openly > Informatics Division > [log in to unmask] 2 Broad St., Suite 208 > tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003 > http://openly.oclc.org/1cate/ 1 Click Access To Everything > -- Jonathan Rochkind Sr. Programmer/Analyst The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu