whoops....that should be rfr_id not rft_id.
> http://resolver.address/? > &url_ver=Z39.88-2004 > &url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx > &rfr_id=mylocalid > &rft_dat=<url>http://www.bbc.co.uk</url> On Mon, Sep 14, 2009 at 2:39 PM, Rosalyn Metz <[email protected]> wrote: > i'd like to point out that perhaps the reason that SFX (and other link > resolvers) don't use the rft_id in a particular way is because no one > has pushed it to. for example, it is possible for you to have the > word dinosaur link to an openurl and provide services for dinosaurs, > but the question is: > > 1) who would provide a link in their articles on webpages to an > openurl about dinosaurs. > > 2) do users really care. > > if i were in Owen's position i might create an openurl that looked like this: > > http://resolver.address/? > &url_ver=Z39.88-2004 > &url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx > &rft_id=mylocalid > &rft_dat=<url>http://www.bbc.co.uk</url> > > where mylocalid is an id i created to give these "special" openurls > and > where <url> is the tag that i made up to help my resolver identify the > data i'm sending privately. > > i could then write a program so my link resolver knows that the > information contained in the private data field (rft_dat) and is > identified by <url> should direct you to that url. you might also > need to make up some other tags (like <pdf> if all your pdfs are in > one spot). > > > > > > > > > > > > > > On Mon, Sep 14, 2009 at 2:23 PM, Jonathan Rochkind <[email protected]> wrote: >> >> I disagree. Putting URIs that unamiguously identify the referent, and in >> some cases provide additional 'hooks' by virtue of additional identifiers >> (local bibID, OCLCnum, LCCN, etc) is a VERY useful thing to do to me. >> Whether or not they resolve to an end-user appropriate web page or not. >> >> If you want to use rft_id to instead be an end-user appropriate access URL >> (which may or may not be a suitable unambiguous persistent identifier), I >> guess it depends on how many of the actually existing in-the-wild link >> resolvers will, in what contexts, treat an http URI as an end-user >> appropriate access URL. If a lot of the in-the-wild link resolvers will, >> that may be a practically useful thing to do. Thus me asking if the one you >> had knowledge of did or didn't. >> >> I'm 99% sure that SFX will not, in any context, treat an rft_id as an >> appropriate end-user access URL. >> >> Certainly providing an appropriate end-user access URL _is_ a useful thing >> to do. So is providing an unambiguous persistent identifier. Both are quite >> useful things to do, they're just different things, shame that OpenURL kinda >> implies that you can use the same data element for both. OpenURL's not >> alone there though, DC does the same thing. >> >> Jonathan >> >> Eric Hellman wrote: >>> >>> 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 >>> >>> [email protected] >>> http://go-to-hellman.blogspot.com/ >>> >>> >
