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?
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]