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
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
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/
> 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.
> 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
>> <[log in to unmask]>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
>>> (URI)." It doesn't say that it needs to resolve to full text.
>>> In my own OpenURL link-generating software, I _frequently_ put
>>> 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
>>> 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
>>> 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
>>> record, but not to full text!]
>>> Or similarly, WorldCat http URIs.
>>> Or, an rft_id to unambigously identify something in terms of it's
>>> 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
>>> 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
>>> to anything in particular? (Although it's nice when it resolves to
>>> 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
>>> 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
>>>> 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
>>>>> 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
>>>> [log in to unmask]
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
[log in to unmask]