 |
 |
As I'm sure you're aware, the OpenURL spec only talks about providing services, and resolving to full text is only one of many possible services. If *all* you know about a referent is the url, then redirecting the user to the url is going to be the best you can do in almost all cases. In particular, I don't think the dublin core profile, which is what Owen suggests to use, has much to say about resolving to full text. 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. IIRC Google, Worldcat, and Wikipedia used rft_id. I'm not in a position to answer any questions about specific link resolver software that I no longer am associated with, however good it is/was. Eric On Sep 14, 2009, at 12:57 PM, Jonathan Rochkind wrote: > Well, in the 'wild' I barely see any rft_id's at all, heh. Aside > from the obvious non-http URIs in rft_id, I'm not sure if I've seen > http URIs that don't resolve to full text. BUT -- you can do > anything with an http URI that you can do with an info uri. There is > no requirement or guarantee in any spec that an HTTP uri will > resolve at all, let alone resolve to full text for the document > cited in an OpenURL. > The OpenURL spec says that rft_id is "An Identifier Descriptor > unambiguously specifies the Entity by means of a Uniform Resource > Identifier (URI)." It doesn't say that it needs to resolve to full > text. > > In my own OpenURL link-generating software, I _frequently_ put > identifiers which are NOT open access URLs to full text in rft_id. > Because there's no other place to put them. And I frequently use > http URIs even for things that don't resolve to full text, because > the conventional wisdom is to always use http for URIs, whether or > not they resolve at all, and certainly no requirement that they > resolve to something in particular like full text. > > Examples that I use myself when generating OpenURL rft_ids, of http > URIs that do not resolve to full text include ones identifying bib > records in my own catalog: > http://catalog.library.jhu.edu/bib/NUM [ Will resolve to my > catalog record, but not to full text!] > > Or similarly, WorldCat http URIs. > > Or, an rft_id to unambigously identify something in terms of it's > Google Books record: http://books.google.com/books?id=tl8MAAAACAAJ > > Also, URIs to unambiguously specify a referent in terms of sudoc: http://purl.org/NET/sudoc/ > [sudoc] => will, as the purl is presently set up by rsinger, > resolve to a GPO catalog record, but there's no guarantee of online > public full text. > > I'm pretty sure what I'm doing is perfectly appropriate based on the > definition of rft_id, but it's definitely incompatible with a > receiving link resolver assuming that all rft_id http URIs will > resolve to full text for the rft cited. I don't think it's > appropriate to assume that just because a URI is http, that means it > will resolve to full text -- it's merely an identifier that > unambiguously specifies the referent, same as any other URI scheme. > Isn't that what the sem web folks are always insisting in the > arguments about how it's okay to use http URIs for any type of > identifier at all -- that http is just an identifier (at least in a > context where all that's called for is a URI to identify), you can't > assume that it resolves to anything in particular? (Although it's > nice when it resolves to RDF saying more about the thing identified, > it's certainly not expected that it will resolve to full text). > > Eric, out of curiosity, will your own link resolver software > automatically take rft_id's and display them to the user as links? > > Jonathan > > Eric Hellman wrote: >> Could you give us examples of http urls in rft_id that are like >> that? I've never seen such. >> >> On Sep 14, 2009, at 11:58 AM, Jonathan Rochkind wrote: >> >> >>> In general, identifiers in URI form are put in rft_id that are >>> NOT meant for providing to the user as a navigable URL. So the >>> receiving software can't assume that whatever url is in rft_is >>> represents an actual access point (available to the user) for the >>> document. >>> >>> >> >> Eric Hellman >> President, Gluejar, Inc. >> 41 Watchung Plaza, #132 >> Montclair, NJ 07042 >> USA >> >> [log in to unmask] >> http://go-to-hellman.blogspot.com/ >> >> Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA [log in to unmask] http://go-to-hellman.blogspot.com/