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