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. 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  
(, 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  
> 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:
>   [ 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:
> Also, URIs to unambiguously specify a referent in terms of 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]

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042

[log in to unmask]