Re: [CODE4LIB] Implementing OpenURL for simple web resources

[Jonathan Rochkind]

Huh, I can't even FIND a section 9.1 in the z39.88 standard. Are we 
looking at the same z39.88 standard? Mine only goes up to chapter 4.  Oh 
wait, there it is in Chapter 3, section 9.1 okay.

While that example contains an http URI, I would say it's intended as an 
unambiguous identifier URI that happens to use an http schema, not an 
end-user access URL.  Although the weird thing is, in every other 
context the docs use an info:sid uri for rfr_id, to the extent that I 
thought you were REQUIRED to use an info:sid in rfr_id, I didn't even 
know you could use an HTTP uri as that example does, weird.  For 
instance, while chapter 3 Section 9.1 uses that example of 
rfr_id=http://www.sciencedirect.com, over on page 14 in Chapter 1, they 
use this example for the same entity:  rfr_id = 
info:sid/elsevier.com:ScienceDirect

It certainly doesn''t surprise anymore when the z3988 standard contains 
ambiguity or confusing/conflicting examples.

I wonder if there's more on this that is conflicting or confusing in the 
"scholarly format" application profiles, or in the "KEV implementation 
guidelines."  Probably. Yep, that's where I got the rfr_id=sid idea 
from!   The "KEV implementation guideilines" say: "Referrer Identifiers 
are defined in the source identifier Namespace `info:ofi/nam:info:sid:'. 
They are identified using the `info:sid/' scheme for the identification 
of collections."  It is unclear how the "KEV Implementation Guidelines" 
justify saying that a rfr_id is always info:sid, when the actual z39.88 
actually uses an http rfr_id example.  Who knows which one was the mistake.

Seriously, don't use OpenURL unless you really can't find anything else 
that will do, or you actually want your OpenURLs to be used by the 
existing 'in the wild' OpenURL resolvers. In the latter case, don't 
count on them doing anything in particular or consistent with 'novel' 
OpenURLs, like ones that put an end-user access URL in rft_id... don't 
expect actually existing in the wild OpenURLs to do anything in 
particular with that.

Jonathan

Rosalyn Metz wrote:
ok no one shoot me for doing this:

in section 9.1 Namespaces [Registry] of the OpenURL standard (z39.88) it
actually provides an example of using a URL in the rfr_id field, and i
wonder why you couldn't just do the same thing for the rft_id

also there is a field called rft_val which currently has no use.  this might
be a good one for it.

just my 2 cents.




On Mon, Sep 14, 2009 at 12:57 PM, Jonathan Rochkind <rochk...@jhu.edu>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] <http://purl.org/NET/sudoc/%5Bsudoc%5D>   => 
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/