 |
 |
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/