In June, a new service that speeds access to life sciences literature reached a milestone. Called PubGet, it is a service that reduces the number of clicks to the full text of an article, and the milestone was activating the 50th institution using its service. Using its own proprietary “pathing engine”, it links directly to the full text on the publisher’s website. PubGet does this by understanding the link structure for each journal of each publisher and constructing the link to the full-text based on information from the citation. The PubGet service focuses on the life sciences journals indexed in PubMed — hence the play on names: PubMed to PubGet.

How It Works

Link Resolver screen for Christensen article

EBSCOhost screen for Christensen article

Typical View of a PubGet Article Display

The pathing engine is one of three components that make up the service. The other two are a search engine and a personalization feature. The search engine indexes the citation and abstract fields; it is not nearly as sophisticated as the thesauri-driven search engine native to PubMed, but it does the job for cases when you have a known citation. The personalization feature allows you to tie your account on PubGet to an institution, and with that knowledge the PubGet service can know exactly what digital rights your institution has for each journal and can create links to the full-text article that go through your institution’s proxy server. The account system also enables you to have new articles matching your search criteria sent to you and to mark articles in the search results for later bulk downloading (via a Firefox plugin).¹

Thinking About PubGet in a Wider Information Ecosystem

It would be nice if PubGet could be set up as an OpenURL target, and when it receives a request translates it to the direct link to the full-text using its pathing engine. That way I could set up PubGet as the OpenURL resolver in my PubMed account, and the article links in PubMed would automatically go to the full text. I don’t know how this would work as a business model for PubGet, though, because as an OpenURL resolver is this manner, it makes the PubGet website invisible — through a series of browser redirects I’d go from PubMed to PubGet to the publisher site. (If the point is to make money selling advertising for related industries, a configuration that completely by-passes any visible signs of PubGet would cut into that revenue source.)

As I was sharing background on PubGet with Thomas Dowling, a colleague at OhioLINK, he pointed out something I didn’t know about OpenURL: it is within the standard to specify a “service type” in the OpenURL Context Object. Section 5.1 of the NISO standard for OpenURL says a service type is “The resource that defines the type of service (pertaining to the Referent) that is requested.” And there are indeed service types registered as part of the SAP2 Community Profile: abstract, citation, fulltext, holdings, ill, and any. So the recipient of an OpenURL request, using the “fulltext” Service Type, should be able to replicate the proprietary PubGet pathing engine using a standard OpenURL structure. In a brief bit of experimentation, though, I was not able to find an OpenURL resolver that a) knew how to handle a Service Type parameter, and/or b) knew how to honor that parameter by getting directly to the full text. As OpenURL undergoes its 5-year review this year, it might be worthwhile to emphasize this part of the standard with examples and descriptions of best practices so it is more widely adopted.

Other Articles on PubGet

• Got PubMed? Pubget Searches and Delivers Scientific PDFs, Bio-IT World, June 10, 2009, By Kevin Davies
• Recommended Website of the month – Pubget, Information Service based at ScHARR at The University of Sheffield, June 9, 2009
• Pubget — useful, growing resource for anyone interested in research, ResearchBlogging.org news, June 10, 2009, By Dave Munger
• Pubget Speeds Up Science Journal Searches, Provides Marketing Tools, Xconomy, June 23, 2009, By Ryan McBride
• Get PDFs ASAP with Pubget, Bitesize Bio, June 25, 2009, By Carrie Iwema

Footnotes

1. Since the articles are not held within the PubGet service itself, the bulk article downloading function requires a Firefox plugin so that the article requests come from your browser to the publisher’s site.

The lead article in the September/October issue of D-Lib Magazine release yesterday is on djatoka, the open source JPEG2000 Image Server from Los Alamos National Laboratory. The authors, Ryan Chute and Herbert Van de Sompel describe their effort in the article abstract:

The ISO-standardized JPEG 2000 image format has started to attract significant attention. Support for the format is emerging in major consumer applications, and the cultural heritage community seriously considers it a viable format for digital preservation. So far, only commercial image servers with JPEG 2000 support have been available. They come with significant license fees and typically provide the customers with limited extensibility capabilities. Here, we introduce djatoka, an open source JPEG 2000 image server with an attractive basic feature set, and extensibility under control of the community of implementers. We describe djatoka, and point at demonstrations that feature digitized images of marvelous historical manuscripts from the collections of the British Library and the University of Ghent. We also call upon the community to engage in further development of djatoka.

The article is very easy to read and is a great overview of how they built the djatoka image server. LANL has a demonstration site with images of the Magna Carta from the British Library. The University of Ghent has also deployed a djatoka installation with some digitized pages of a Gregorian choir book. (The text of the site is in Dutch, I think, but you can click on the square boxes to the right of “Fol.” to bring up the images.) LANL has also put together a screencast demonstration of djatoka, included below.

djatoka is available under the GNU Lesser General Public License. The software has a site on SourceForge with forums for discussion. It runs as a Java servlet, so it is pretty much cross-platform. In the image server is the Kakadu JPEG2000 toolkit and the IIPImage JavaScript Viewer toolkit. One other key piece is a fascinating use of an OpenURL ContextObject to carry the service request information from the browser through the image server to the caching and rendering pieces.

Congratulations and kudos to Ryan, Herbert, and the team at LANL for putting together this great piece of software and releasing it as open source.Ryan Chute, Herbert Van de Sompel (2008). Introducing djatoka: A Reuse Friendly, Open Source JPEG 2000 Image Server D-Lib Magazine, 14 (9/10) DOI: 10.1045/september2008-chute

Earlier this week I received an e-mail from the director of the ISSN International Center announcing a session at the ALA Annual Conference in Anaheim to talk about the “linking ISSN”. Abbreviated ISSN-L, this is a new addition to the revised ISSN standard (ISO 3297, published last August) that allows for the collocation of separate ISSNs under a single ISSN-L. The ISSN standard now explicitly states that an ISSN is a unique identifier for a specific serial in a defined medium. In other words, separate ISSN should be assigned to each different medium version of a serial. The ISSN-L table brings these separate ISSNs together.

The FAQ I received that goes along with the e-mail announcement has several interesting statements. I’ve extracted the most interesting, at least from my perspective, here:

The purpose of the linking ISSN is to provide a tool for grouping, or collocating, the various medium versions of a resource, for instance, the print and online versions of a journal. … Those involved in the production, distribution, management of, and access to serial resources have expressed the strong desire that the ISSN system meet two different needs:

• The need for the ISSN to identify the various medium versions of a continuing resource, for product management purposes. To meet this need, separate ISSN are assigned to the various medium versions of a resource.
• The need for a collocating, or grouping mechanism that would bring together various medium versions, and thus facilitate content management. The linking ISSN (ISSN-L) has been defined to meet this currently unmet need.

The linking ISSN is a new function for the ISSN system — not a new identifier. … The first ISSN assigned in the ISSN Register to any medium version of a continuing resource is designated by default to function also as the linking ISSN and applies to all other medium versions of that resource identified in the ISSN Register. The linking ISSN is labelled (for eye-readable purposes) as “linking ISSN” or “ISSN-L”. A linking ISSN is designated for each continuing resource identified in the ISSN Register, even if the continuing resource is issued in only one medium. Only one linking ISSN is designated regardless of how many different medium versions of a continuing resource exist.

The ISSN-L should always be treated, for computer processing purposes, as a separate data element. For example, in MARC formats, which are used in the ISSN Register, ISSN-L is input in a separately tagged subfield in each of the ISSN Register metadata records to which it pertains. It is important to note that ISSN-L should be processed and used separately from medium-specific ISSN. In applications based on tables or indexes, ISSN-L should not be included in the same tables or indexes as medium-specific ISSN.

The designated ISSN-L is made available in several different ways:

• via a table which lists the ISSN-L and the corresponding ISSN linked to the ISSN-L. This table is available free of charge on the ISSN IC web site. [See note below.]
• via the ISSN Register: (each metadata record in the ISSN Register includes the medium-specific ISSN assigned to the resource described in the record, and the designated linking ISSN, as separate data elements);
• via the ISSN National Centres, which communicates to publishers the ISSN-L designated for newly-assigned ISSN,
• via the resources themselves, provided that publishers print or display this information according to the recommendations in the standard.

In order for the ISSN-L to work effectively, publishers will need to clearly indicate when they are using an ISSN-L as opposed to an ISSN. The ISO standard’s recommendations for printing and displaying ISSN-L are as follows: the linking ISSN shall be clearly distinguished as such by use of the label ISSN-L. In such cases, the label ISSN-L shall be written in uppercase and a space shall precede the 8 digits of the linking ISSN. Example: ‘ISSN-L 0251-1479′.

No programmatic method can be used to determine ISSN-L on the basis of one of the medium-specific ISSN, nor is there a programmatic way to determine the group of medium-specific ISSN associated with one ISSN-L. This is due to fundamental characteristics of the ISSN system: ISSN have no inherent meaning, and they are distributed sequentially. ISSN are assigned by national centres around the world, and a new medium version may appear at any time, perhaps published in a different country; this cannot be predicted and thus there is no programmatic way to associate an ISSN with its corresponding ISSN-L.

The assignment policy of the Standard now explicitly specifies that ISSN is a unique identifier for a specific serial in a defined medium. Therefore separate ISSN are assigned to each particular medium version of a serial. … If some publishers use the same ISSN for different medium versions of a serial, they deprive their users of the means to identify the medium- specific versions of that serial for ordering, claiming, etc. However, this should not interfere with the ISSN-L. The single ISSN will become the ISSN-L that can be used for collocating functions.

ISSN-L is a tool that aims at facilitating collocating functions. To perform these functions adequately, ISSN-L and the related ISSN have to be present in OpenURL knowledge bases. At this time, various scenarios can be envisaged. The desired end result is described as follows: The request must use the data available in the citation. It is the job of the resolver to match the identifier to the appropriate resource. It is the resolver that will make use of ISSN-L to relate the various medium of an ISSN to each other and find one to satisfy the request. One should be able to put in a request (for example an OpenURL) using any of the ISSN and separately and additionally request that the electronic copy is desired.

One note: I can’t find the ISSN-L table on the http://www.issn.org/ website. In a follow up discussion with Françoise Pellé (Director of the ISSN International Centre) I learned that it isn’t there yet, but they intend to put it there.

This is an interesting, well, kluge. It provides a neat amount of backwards compatibility — for publications that only have one medium, that publication’s ISSN automatically becomes its ISSN-L. The publishers (presumably) would need to take proactive action to tell the ISSN registrar that two ISSN are two mediums of the same publication; hopefully the word will get out and all affected publishers will do so.

It doesn’t effectively replace the xISSN service from OCLC because the ISSN-L table only gives current links. The description of xISSN says ISSNs are related in two different ways: different editions of same serial (such as print and online editions) and historical relationships (ISSN changes that result from title changes, mergers, splits, etc.). ISSN-L only handles the former (different editions) relationship type, not the latter (historical) relationship type. The ISSN-L table is (reportedly) free, however, and the xID service require an OCLC network membership. (While this posting was in draft form, Tim McCormick of OCLC announced that effective immediately, xID services from OCLC — that is, xISBN, and the forthcoming xISSN — will be included at no additional cost with all OCLC cataloguing subscriptions.

I hope to hear more after ALA Annual. Unfortunately, I think I have a conflict with the proposed meeting on Friday afternoon of ALA, so if anyone else hears anything please blog about it. (Trackbacks to here would be appreciated.)

Updates from Information at ALA

MARC codes were approved by MARBI a few months ago. Current ISSN-L identifiers will be put in MARC21 field 022 subfield ‘l’. Cancelled ISSN-L identifiers will be put in MARC21 field 022 subfield ‘m’. (Every record will have a subfield ‘l’ or a subfield ‘m’, even if it is in a single format.)

Retrospective designation uses lowest ISSN from the cluster linked via 776 field. As on-going ISSN assignments are made, the ISSN-L will be the first assigned out of any media. (May not always be the lowest in numerical order because of how ISSNs are allocated to ISSN centers.)

The crossreferencing linking table for ISSN-L has not yet been published. The international ISSN center is also considering a web service that would send back all of the associated ISSNs for an ISSN-L.

Launch is at IFLA in August 2008. Expected implementation before end of 2008. (There is of course some catch-up time as library automation vendors add this capability to individual systems.)

The text was modified to remove a link to http://ala.org/ala/lita/litamembership/litaigs/igstandards/standards.cfm on June 9th, 2011.

Extra! Extra! Read All About It! “Explore History as it Happened: Google News Now Has Archive Search” Extra! Extra!

In my imagination I can see and hear the herald of the newspaper carrier on the street corner barking out this call. Except, Kids These Days would probably decry the use of dead trees to carry stale news and already be reading it on their PDAs and text-messaging each other on their cell phones. As it is, I found out about it through a story on Search Engine Watch (also found in Wall Street Journal and the U.K. Guardian and the New York Times) which itself touted Google’s “200 Year News Archive Search.” It is a nice service; I look at it, though, and have to wonder about the changing — if not outright diminishing — role of libraries as couriers of information. After all, couldn’t links to resources from the user’s local library be included right there next to the commercial article suppliers? If they could, why aren’t they? And what does it mean that they are not?

How Libraries Could Be Included

(As an aside, wouldn’t the same thing be possible for the Google Books service as well? OpenURL can carry metadata about books as well as journals, so including a hyperlink to the library’s link resolver would seem to be a pretty easy thing to do.)

Why Libraries Aren’t Included: The Possible Reasons

1. In Progress (“We’re Working On It. What? ‘Internet Time’ Isn’t Fast Enough For You?”)

2. Benign Neglect (“Oh, You Mean Libraries Already Have Some of This Stuff?”)

A note from the News archive search team

Please let us know if you have suggestions, questions or comments about News archive search. Our goal with News archive search is to make it possible for users to read about historical events as they happened. History is often presented with a viewpoint of many years later and is frequently smoothed over in many ways and for many reasons. Enabling users to read about history as it unfolded allows them to explore and understand the past for themselves.

http://news.google.com/archivesearch/about.html

3. Clash of Business and Library Ethos (The “Follow the Money” Theory)

This is the prototypical clash between two very different value sets: that of a business seeking to maximize returns and profits, and that of a not-for-profit library seeking to economically acquire and present content to users at a cost — in aggregate — cheaper than the users could do for themselves.

I also can’t help but wonder about the ethos in play for some of the content suppliers that have partnered with Google to provide this service. From the Search Engine Watch article:

Google has partnered with news organizations including Time, The Wall Street Journal, The New York Times, the Guardian and the Washington Post, and aggregators including Factiva, LexisNexis, Thomson Gale and HighBeam Research, to index the full-text of content going back 200 years.

http://searchenginewatch.com/showPage.html?page=3623345

Whoa! Don’t many of us already do business with Factiva, LexisNexis, and Thomson Gale? (I don’t know about HighBeam Research — that name is new to me.) Wouldn’t they, too, have our IP address ranges and know about our patrons? In my limited amount of testing using an IP address associated with an institution that has access to products from these three vendors, I’m still asked to pay for article that my library has, in effect, already acquired.

And What Does It Mean That We Are Not?

[Updated 20060907T1038 to include links to mainstream media articles about the new service.]

Footnotes

1. Based on the date of adoption as listed in the ISSN entry on Wikipedia.

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?

The text was modified to remove a link to http://demo.exlibrisgroup.com:9003/demo/cgi/core/citation-linker.cgi on January 28th, 2011.