A Known Citation Discovery Tool in a Library2.0 World

 Posted on 
 ·  4 minutes reading time

When it comes to seeking a full-text copy of that known-item citation, are our users asking "what have you done for me lately?" OpenURL has taken us pretty far when one starts in an online environment -- a link that sends the citation elements to our favorite link resolver -- but it only works when the user starts online with an OpenURL-enabled database. (We also need to set aside for the moment the need for some sort of OpenURL base resolver URL discovery tool -- how does an arbitrary service know which OpenURL base resolver I want to use!) What if a user has a citation on a printed paper or from some other non-online form? Could we make their lives easier, too? Here is one way. (Thanks go out to Celeste Feather and Thomas Dowling for helping me think through the possibilities and issues.)

Some sites have addressed this issue with a static HTML form that prompts for the citation information (for example, this sample from Ex Libris' SFX demo server). That is so Web-1.0, though -- you have to fill out the entire form before you get any response back from the server on the availability (or non-availability) of the article you are trying to find. What if we could meet the user where they are with an interactive dialog that would quickly connect the user with the article?

One of the underlying assumptions is that users are still going to the OPAC to do a known-item search by journal title to see if the journal is held by the library in some form. The scheme that follows, though, would work just as well in A-Z journal lists and other places where the ISSN of the desired journal is known. The process starts when the user clicks on a link encoded with the ISSN from the bibliographic record pointing into our new OpenURL link resolver. The link resolver returns to the browser a page that lists articles from the given ISSN in reverse chronological order. (The theory here is, of course, to give the user some results, even though they are not likely what the user wants!)

The page also has an HTML form with fields for citation elements. As the user keys information into the form fields, AJAX calls update the results area of the web page with relevant hits. For instance, if a user types the first few letters of the author's last name, the results area of the web page shows articles by that author in the journal. (We could also help the user with form-field completion based on name authority records and other author tables so that even as the user types the first few letters of the last name he or she could then pick the full name out of a list.) With luck, the user might find the desired article without any additional data entry!

Another path into the citation results via the link resolver: if a user types the volume into the form field, the AJAX calls cause links to appear to issues of that volume in addition to updating the results to a reverse chronological listing of articles. If a user then types the issue into the HTML form field or clicks the issue link, the results area displays articles from that issue in page number order. Selecting the link of an article would show the list of sources where the article can be found (as our OpenURL resolvers do now), and off the user goes.

Ideally, all of the form elements would be AJAX'd, so if a user types an author's last name and a year, the appropriate citation(s) would show up. One might even be able to insert this activity in an IFRAME right on the bibliographic record display (if one have that much control over HTML layouts of various systems).

So what is to prevent us from reaching this citation discovery nirvana now? Well, a couple of things:

  1. Our link resolvers don't know anything about the actual citations of items in journals -- they just know how to take the citation elements and construct a URL that points into some other system. In order to make this work, our link resolver would need to be paired with a metasearch engine or a comprehensive index of article citations (or both).
  2. It would be helpful if there was an ISSN disambiguator to find alternate ISSNs (print vs. electronic, etc.) in order to cast a wide net for possible results. (In other words, a counterpart to OCLC's xISBN resolver service.)

Two pretty high hurdles. Still, it would be really useful if we could pull it off, wouldn't it?