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  
>> <[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  
>>> 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
>>>>
>>>> [log in to unmask]
>>>> http://go-to-hellman.blogspot.com/
>>>>
>>>>
>>>>
>>>>
>>
>>

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

[log in to unmask]
http://go-to-hellman.blogspot.com/