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/
>
>