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