OhioLINK uses III’s Millennium serials module and electronic packing slips to control the serials that we add to the Electronic Journal Center. The system provides record of:
We send three claims to the publisher for missing content before making the assumption that content is unavailable.
Connect to the Serials Catalog.
We implemented the serials checkin and claiming system to more efficiently control and claim the serials that we add to the Electronic Journal Center. Because the software we use to run the EJC has only rudimentary tools for claiming and notification of metadata problems, we are using III’s Millennium serials module and electronic packing slip products to provide some of the control we lacked in the past.
We check in all EJC serials issues that we receive except those from BioMedCentral and BePress. We send three claims to the publisher for missing content before making the assumption that content is unavailable. Thanks to the claiming system, we now have quantifiable information to use in working with publishers who have chronic problems delivering content. We have filled in thousands of missing back issues.
You can connect to the serials system in the following ways:
Use the system to see whether we have received an issue, what issues are unavailable, and when and how often we have claimed missing issues.
LIB HAS: Check the LIB HAS statement to see known gaps and when our run of a journal started. We also use this area to note title transfers and other anomalies.
Latest Received: Click Latest Received to see the checkin card and see what has been claimed and when issues have been received. Late and claim statuses:
|LATE||—||45 days after issue's expected date (10 days for weeklies, 21 days for semimonthlies)|
|CLAIMED1||—||first claim sent|
|LATE 1||—||45 days after first claim|
|CLAIMED2||—||second claim sent|
|LATE 2||—||45 days after second claim|
|CLAIMED3||—||third claim sent|
|LATE 3||—||45 days after third claim; presumably we are never going to get this issue|
We have normally claimed the issue at least three times and given up on its receipt. If we know the reason why the publisher did not supply the issue, and we can state that reason briefly, we add a note to the holdings statement. In other cases, we do not know the exact reason the publisher did not supply the issue.
If we have recorded a missing issue as a gap in the holdings statement and we have no checkin box for the issue, we are very unlikely to receive that issue.
The checkin system does not identify corrupted or missing PDF files, bad links to text on the publishers’ sites, or delivery of partial issues. The checkin process does bring to light many metadata problems, including ISSN errors and oddly formatted dates and numbering, but it takes a person, not a machine, to detangle and resolve these problems.
The checkin systems works on prediction dates and has no interaction with publishers’ web sites. So there is no automatic way of knowing if a publisher has loaded an issue on its own web site but failed to send an issue to us until the prediction date triggers a claim.
Because the checkin system works at the issue level, not the article level, we are not able to check in content from BePress or BioMedCentral. These publishers continuously supply articles, and the volume/issue designation is an artificial construct that does not really pertain to their journals’ delivery.
You may report problems or seek additional information about Electronic Journal Center titles in the following ways:
There is no way to report missing issues from within the checkin system. This system is simply the equivalent of the serials checkin and claiming module in your library’s Innopac.
Loading or creating bibliographic records : There must be a bibliographic record for every title we check in and claim. We receive a full MARC record from OCLC’s TECHPRO contract cataloging service several months after we load each new EJC title for the first time. We create a brief, temporary bibliographic record to use during the gap between the first EJC load and the time we receive a record from TECHPRO.
Creating the checkin record and checkin card : The basic checkin record includes information about the publisher, the number of copies (always 1 in our case), and some information that the system uses to allow electronic checkin. We create a checkin card for all active titles. Here we predict, as best we can, what issues we will receive in the future and at what intervals. We also make retrospective cards, if they will be needed to claim gaps in our backfile.
Creating the holdings statement : The holdings statement tells viewers whether a title is open or closed and the extent of the issues we hold. In many cases, this is straightforward, but it can be more challenging in situations where there are odd gaps. Is the lack of back issues due to an oversight on the publisher’s part or due to licensing restrictions? Although our title list information is much better than it has been in the past, there are still situations where making a decision on a backfile’s availability is more of an art than a science. We have also added notes, such as “No longer available to OhioLINK,” or “Continued by the Journal of Play-Dough.” These notes contain much more information than the limited notes that the EJC software permits.
Electronic checkin : In a separate process, OhioLINK staff have written scripts that convert parts of the EJC metadata we receive with each electronic journal issue to XML files that are compatible with III Millennium’s requirements for their electronic packing slip product. As we receive new EJC issues, we FTP metadata files to a local computer. Then, using III’s Vendor Checkin Server Interface, we move the files to the checkin machine. The system automatically checks in the issues as we move the XML files to the Millennium Server. A staff member must click on each file numerous times in order to complete the load. It is a time-consuming process because there is no batch load option.
The electronic packing slip product is very literal-minded, so there are often checkin failures. For example, checkin fails if the month in the XML data does not match the month of the issue on the checkin card or if there is a slight difference in syntax for the enumeration or chronology. We review issues that do not check in and check them in by hand if necessary.
Claiming and follow up : Running claims is not an automatic process. One must go through a list the system generates and queue up the claims. We are careful to verify that we truly have not received an issue before we send a claim. If a publisher does not respond to a claim, we send two more claims before deciding that an issue is unavailable. At that point, we make a note in the checkin system so that we can answer any later queries.
And on it goes. For issues with weekly or semimonthly frequencies, the grace interval is 10 or 21 days instead of 45.
updated July 2011