What the spec for z39.88 says is that rfr_id (and all the other _id's)
must be URIs.
the info:sid samespace was defined to allow minting of identifiers for
the specific purpose of identifying referrers. the info uri was
defined to allow non-resolving identifiers to have a place to live
within URI-land.
Documents written by standards committees are often not as clear as
they should be, but its hard to get consensus across an industy
without getting a committee together. Social process is so much harder
than technology.
On Sep 14, 2009, at 1:57 PM, Jonathan Rochkind wrote:
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/
Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA
e...@hellman.net
http://go-to-hellman.blogspot.com/