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
e...@hellman.net
http://go-to-hellman.blogspot.com/
Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA
e...@hellman.net
http://go-to-hellman.blogspot.com/
