Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 50 Current »

This page describes the Scanned Key Content workflow that originated from a Harvard Library Lab project in 2012. This method is still supported. 

As of 2024, you can alternatively use Alma-D to show images of non-digital content. See Custom thumbnails for any Alma bib, including print titles (using Alma-D thumbnail feature)

OVERVIEW

HOLLIS supports the display of thumbnail images for content designated as "key content" by staff. One designated thumbnail will display in the search results:


All thumbnails will display in the full record:

This feature can be used in a number of different ways. Some examples include: 

  • To display a scanned cover and index of a pamphlet that is not digitized in its entirety.
  • To highlight a specific plate or illustration in a book.
  • To give the researcher a better sense of what an object is:


BACKGROUND/HISTORY

The Scanned Key Content (SKC) workflows began as a Harvard Library Lab project to explore ways that images could be quickly captured at the point of accession or cataloging and displayed in the public catalog to support resource discovery and identification. In brief: Images are captured, deposited into the Digital Repository (DRS), and links to the images are added to holdings records. SKC is not intended to replace whole item digitization. For more information on the original Library Lab project including examples of images and catalog records see this presentation and poster.

LIST OF PERSONNEL / REPOSITORY PARTICIPANTS AND CONTACTS

  • Amy Benson, Librarian/Archivist for Digital Initiatives, Schlesinger Library
  • Nell Carlson, Curator of Historical Collections, Harvard Divinity School Library
  • Erin LaBove, Cataloger, Published Material, Schlesinger Library
  • Mingtao Zhao, Systems Analyst and Applications Developer, Harvard Library, Imaging Services

COSTS

  • Each repository is responsible for the costs associated with creating Key Content images.
  • Each repository is also responsible for the costs incurred by storage of their Key Content images in the DRS. DRS fees are assessed on a gigabyte-per-year basis.
    • The FY23 cost for still JPEG2000 images that are meant as both the preservation and deliverable copy is $0.90 per gigabyte per year.
    • LTS maintains a wiki page that lists DRS Storage Service Levels and Price Model.
      • As an example, fifty JP2images averaging 4MB each would cost approximately $0.18 per year at FY23 prices.
  • As of July 1, 2020, there is no fee for DRS deposit of SKC images or adding the image links to bibliographic records in Alma.

DRAFT Workflow Outline as of 10/11/2022.

BEFORE YOU BEGIN

  1. Before capturing SKC images, verify that the specific images of the item you want to add do not already exist. Multiple images from the same item are fine, but do not submit duplicate images for the same part/page of the same item.
  2. Unless there is a very good reason to do it, do not add SKC images for items that have already been digitized in their entirety.
    1. If an item meets eligibility requirements (copyright, physical stability, etc.) consider getting in touch with your repository’s local digitization coordinator to find out about available options for digitization of the entire item.

IMAGE CAPTURE

  • Repositories capture SKC images using available equipment such as scanners, cameras, cell phones, etc.
  • Repositories may save images as either TIFF (color, non-compressed, non-multi-page) or JPG file types, but not both. I.e., choose a single file type for SKC images per Repository.

FILE NAMING and ORDERING OF IMAGES

  • Repositories must name image files according to a specific file naming convention. The information contained in the file name supports later generation of the LTS batch linking spreadsheet.
    • As part of the file name, a number is added to indicate the sequence order of the 856 fields in the holding record and, in turn, the order the images will appear in HOLLIS. It is the first image in the Holding Record that will display in the search results in HOLLIS. All associated SKC images will display in the full bibliographic record.
    • Required for the file name are the Alma MMSID, the Alma Holding ID, a sequencing number, and text indicating part of item captured for the 856 $3.
    • File names cannot contain spaces. Each element of the file name must be separated by an underscore.
      • Example: 990027227450203941_221846479990003941_01_Cover.jpg
      • Example: 990027227450203941_221846479990003941_02_Table_of_contents.tif
    • Optionally, a Repository can include a copy number in the file name when it holds more than one copy.
      • Example:990027227450203941_221846479990003941_01_copy1_Cover.jpg
    • To reduce confusion when more than one Repository holds a resource, it is best practice to include the name of the holding Repository in the $3 of the 856 for the SKC images. Imaging Services staff has made it possible to automatically add the Repository name to the text of the $3 field as part of the DRS report conversion process, without a Library having to include it in the file name. Each Repository can specify the desired name/text to be added in this process. Contact Imaging Services to specify the naming convention for your Repository.
      • For example, all Schlesinger Library items will have "Schlesinger Library copy" as part of the $3 text.
  • Because the MMS and Holding IDs are long number strings that must be accurate, special care and/or software should be used when naming image files.
    • Harvard's DRS documentation offers recommendations for file naming software: DRS Quick Start Reference#BatchRenameUtilities
    • Care should be taken to ensure that image file names are correct before the images are submitted for deposit.
      • For example: please check to make sure that all MMSIDs begin with 99 and all Holding IDs begin with 22.

DEPOSIT

Imaging Services staff will deposit SKC images on behalf of a Repository. SKC images can be provided to Imaging Services via a shared SharePoint location, or by copying files to a Repository-specific SKC folder on the Imaging Services shared network drive. If you have questions about how to set up a SharePoint folder that will allow access to Imaging Services staff, contact your Repository's SharePoint administrator, or HUIT. If you want to use Imaging Services shared network drive for file sharing and your Repository does not currently have a Repository specific folder on the IS shared network drive, please get in touch with your Imaging Services staff contact to get one set up.

Instructions for Repositories that use the Imaging Services shared network drive:

  • In the Repository folder, there will be an SKC folder. Repositories will use this space to stage their scanned images for deposit. In this SKC folder, there will be a “special” subfolder with the name '_Ready_For_DRS_'. Save image files for deposit in that folder.
  • Repositories will create one or more subfolders in this _Ready_For_DRS_ folder, named with the correct DRS billing code. If a Repository has only one SKC billing code, it will have only one sub folder. Images ready for deposit to DRS will be copied/moved into these subfolders by Repository staff.
  • For example, Schlesinger Library will have the following folder structure:
    • Schlesinger

\_ SKC

 \_ _Ready_For_DRS_

 \_ RAD.SCHL.SKC_0001

 \_ Batch001

 \_ Batch002

 \_ ...

 \_ RAD.SCHL.SKC_0002

 \_ Batch003

Whether using SharePoint or Imaging Services shared network drive:

  • Repository staff will send an email to the Imaging Services (IS) contact to alert IS staff that a batch or batches of images are ready for deposit.
  • When convenient for them, Imaging Services staff will move and deposit all of a Repository's SKC image batches.
  • Post-deposit, IS staff will process the resulting SKC DRS deposit reports to convert them into a single linking spreadsheet matching the template supplied by LTS staff. 
  • Imaging Services will submit the spreadsheet to LTS for linking in Alma by submitting an LTS support ticket request. LTS staff will process the request on a quarterly schedule and/or as is convenient for them.
  • Each Repository DRS representative will receive a copy of the original DRS report via email.

LINKING

  • The Linking Spreadsheet will be sent to LTS Staff by Imaging Services staff, via a support ticket: http://nrs.harvard.edu/urn-3:hul.ois:almasupport
    • Please add "Attn: Corinna" in the Detail. Also name any Repository staff who should be notified when the work is complete.
  • LTS will run the batch process to add the SKC links to Alma.
  • Upon completion, LTS will reply via LibAnswers and close the ticket.

**REPORTING

  • Alma/COGNOS reporting for items in collection with SKC content
  • Use of 583 field (needs discussion)

EXAMPLES

Correctly formatted file names

  • 990027227450203941_221846479990003941_01_Schlesinger_Library_copy_Cover.jpg
  • 990027227450203941_221846479990003941_02_Schlesinger_Library_copy_Table_of_contents.tif

Completed SKC 856 Field:

Links to existing Records with SKC in HOLLIS:

=================================================

Additional details

Staff may add multiple holding 856 fields with $x keycontent. A thumbnail version of the image in the first 856 field in a record will be used for the search result page. Images in all 856 fields in a record will appear in the full record display. Do not add height or width parameters to the links in the 856 fields.

Additional examples 

Local information is particularly challenging to describe within the cataloging environment, and a picture can speak 1,000 words:

http://id.lib.harvard.edu/aleph/011494162/catalog 

The same goes for annotations. Are they in the hand the user wants to see, are they the type of annotations wanted:

http://id.lib.harvard.edu/aleph/014226784/catalog 

Is this the print the user wants? In this case, the print is HUGE, so entirely better for folks to check it out first without having to request it:

http://id.lib.harvard.edu/aleph/014289772/catalog 

Whose name is that? We can’t read the former owner’s signature, but a knowledgeable user may be able to read it. Additionally, including cast lists can be quite useful, as this information can sometimes be difficult to find:

http://id.lib.harvard.edu/aleph/014208635/catalog 

Contents notes are nice to include, particularly when they present information which is not transferrable to a catalog record, like musical incipits:

http://id.lib.harvard.edu/aleph/014156281/catalog 

Other local information includes ads like these, with photos which would be difficult to find elsewhere:

http://id.lib.harvard.edu/aleph/014149859/catalog 

Publishers’ catalogs are also highly useful; in the case of the many Johann Strauss issues collected by John Ward for instance, the catalogs help to identify the date of the issue, by examining the publications listed in the catalog:

http://id.lib.harvard.edu/aleph/012573648/catalog 

Our ongoing broadside cataloging project has been a perfect case for scanning key content, and luboks provide wonderful, unique images:

http://id.lib.harvard.edu/aleph/014240710/catalog 

The Santo Domingo project has been generating key content as well, including some unusual serial covers.

http://id.lib.harvard.edu/aleph/014121435/catalog


  • No labels