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