This document provides an overview of Open Library Scan-On-Demand. It is a planning document at this stage, and needs more input from the community. The ultimate goal is to use it as a tool to encourage participation from more libraries as Open Library moves towards Digital ILL.
Data Import and UI Integration
User-Facing View
Administrator View
The IA Book Identifier
Existing Workflow Considerations
Next Steps
Data Import and UI Integration
When importing data from a library participating in Scan-On-Demand, the first step is to target the records to be used (e.g. pre-1923 research library works), and import all of the relevant MARC fields that support the library workflow and that of the participating scanning center. In the case of the Boston Public Library, the relevant MARC fields were as follows:- Field 001: Source Record ID
Locates the record in participating library database. - Field 090: Shelf Number
Locates the book on the physical shelf. - Field 852: Barcode
Unique identifier for each book.
The 001 (003) is best stored as a unique id (generally one appends the 003 to the beginning or end of the 001 in parens -- like OCLC numbers). This allows Open Library to link to the exact record in the participating library database. The call number is where it is on the physical shelf, however, the participating library can have more than one copy of the book and those copies may have different call numbers. With just the ID, Open Library could get copy information directly from a participating database (a common practice because copy information changes more frequently than other information). Open Library could even retrieve whether or not the item is on the shelf or checked out (most catalogs can serve up that data) but in any case, accurate copy/shelf information has to be up-to-date to be reliable. More in-depth information on establishing a connection to a contributing institution's Z39.50 catalog is available at the Internet Archive (password required).
Once the required fields have been identified and imported, additional munging may be required to reflect workflow realities. In the case of the Boston Public Library, all microtext records had to be deleted as there was no microfilm scanner on-site.
Once the data has been imported, the user interface can be customized to meet the participating libraries needs. The following list reflects the customizable components of the user interface:
*Core team members from the participating library and scanning center must be identified and added to the administrator group. Members of this group are added to the internal workflow mailing list and are permitted to work in the administrative interface.
User-Facing View
Once the user interface has been customized, the books available for scan-on-demand from a participating library can be made available to users. At present, the books can only be discovered through limited means. A user can discover a scannable book if it is listed in the "scannable" facet in the search results. Scannable books are also presented as a browsable list of scan records. These records are also further broken down by scan location. More sophisticated methods of resource discovery will be built into future generations of Scan-On-Demand.
Scannable records are distinguished by a button underneath the graphical representation of the cover. When a user clicks this button, they are required to log in and, after a few simple prompts, the selected book is entered into the Scan-On-Demand workflow.
One key prompt in this workflow notifies the user of the time it will take for a book be scanned. In the case of the Boston Public Library, three classes of books were identified: Rare Books, Fine Arts, and Book Delivery. A one-week window is the standard turnaround time for all three departments.
This email is generated by a user action, but only viewable by the administrative group.
Once the scan is initiated, an email is sent to a mailing list comprised of members of the participating library, the scanning center, and the Open Library team (defined as the administrator group in the Data Import and UI Integration step). The email contains important record information such as title, item, author, edition, publication date, call number, and bib number.
As a time-saving measure, the bar-code can be electronically generated and embedded in the email itself, so that the email can be printed and inserted into the physical book as a tracking method. This is a method currently in practice at the Internet Archive/LA scanning center to eliminate the reliance on pick lists which can impede workflow in an on-demand environment.
Administrator View
The Scan Queue is a web interface that organizes many of the functions of the Scan-On-Demand administrator view in a dashboard display. The queue is sortable by book state and provides easy access to many key functions, most notably the scan record.
The scan record provides the interface for most of the key functions in the Scan-On-Demand workflow. This is where the scanner operator changes the state of a book in the workflow. The record provides a simple history view, and the ability for scanner operators to provide comments on the status of a book.
The IA Book Identifier
The IA Book Identifier is the critical piece of information in this process. It is what links the Open Library record to the scanned manifestation of the physical book. This information is entered during the final stage of the workflow, when the scanner operator changes the status of a book to "SCAN_COMPLETE." Multiple identifiers can be entered when the scanner operator selects the check box for a multi-volume work. As of this writing, there is no support for incomplete multi-volume sets.
WISH-LIST FEATURE: The scanner operator will be prompted to select a suitable cover for the book from the first 10 pages of the scanned volume. This feature is currently in development, and works in tandem with the recently released Open Library Covers API.
Once the IA identifier has been successfully entered by the scanner operator, an email is sent to the original requester notifying them that the book they requested is available for digital download on Open Library.
This email is initiated by an administrative action, and is sent to the user (original requester)
and the administrative group to close the workflow cycle.
Existing Workflow Considerations
The current Scan-On-Demand system was based on the physical workflow at the Internet Archive/SF and modified to suit the workflow realities of the Boston Scanning Center and BPL. Initial on-site meetings were conducted in May 2008 with members of Open Library and the Internet Archive. The goal of the meeting was to potentially integrate the existing elements into one cohesive system, and it was noted from the outset that tracking the book through the system was essential to the success of the tool. This section also introduces some key terminology used by Internet Archive scanning operators, and identifies the software programs and technology currently used in the workflow.
The overall workflow can be distilled as follows, although the process can differ at individual scanning centers:
- Once a book is pulled, it arrives to the scanning center and is placed on a cart.
- The scanner operator places a color-coded tag (which simply identifies the books by which cart they came off of).
- The tag contains a GLADYS number if available and other information from the contributing library
- A book is pulled from the cart and "loaded" (given an IA identifier using the BibTool) - this is a manual process - duplicate entries are flagged and edited by operators.
- The book is then available for scanning on the Scribe2 system.
- Once scanned, it is sent to the petabox for processing (this is where the book is derived into its various formats: PDF, .txt, DjVu, FlipBook etc.).
- At this point, it appears in the MetaManager queue (once it passes QA and processing) with all of the other submissions from users of archive.org
It was noted during that meeting that it would be ideal if there was a system where people could sign off on:
- when a book is checked in
- flagged (this is the QA term for books that do not pass inspection)
- loaded (this currently entails creating an IA identifier with the BibTool [screenshot])
- which books are priority
- scan in progress (book on Scribe2)
- scan completed (URL sent to patron --> processed at petabox --> MetaManager queue [screenshot])
The final prototype created for use with the Boston Public Library simplified the steps outlined in this initial workflow, but it is interesting to note what could be considered in a more comprehensive quality assurance/workflow management system.
Next Steps
Digital ILL
The next steps for Scan-On-Demand will involve getting more catalogs from libraries interested in participating. At that time, we can move towards a Digital ILL environment. If a book cannot be found on the shelf of a participating library, a request for an in-depth search will be initiated and forwarded to other participating institutions. The original requester will be notified by email that the search is still in progress.
Stats
Support for statistics is a service that Open Library would like to offer with Scan-On-Demand. Providing this type of service would help libraries keep costs down since they would have to develop the same type of system in-house. Interesting stats include requests received versus actually filled. Repeat requests for an unavailable book would also help libraries update their catalogs by purging obsolete records. There is some interest in migrating towards a system similar to launchpad.net. This could be a viable option when more libraries begin participating and the workflow can potentially be distributed.
Outreach
Interesting ideas for outreach have been brainstormed during the planning of Scan-On-Demand. One scenario involves initiating the request at the front desk of a participating library when the physical book is checked out. The patron would receive a hard copy and then be asked if they would like a digital copy as well. The key will be getting the book in the requester's hands as soon as possible - so scanning would be done after a person uses the book. In essence, a user voted for the book just by the fact that they requested it.
History
- Created October 12, 2008
- 13 revisions
| August 9, 2023 | Edited by Drini | Convert type to page |
| May 6, 2009 | Edited by webchick | Edited without comment. |
| May 6, 2009 | Edited by webchick | tweak |
| May 6, 2009 | Edited by webchick | Edited without comment. |
| October 12, 2008 | Created by webchick | adding Scan-On-Demand Overview |