Vendor Digitization

• 1: Scope of Services & General Practices for Vendor Digitization
• 2: Vendor Digitization Inventory Spreadsheet
• 3: JSON Sidecar Schema & Automated Validation
• 4: Digital Asset Specifications
• 5: Barcode Assignment and Application Recommendations

1 - Scope of Services & General Practices for Vendor Digitization

1. Overview and Operational Framework

This document establishes the standard operational framework for the digitization, metadata creation, text extraction, cataloging, quality control, and delivery of Library collection materials by external vendors. It covers a broad range of image-based formats and professional bibliographic services.

Services are authorized on a project-by-project basis through formal written scopes of work. This framework does not obligate the Library to authorize any specific project, service category, or volume of work. No project work shall begin until specific requirements, schedules, and quotes are approved in writing.

2. Authorized Material Categories

Vendors may be authorized to provide digitization and processing services for the following material categories:

• Microforms: 16mm and 35mm roll film, polyester and acetate film, microfiche, aperture cards, and related microform media.
• Bound Volumes: Books, rare books, periodicals, ledgers, scrapbooks, albums, and other bound or gathered formats.
• Flat Paper & Graphic Materials: Archival folders, loose correspondence, maps, posters, broadsides, oversized items, and related paper collections.
• Photographic Materials: Photographic prints, negatives, transparencies, slides, glass plate negatives, lantern slides, and related reflective or transmissive formats.
• Other Image-Based Materials: Additional specialized formats as defined in project-specific statements of work.

3. Project Workflow and Authorization

3.1 Quotes and Pricing

Before any project begins, the Vendor must provide a detailed written quote. Each quote must identify:

• Detailed project scope, material types, and estimated quantities
• Unit rates, estimated total cost, and not-to-exceed figures (where applicable)
• Required deliverables, project milestones, and estimated production schedule
• Metadata, cataloging, text extraction (OCR), and quality control requirements
• Shipping, handling, insurance, or specialized storage fees

3.2 Change Management

Any change in scope, quantity, technical specifications, handling requirements, cataloging rules, schedule, or cost requires written Library approval before the Vendor proceeds. The Vendor must immediately notify the Library of any discovered physical conditions, inventory discrepancies, or source material issues that impact project delivery.

3.3 Pilot and Test Batches

The Library may require the Vendor to complete a pilot or test batch prior to full production—especially for new material types, complex archival collections, fragile physical objects, or specialized OCR/cataloging workflows. Full production shall not proceed until the Library has reviewed and approved the pilot deliverables in writing.

4. Preservation Handling and Chain of Custody

4.1 Preservation Handling Protocols

Vendors must handle all cultural heritage materials according to institutional preservation standards and any project-specific instructions supplied by the Library.

• No destructive handling is permitted. Disbinding, cutting, trimming, flattening, cleaning, repair, rehousing, fastener removal, or removal from mounts/albums is strictly prohibited without explicit, prior written authorization from the Library.

4.2 Chain of Custody and Mandatory Reporting

The Vendor must maintain documented, end-to-end chain-of-custody tracking for all physical materials in its possession, recording receipt, storage location, production status, and return shipment.

Vendors must immediately halt work and report the following to the Library:

• Missing materials, barcode mismatches, or inventory discrepancies
• Damage discovered at intake or occurring during Vendor custody
• Active mold, pests, vinegar syndrome, or other hazardous/unstable conditions
• Brittle paper, broken glass plates, flaking emulsions, or severely damaged bindings
• Any material that cannot be digitized safely using standard equipment

5. Packaging, Transportation, and Logistics

When authorized by project scope, the Vendor must provide secure transport and on-site packing services that meet the following environmental and security thresholds:

5.1 Secure Transportation Requirements

• Climate & Environmental Control: Transit vehicles must feature functioning climate control systems to maintain stable temperatures (typically 60–70°F) and protect materials from extreme fluctuations. Cargo areas must be weather-tight and free of contaminants or pests.
• Shock & Vibration Mitigation: Vehicles must use air-ride suspension systems to minimize mechanical shock and vibration during transit.
• Security & Custody: Cargo areas must remain locked and alarmed at all times. Materials must never be left unattended in an insecure vehicle.
• Exclusive Use: Unless expressly authorized in writing, transit vehicles must be dedicated exclusively to Library materials; co-mingling collections with commercial freight or third-party cargo is strictly prohibited.

5.2 Handling and Packaging of Disbound Materials

If the Library grants explicit prior written approval to disbind a volume for capture, the Vendor must adhere to strict return packaging protocols:

1. Absolute Collation Retention: The exact original chronological and physical page order of the leaves must be maintained at all times. A final collation check is required prior to packing.
2. Preservation of Binding Elements: No part of the original object may be discarded. Original boards, spines, flyleaves, sewing threads, and fragments must be gathered in an archival envelope and housed directly alongside the text block.
3. Archival Enclosures: Disbound leaves must be placed into custom-fitted, acid-free, lignin-free four-flap enclosures (phase boxes) that pass the Photographic Activity Test (PAT). Leaves must fit snugly to prevent edge-crumpling.
4. Flat Packing: All enclosures containing disbound materials must be packed completely flat within transit cases. They must never be packed vertically (on edge), and heavy bound volumes must never be stacked on top of loose leaves.
5. Enclosure Labeling: Every enclosure must display the Library barcode, call number, bibliographic ID, and a prominent warning: DISBOUND FOR DIGITIZATION – LOOSE LEAVES.

6. Technical Specifications and Digital Organization

6.1 Technical Capture Standards

Digital files must be created in strict adherence to Library technical specifications, which define acceptable file formats, compression, optical resolution, bit depth, color space (ICC profiles), target usage, and quality thresholds (such as FADGI guidelines).

Vendors must maintain documented procedures for camera/scanner calibration, lighting uniformity, and color management. No substitution of file formats, compression settings, or image processing algorithms is permitted without written approval.

6.2 Text Extraction (OCR)

For text-based collections, project scopes may require optical character recognition (OCR) or structured text extraction. Depending on the project, deliverables may include:

• Searchable PDFs (must not be the sole OCR deliverable unless explicitly approved)
• Plain text (.txt) files
• Structured XML packages (ALTO XML, hOCR, or METS/ALTO)
• OCR confidence scoring and exception reporting for unreadable source text

6.3 Digital File Organization

Deliverables must strictly follow the file naming, zero-padding, and directory structures established by the Library. Vendors must maintain clear separation between preservation masters, production/service copies, access derivatives, OCR files, technical targets, and metadata manifests.

7. Metadata and Cataloging Services

7.1 Metadata Requirements

Vendors are required to generate and deliver structured metadata sufficient to support file validation, ingest, and discovery workflows. Required metadata typically includes:

• Identifiers: Barcodes, call numbers, bibliographic IDs, reel numbers, and frame numbers.
• Descriptive Metadata: Item titles, date ranges, chronology, enumeration, and language.
• Technical Metadata: Filenames, directory paths, file formats, pixel dimensions, bit depth, color space, and cryptographic checksums (MD5 algorithm preferred).
• Process Metadata: Capture dates, hardware/software specifications, operator IDs, and QC status.

7.2 Cataloging Standards

When providing bibliographic services, cataloging work must conform to institutional standards and project-specific cataloging rules (e.g., RDA, MARC21, LCSH, LCNAF, and local Library cataloging guidelines). Vendors must document all cataloging uncertainties, authority conflicts, and local exceptions for Library review.

8. Quality Control, Acceptance, and Rework

8.1 Vendor Quality Control (QC)

Vendors must perform 100% technical automated validation prior to delivery, verifying file presence, naming syntax, directory structure, sequence integrity, format specifications, and checksum completeness.

Vendors must also perform visual quality control (100% or statistical sampling as defined by project scope) to check for:

• Correct focus, exposure, and color/tone balance
• Proper cropping, skew correction, and orientation
• Absence of dust, Newton’s rings, glare, or physical obstructions
• Completeness of capture (no missing pages, clipped margins, or skipped frames)
• Correct polarity/inversion for transmissive negatives

8.2 Library Acceptance Review

Deliverables are not considered accepted until Library staff complete structural, technical, and visual reviews confirming that all digital files, metadata manifests, and returned physical materials conform to agreed specifications.

8.3 Error Correction and Rework

The Vendor must correct all vendor-responsible errors at no additional cost to the Library. Rework may require physical re-digitization, file replacement, metadata remediation, or manifest correction.

Common vendor-responsible errors include missing files, sequence gaps, corrupt data, incorrect file formatting, poor optical focus, cropped content, unauthorized post-processing, and checksum mismatches.

9. Deliverables and Order of Precedence

9.1 Standard Project Deliverables

Depending on the project scope, required deliverables typically include:

9.2 Order of Precedence

In the event of a conflict among project documentation, the following hierarchy applies unless explicitly waived in writing:

1. Approved project-specific Statement of Work, quote, or purchase order
2. This Scope of Services & Practices document
3. Library Digital Asset Specifications & Technical Appendices
4. Library-supplied metadata, cataloging, or handling instructions
5. Vendor-provided documentation or general service descriptions

2 - Vendor Digitization Inventory Spreadsheet

1. Overview and Workflow

When initiating an external digitization project, the Library provides vendors with a standardized metadata inventory spreadsheet. This document serves as the foundational tracking manifest for physical materials selected for digitization, establishes the baseline data required for item identification, and directly informs vendor scoping, equipment preparation, and cost estimates.

1.1 Downloads & Sample Files

• Inventory Spreadsheet Template: NYPL_Vendor_Digital_Imaging_Inventory_Template.xlsx
• Sample Photograph Sidecar (Single-Unit): sample_photograph_sidecar.json
• Sample Split Microfilm Sidecar (Multi-Unit): sample_split_microfilm_sidecar.json

1.2 Completeness & Internal Tracking Fields

This spreadsheet is a shared tool between curatorial staff, the Vendor Digitization Services team, and external vendors. When filling out this sheet, staff must adhere to the following division of responsibilities:

• Fill Out to the Best of Your Ability: Not every field in the spreadsheet is mandatory. Some archival inventory items may not be fully cataloged, described in a finding aid, or possess formalized collection IDs. However, because this inventory is used to calculate vendor estimates and resource allocation, it is vital that it be filled out as completely and accurately as possible. If descriptive metadata exists, include it.
• Internal Tracking Fields: Users preparing inventories do not need to fill out project_code (Column C) or funding_source (Column D) if they are unassigned. The Vendor Digitization Services team will complete and verify administrative tracking codes before submitting the final sheet to a vendor.

1.3 How Vendors Must Use This Data

This spreadsheet represents the initial selection and inventory stage of the digitization workflow. The data provided here must be ingested by the vendor and used as the root source for generating item-level metadata during capture.

When delivering digitized assets back to the Library, the vendor is responsible for generating individual JSON sidecar files for each asset. To build valid sidecars, the vendor must:

1. Map Library Metadata: Parse the item-level fields from this spreadsheet (such as barcode, division_code, object_type, and object_format) directly into their corresponding schema paths in the final JSON sidecar.
2. Append Capture Metadata: Generate and populate all capture-specific technical and administrative fields that occur during digitization (e.g., digitizationDate, capture device specifications, capture software, and operator details).
3. Append Asset-Level Metadata: Generate individual file-level tracking data for every image captured (e.g., fileRole, referenceFilename, frameNumber, sequenceNumber, side, and sequenceLabel).

Scope Limitation: Because technical capture fields, schemaVersion, and asset-level file specifications are generated dynamically during the digitization process, they are strictly excluded from this initial inventory spreadsheet.

2. Row Granularity: Physical vs. Intellectual Content

The spreadsheet must be populated according to the physical and intellectual structure of the materials being shipped. Every item scheduled for digitization requires a valid barcode (barcode), or the project cannot be initiated.

2.1 Standard Physical Granularity (One Row per Item)

As a baseline rule, each physical item being digitized (e.g., each bound volume, box, folder, reel, or photograph) must get its own dedicated row. If multiple physical items belong to a single catalog record (bnumber) or finding aid component, create a separate row for each physical carrier and reuse/repeat that bnumber or shelf_locator across those rows.

2.2 Intellectual Splitting on a Single Physical Item (Multi-Unit Objects)

Frequently, a single physical carrier (such as a volume of bound pamphlets or a microfilm reel) contains multiple distinct intellectual works that require the vendor to build separate digital packages/sidecars. Because splitting intellectual units impacts vendor pricing and capture workflows, staff must capture known complexities upfront:

• Known Intellectual Units: If staff know at the inventory stage that a single physical item must be split into multiple digital packages, create one row per intellectual unit. Repeat the physical barcode across every row associated with the item, increment the unit_index field sequentially (1, 2, 3, etc.), and provide descriptive titles in unit_title.
• Unknown/Unscoped Splits: If staff know a physical carrier contains multiple works but do not yet know the specific unit boundaries or titles, log one row for the physical item, leave unit_index and unit_title blank, and explicitly note the complexity in physical_condition_notes (e.g., “Contains multiple titles; vendor scoping required to determine digital package splits”).

3. Column Specification (A–Q)

The spreadsheet follows an ordered curatorial citation structure, grouping division_code, shelf_locator, and bnumber together.

3.1 Non-Schema Tracking Columns ([INFO])

Columns O, P, and Q ([INFO] estimated_page_count, [INFO] is_oversized, and [INFO] needs_cataloging) are explicitly differentiated in the template with a yellow header background. They are color-coded differently because this data will not be retained in final digital archival packages or sidecars.

However, these fields are critical for calculating vendor cost estimates, timeline sizing, capture equipment allocation, and curatorial remediation. Staff should make every effort to fill out these yellow columns whenever possible.

Vendors must ignore and strip all [INFO] columns when parsing the spreadsheet into automated production pipelines. These columns do not map to the metadata schema and must never appear in generated JSON sidecar files.

4. Controlled Vocabulary

4.1 Material Types (object_type & object_format)

To ensure data consistency and schema compliance across all projects, users must use the built-in drop-down menus in the Excel template for object_type (Col I) and object_format (Col J) rather than typing manual entries.

The template features dependent data validation: selecting an object_type in Column I will automatically filter the allowed values in Column J (object_format) to only show legal pairings. Any unrecognized string or mismatched pair will fail schema validation.

4.2 Curatorial Division Codes (division_code)

Column F (division_code) requires a standardized administrative code selected from the built-in dropdown menu. Do not enter full division names.

5. Worked Examples

5.1 Standard Single-Unit Item (Photographic Print)

For standard materials containing a single intellectual work on a single physical carrier, leave the unit index and unit title fields blank.

• View Output Sample: sample_photograph_sidecar.json

5.2 Single Physical Item Containing Multiple Intellectual Works (Bound Pamphlets)

When staff know upfront that a single physical volume contains multiple distinct works that must be delivered as separate digital packages, repeat the physical barcode across rows while assigning sequential unit indexes and titles to estimate the scope of each digital package.

• View Output Sample: sample_split_microfilm_sidecar.json (Illustrates multi-unit sidecar packaging syntax)

6. Implementation & Validation Rules

• Root Filename Generation: The barcode value (Column A) serves as the primary identifier for the physical asset and must form the root prefix for all generated digital files. In the JSON sidecar, the referenceFilename attribute must always begin with this string.
• Multi-Unit Naming Syntax: For multi-unit items, the integer in unit_index (Column L) dictates the unit segment of the final filename. Vendors must zero-pad this integer to three digits using the u00N naming convention (e.g., unit_index: 2 maps to filename segment u002).
• Scoping Multi-Unit Packages: When vendors ingest inventory rows where identical barcodes share multiple sequential unit_index numbers, they must configure their capture pipelines to generate distinct structural digital packages and sidecars for each unit segment, rather than combining them into a single asset package.
• Internal Field Verification: Prior to vendor distribution, the Vendor Digitization Services team is responsible for verifying and locking the project_code (Column C) and funding_source (Column D) fields for the entire batch.
• Template Dropdown Enforcement: The Excel template provided by the Library contains pre-configured data validation rules for columns F (division_code), I (object_type), J (object_format), P (is_oversized), and Q (needs_cataloging). Staff must not overwrite or paste plain text over these cells to prevent validation failures during ingestion.

3 - JSON Sidecar Schema & Automated Validation

1. Purpose and Workflow Integration

When delivering digitized assets to the Library, external vendors must supply a structured JSON sidecar file alongside every individual digital asset, including preservation masters, production/service files, access derivatives, and OCR text files.

While the Inventory Spreadsheet establishes the initial item-level metadata provided by the Library at intake, the JSON sidecar schema governs the asset-level, technical, and operational metadata generated by the vendor during digitization.

The authoritative JSON Schema is maintained as a separate, publicly accessible file. Vendors must integrate this schema into their automated quality-control pipelines before delivery.

• Public schema: digitized_image_schema.json
• Sample Photograph Sidecar (Single-Unit): sample_photograph_sidecar.json
• Sample Split Microfilm Sidecar (Multi-Unit): sample_split_microfilm_sidecar.json

The public URL must return the raw JSON Schema document rather than an HTML page, redirect, or error response.

2. Core Schema Requirements

Every delivered JSON sidecar must contain a valid JSON object that conforms to JSON Schema Draft 7.

The schema uses additionalProperties: false where applicable. Undocumented properties added by vendor software will therefore cause validation to fail.

Property names and controlled-vocabulary values are case-sensitive.

2.1 Required Root Objects

Every sidecar must contain the following six top-level objects:

1. administrative
   Grant, contract, or project-level administrative data, such as projectCode, fundingSource, and schemaVersion.

2. asset
   File-level tracking data, including the file role (pres, serv, access, or ocr) and exact referenceFilename.

3. identifiers
   Bibliographic and archival identifiers mapped from the Library-supplied inventory spreadsheet, such as barcode, divisionCode, bnumber, and shelf_locator (or classmark).

4. source
   Physical-source characteristics observed at capture, including the controlled object type and format pairing and sequential capture data such as sequenceNumber, unitIndex, unitTitle, side, and sequenceLabel.

5. digitizationProcess
   Technical metadata describing the capture device, lens, capture software, equipment identifiers, and calibration targets.

6. digitizer
   Administrative information identifying the operator and vendor organization responsible for capture.

3. Strict Naming and Controlled Vocabularies

3.1 Filename Pattern

To support reliable automated ingest and validation, the referenceFilename property in the asset object must follow one of the Library’s approved naming structures.

The base filename pattern is:

^33433\d{9}_(?:(?:negative|positive)_)?(?:[rv]|\d{5})_(?:pres|serv|access|ocr)\.[a-z0-9]+$

The pattern supports the following two filename structures:

[barcode]_[side-or-sequence]_[role].[extension]

[barcode]_[negative-or-positive]_[side-or-sequence]_[role].[extension]

Multi-unit identifiers such as u001 and u002 are not included in filenames. Multi-unit membership is represented by the asset’s enclosing directory and by the source.sequence.unitIndex property in its JSON sidecar.

Pattern components

• Barcode — 33433\d{9}
  A 14-digit NYPL barcode beginning with 33433.

• Negative-source component — negative|positive
  Used only for parallel files derived from a physical film or glass negative:

  • negative identifies the faithful, non-inverted representation of the source negative;
  • positive identifies the digitally inverted positive representation derived from that negative.

  These components do not describe all materials that happen to display as positive images. They must not be used for photographic prints, slides, transparencies, reflective materials, or other natively positive source objects.

• Side or sequence — [rv]|\d{5}
  Either:

  • r for recto;
  • v for verso; or
  • a five-digit, zero-padded sequence number such as 00001 or 00981.

• File role — pres|serv|access|ocr
  One of the four approved delivery roles:

  • pres;
  • serv;
  • access;
  • ocr.

• Extension — [a-z0-9]+
  A lowercase file extension such as .tif, .jp2, .jpg, .pdf, .xml, or .txt.

Valid examples

33433123456789_r_pres.tif
33433123456789_v_access.jpg
33433123456789_00001_serv.tif
33433987654321_negative_00001_pres.tif
33433987654321_positive_00001_access.jpg
33433555554444_00981_ocr.xml

Invalid examples

33433123456789_positive_r_pres.tif
33433123456789_R_pres.tif
33433123456789_1_pres.tif
33433555554444_u001_00001_ocr.xml
33433987654321_negative_u001_00001_pres.tif
nypl_33433123456789_00001_pres.tif
33433123456789_00001_master.tif
33433123456789_00001_pres.TIF

The filename pattern must be encoded with doubled backslashes when stored as a JSON string inside the schema:

{
  "pattern": "^33433\\d{9}_(?:(?:negative|positive)_)?(?:[rv]|\\d{5})_(?:pres|serv|access|ocr)\\.[a-z0-9]+$"
}

The schema applies additional conditional validation based on source.object.format:

• When the physical source is a black-and-white negative, color negative, or glass plate negative, referenceFilename must include either negative or positive.
• For all other source formats, referenceFilename must not include either component.
• The suffix in referenceFilename must agree with asset.fileRole. For example, an asset with "fileRole": "pres" must have a filename ending in _pres followed by its extension.

3.2 Multi-Unit Directory and Sequence Rules

When one physical item contains multiple distinct intellectual units, the Library still requires one BagIt bag for the complete physical object. The bag root is named with the physical item’s barcode.

Each intellectual unit is represented by a zero-padded unit subdirectory inside the bag’s data/ directory:

33433555554444/
└── data/
    ├── u001/
    └── u002/

The unit identifier is recorded in two places:

1. the enclosing directory, such as data/u002/; and
2. the JSON sidecar property source.sequence.unitIndex, where the integer 2 corresponds to u002.

A human-readable intellectual-unit title is recorded in source.sequence.unitTitle.

The unit identifier must not appear in referenceFilename.

Sequence numbering must remain absolute and uninterrupted across the entire physical object. It must not restart when a new intellectual unit begins.

For example, when unit 1 contains frames 1 through 980 and unit 2 begins at frame 981, the files are structured as follows:

33433555554444/
└── data/
    ├── u001/
    │   ├── 33433555554444_00001_pres.tif
    │   └── 33433555554444_00980_pres.tif
    └── u002/
        ├── 33433555554444_00981_pres.tif
        └── 33433555554444_01650_pres.tif

The JSON sidecar for the first frame in u002 would therefore include:

{
  "administrative": {
    "schemaVersion": "1.0",
    "projectCode": "NEH-2024-001",
    "fundingSource": "NEH_GRANT_1"
  },
  "asset": {
    "fileRole": "pres",
    "referenceFilename": "33433555554444_00981_pres.tif"
  },
  "source": {
    "object": {
      "type": "microform",
      "format": "35mm roll microfilm"
    },
    "sequence": {
      "unitIndex": 2,
      "unitTitle": "Pamphlet 2",
      "sequenceNumber": 981,
      "sequenceLabel": "Frame 981"
    }
  }
}

The integer sequenceNumber is stored as 981 in JSON. Its filename representation is zero-padded to five digits as 00981.

3.3 Controlled-Vocabulary Validation

The schema uses conditional JSON Schema logic, including oneOf, to enforce approved pairings between source.object.type and source.object.format.

For example, when a sidecar declares:

{
  "type": "reflective photographic"
}

the corresponding format value must be one of the formats explicitly permitted for that object type. An unsupported value will cause schema validation to fail.

Vendors must use the exact spelling, capitalization, and punctuation defined by the schema. Local synonyms, abbreviations, or alternate labels are not permitted unless the Library approves a schema revision.

4. Automated Validation Workflows

Vendors must perform automated schema validation on 100% of generated JSON sidecars before packaging and delivering files to the Library.

Validation must occur against a controlled local copy of the authoritative schema. The schema copy should be downloaded at the beginning of the project or build process rather than fetched separately for every sidecar.

4.1 Node.js Command-Line Validation with AJV

AJV provides command-line JSON Schema validation through the ajv-cli package.

1. Install AJV CLI

npm install --global ajv-cli

2. Download the authoritative schema

curl --fail --location \
  --output digitized_image_schema.json \
  https://nypl-research.github.io/digital-imaging-resources/schemas/digitized_image_schema.json

The --fail option causes the command to return an error for an unsuccessful HTTP response instead of saving an error page as though it were a schema.

3. Validate one sidecar

ajv validate \
  --spec=draft7 \
  --all-errors \
  -s ./digitized_image_schema.json \
  -d /path/to/delivery/33433123456789_r_pres.json

4. Validate an entire directory

ajv validate \
  --spec=draft7 \
  --all-errors \
  -s ./digitized_image_schema.json \
  -d "/path/to/delivery/**/*.json"

AJV returns an exit status of 0 when all supplied files are valid and an exit status of 1 when one or more files fail validation.

Validation errors identify the affected instance path, schema path, failed keyword, and associated error message. For example, an error may identify:

• a missing required property;
• an unapproved additional property;
• a controlled-vocabulary mismatch;
• an incorrect data type;
• a malformed filename;
• a filename that does not match referenceFilename;
• a mismatch between asset.fileRole and the filename suffix;
• an invalid use or omission of the negative or positive filename component.

For more readable output, add:

--errors=text

Example:

ajv validate \
  --spec=draft7 \
  --all-errors \
  --errors=text \
  -s ./digitized_image_schema.json \
  -d "/path/to/delivery/**/*.json"

4.2 Python Validation with jsonschema

Vendors integrating validation into Python processing pipelines may use the jsonschema package.

1. Install the package

python -m pip install jsonschema

2. Validate a sidecar

#!/usr/bin/env python3

import json
import sys
import urllib.error
import urllib.request
from json import JSONDecodeError
from pathlib import Path
from typing import Any, Iterable

from jsonschema import Draft7Validator
from jsonschema.exceptions import SchemaError, ValidationError


SCHEMA_URL = (
    "https://nypl-research.github.io/digital-imaging-resources/"
    "schemas/digitized_image_schema.json"
)

SIDECAR_PATH = Path("33433123456789_r_pres.json")


def load_remote_json(url: str) -> Any:
    """Download and parse a JSON document."""

    request = urllib.request.Request(
        url,
        headers={"User-Agent": "NYPL-sidecar-validator/1.0"},
    )

    with urllib.request.urlopen(request, timeout=30) as response:
        return json.loads(response.read().decode("utf-8"))


def load_local_json(path: Path) -> Any:
    """Read and parse a local UTF-8 JSON file."""

    with path.open("r", encoding="utf-8") as file_handle:
        return json.load(file_handle)


def format_instance_path(path: Iterable[Any]) -> str:
    """Convert a jsonschema error path into a readable JSON path."""

    formatted = "$"

    for component in path:
        if isinstance(component, int):
            formatted += f"[{component}]"
        else:
            formatted += f".{component}"

    return formatted


def main() -> int:
    try:
        schema = load_remote_json(SCHEMA_URL)
        Draft7Validator.check_schema(schema)

        sidecar_data = load_local_json(SIDECAR_PATH)

    except urllib.error.URLError as error:
        print(
            f"SCHEMA DOWNLOAD ERROR: {error}",
            file=sys.stderr,
        )
        return 2

    except FileNotFoundError:
        print(
            f"FILE ERROR: Sidecar not found: {SIDECAR_PATH}",
            file=sys.stderr,
        )
        return 2

    except JSONDecodeError as error:
        print(
            f"JSON SYNTAX ERROR: {error}",
            file=sys.stderr,
        )
        return 2

    except SchemaError as error:
        print(
            f"SCHEMA ERROR: {error.message}",
            file=sys.stderr,
        )
        return 2

    validator = Draft7Validator(schema)

    errors: list[ValidationError] = sorted(
        validator.iter_errors(sidecar_data),
        key=lambda error: list(error.absolute_path),
    )

    if not errors:
        print(
            f"VALID: {SIDECAR_PATH} is ready for delivery."
        )
        return 0

    print(
        f"INVALID: {SIDECAR_PATH} contains "
        f"{len(errors)} schema validation error(s).",
        file=sys.stderr,
    )

    for number, error in enumerate(errors, start=1):
        instance_path = format_instance_path(error.absolute_path)
        schema_path = "/".join(str(part) for part in error.absolute_schema_path)

        print(
            f"\nError {number}:",
            file=sys.stderr,
        )
        print(
            f"  Instance path: {instance_path}",
            file=sys.stderr,
        )
        print(
            f"  Schema path:   {schema_path}",
            file=sys.stderr,
        )
        print(
            f"  Message:       {error.message}",
            file=sys.stderr,
        )

    return 1


if __name__ == "__main__":
    raise SystemExit(main())

This example uses three exit statuses:

• 0: the sidecar is valid;
• 1: the sidecar is valid JSON but fails schema validation;
• 2: the schema or sidecar could not be loaded or parsed.

For high-volume validation, vendors should download the schema once, instantiate one Draft7Validator, and reuse that validator for every sidecar in the batch.

4.3 Validation Beyond JSON Schema

JSON Schema validation confirms that an individual sidecar follows the required structure and controlled rules. It does not inspect the filesystem or compare values across multiple files.

The vendor’s delivery-validation workflow must therefore perform additional checks that cannot be enforced by the Draft 7 schema alone, including:

• confirming that the barcode at the beginning of asset.referenceFilename matches identifiers.barcode;
• confirming that the asset file and its JSON sidecar have matching basenames;
• confirming that a sidecar with unitIndex: 2 resides in data/u002/;
• confirming that sequence numbers remain continuous across unit-directory boundaries;
• confirming that sequence numbering does not restart within each unit;
• confirming that every file listed in the BagIt payload is included in the applicable checksum manifest;
• confirming that no asset is duplicated or omitted when files are grouped into unit directories.

5. Schema Access and Download

The authoritative schema is maintained as an independent JSON artifact rather than duplicated within this documentation.

5.1 Browser Access

Open the following resource to view or save the schema:

• digitized_image_schema.json

5.2 Download with cURL

curl --fail --location \
  --output digitized_image_schema.json \
  https://nypl-research.github.io/digital-imaging-resources/schemas/digitized_image_schema.json

5.3 Download with Wget

wget \
  --output-document=digitized_image_schema.json \
  https://nypl-research.github.io/digital-imaging-resources/schemas/digitized_image_schema.json

5.4 Confirm That the Downloaded File Is JSON

A successful HTTP download does not by itself prove that the downloaded document contains valid JSON. Vendors should parse or validate the schema before using it.

Using Python:

python -m json.tool digitized_image_schema.json > /dev/null

Using AJV:

ajv compile \
  --spec=draft7 \
  -s ./digitized_image_schema.json

A failed parse or compile must stop the validation workflow. An HTML error page, empty file, malformed JSON document, or invalid schema must never be treated as an authoritative schema copy.

4 - Digital Asset Specifications

1. Purpose

This appendix defines baseline digital asset specifications for outsourced digitization of image-based collection materials. It is intended to support project-specific scopes of work (SOWs) and may be incorporated into any applicable vendor digitization agreements or contracts.

These specifications establish expected deliverables for several broad material categories:

• Reflective textual and graphic materials
• Reflective photographic materials
• Transmissive photographic materials, including film negatives, transparencies, slides, and glass plates
• Microform materials, including 16mm and 35mm roll microfilm, microfiche, and aperture cards
• Associated metadata, OCR, manifests, checksums, and quality control documentation.

Project-specific scopes may supplement or modify these requirements, but deviations must be approved in writing by the Library before production begins.

2. General Principles

2.1 Preservation and Access Deliverables

The Library may request multiple deliverable types for each project. These should be clearly distinguished by role.

Not every project will require every role. Each project-specific scope should identify required deliverables.

2.2 No Silent Substitution

The vendor shall not substitute file formats, compression methods, color profiles, bit depths, resolutions, OCR formats, naming conventions, metadata fields, or delivery structures without prior written approval from the Library.

2.3 Accurate Source-Sized Resolution

When resolution is specified in pixels per inch, the PPI shall be measured relative to the physical dimensions of the original source object, not the dimensions of a derivative file or resized output. Image files must include accurate resolution metadata in the appropriate TIFF or image header fields.

2.4 FADGI Conformance

Where applicable, digitization should be performed according to the FADGI Technical Guidelines for Digitizing Cultural Heritage Materials, using the appropriate object category, star level, targets, and conformance evaluation tools for the source material.

Unless otherwise specified:

• General textual and manuscript materials should meet FADGI 3-Star requirements at minimum.
• Rare, special, photographic, fine-detail, and high-value materials should meet FADGI 4-Star requirements where feasible.
• Transmissive materials should use appropriate transmissive targets and evaluation methods.
• Vendor documentation should identify the FADGI category and star level targeted for each project.

2.5 Targets and Calibration

The vendor shall utilize appropriate technical targets, calibration procedures, and process-control documentation for each material type to ensure FADGI compliance.

2.5.1 Reflective Materials (Object-Level Targets)

For reflective textual, graphic, and photographic print materials (Sections 3 and 4), the vendor shall utilize appropriate Image Science Associates (ISA) GoldenThread targets (such as the ISA Object Target or Device Target, as appropriate for the material size).

Preservation (U-Files): Targets must be captured inline with the source material as object-level target-bearing images. The target must be positioned within the frame so that it is fully visible, un-obscured, and flat, without overlapping any portion of the source collection item.

Production / Service (S-Files): The target must be digitally cropped out of the final delivered image. The crop must completely exclude the target while retaining a slight, uniform, and visible border of the capture background around the physical edges of the collection object. Overly tight cropping, flush cropping, or any crop that cuts into the physical boundary of the object is strictly prohibited.

2.5.2 Transmissive Materials (Batch/Session Calibration)

For transmissive materials (Section 5), technical calibration targets must be captured at the start of each production session or batch to establish, verify, and document equipment profiles.

Transmissive targets shall be included in the final delivery as separate, uncropped target images.

Targets must not be embedded within or captured inline with the source collection object images, unless an exception is explicitly requested and authorized in the project-specific SOW

3. Reflective Textual, Manuscript, Bound Volume, and Graphic Materials

3.1 Included Materials

This category includes:

• Bound volumes
• Rare books
• Manuscripts
• Loose paper
• Archival folders
• Correspondence
• Ledgers
• Scrapbooks
• Maps, posters, broadsides, and other graphic works, unless treated as oversized special projects
• Mixed paper-based collections.

Photographic prints may be handled under this category for routine access projects, but preservation-quality photographic print digitization should follow the photographic reflective specifications in Section 4.

3.2 Recommended Baseline Specifications

3.3 Handling of Bound Volumes

Unless explicitly authorized by the Library, bound volumes must be digitized non-destructively. The vendor shall use appropriate cradles, supports, lighting, and capture methods to avoid damage to bindings, pages, covers, inserts, and foldouts.

Project-specific instructions should define capture requirements for:

• Front cover
• Back cover
• Spine
• Endpapers
• Blank pages
• Foldouts
• Inserts
• Tipped-in items
• Page edges
• Bookplates
• Ownership marks
• Barcodes or labels.

4. Reflective Photographic Prints

4.1 Included Materials

This category includes:

• Black-and-white photographic prints
• Color photographic prints
• Mounted photographs
• Cabinet cards
• Cartes de visite
• Annotated prints
• Photographs with significant versos, mounts, stamps, captions, or enclosures.

4.2 Recommended Baseline Specifications

4.3 Versos, Mounts, and Enclosures

Project-specific instructions must state whether the vendor should capture:

• Versos
• Captions
• Stamps
• Annotations
• Mounts
• Sleeves
• Enclosures
• Folder labels
• Item labels
• Barcodes.

When versos or associated enclosures are captured, the file naming convention must clearly distinguish front, back, mount, sleeve, enclosure, or label images.

5. Transmissive Photographic Materials: Film, Slides, Transparencies, and Glass

5.1 Included Materials

This category covers transmissive media, divided into two operational tracks based on whether the original source image is a negative or a native positive:

Negative Materials Track: Black-and-white negatives, color negatives, sheet film negatives, roll film negatives, nitrate negatives, acetate negatives, and glass plate negatives.

Positive Materials Track: Color transparencies, mounted slides (Kodachrome, Ektachrome, etc.), lantern slides, and glass transparencies.

5.2 Preservation and Derivative Concept

To preserve both the physical reality of a transmissive artifact and its human-readable interpretation, different asset counts and processing approaches are required depending on whether the original source media is a negative or a native positive:

For Negative Materials (Film & Glass): The vendor must maintain parallel production tracks, delivering six (6) files total per physical item: two preservation, two service (one negative, one positive), and two access JPEGs (one negative, one positive). The two mandatory preservation files are defined as follows:

Negative Preservation Master (U-File): A faithful, raw, un-inverted capture of the source negative as a negative image. For color negatives, the integral film base and orange mask must remain fully intact. The primary purpose of this file is to retain the absolute, objective physical and informational content of the film base.

Positive Preservation Master: A high-fidelity, digitally inverted positive image derived directly from the raw capture. This master must be tonally adjusted and optimized for visual interpretation, preserving maximum tonal information across the histogram while strictly avoiding highlight or shadow clipping, excessive contrast compression, or data loss.

For Positive Materials (Slides & Transparencies): Because these items are natively positive, no inversion or dual-tracking is required. The vendor shall deliver three (3) files total per physical item: one preservation (U-File), one production/service (S-File), and one web display/access JPEG. The preservation master represents a faithful, raw capture of the positive transparency or slide without any undocumented tonal adjustments.

5.3 Black-and-White Film Negatives (6-File Dual Track)

5.4 Color Film Negatives (6-File Dual Track)

5.5 Color Transparencies and Mounted Slides (3-File Single Track)

This section applies to natively positive film transmissive materials (e.g., Kodachrome, Ektachrome, slides).

5.6 Glass Plate Negatives and Glass Transparencies

Glass materials require specialized handling and will be mapped to the file structures established above via individual project SOWs:

Glass Plate Negatives: Shall follow the six (6) file dual-track role structure, inversion logic, and bit-depth specifications outlined for film negatives in Section 5.3 (Grayscale) or Section 5.4 (Color).

Glass Transparencies and Lantern Slides: Shall follow the three (3) file single-track role structure outlined for positive transmissive materials in Section 5.5.

5.6.1 Technical Modifications for Glass Substrates

Regardless of the file track utilized, all glass-based materials must adhere to the following baseline modifications:

Resolution: Sampling frequency shall be defined in the project SOW relative to the physical dimensions of the glass plate (typically a minimum of 400 to 600 PPI natively), without digital interpolation.

Cropping: For Preservation file (U-Files), the entire physical glass plate must be fully visible. The vendor must retain all physical edges, corners, emulsion damage, glass cracks, silver mirroring, and historical labels or markings.

Color Mode: If a black-and-white glass negative exhibits severe chemical deterioration, silver mirroring, or hand-coloring, the Library may mandate an RGB color capture in the SOW to preserve these physical attributes.

5.7 Glass and Fragile Transmissive Handling Requirements

The vendor shall use handling and capture methods appropriate for fragile glass and transmissive photographic materials. Requirements may include:

• Low-heat or cold illumination
• Minimal exposure time
• Appropriate custom supports for cracked or structurally compromised glass
• No direct physical pressure placed on emulsion surfaces (e.g., placing glass plates emulsion-side up on a low-iron, anti-reflective lower glass shelf)
• Meticulous handling of flaking or lifting emulsions
• Procedures for broken or cracked plates
• Immediate reporting of unstable or unsafe items
• Project-specific approval before attempting capture of damaged items.

Specific equipment may be proposed by the vendor, but the Scope of Work should describe the required outcome rather than requiring a named lighting system unless the Library has a specific technical reason to mandate it.

5.8 Inversion and Tonal Adjustment Requirements

For negative-to-positive conversions, the vendor shall provide a fully documented, repeatable inversion workflow. Positive files must be visually optimized for immediate display while retaining full tonal representation across the histogram.

The vendor shall avoid:

• Clipping highlights or shadows
• Excessive contrast expansion
• Unnatural tonal compression
• Automated correction that obscures source characteristics
• Removal of historically or physically meaningful marks
• Inconsistent positive rendering across a batch.

The Library may require approval of a pilot batch before production begins, especially for negative inversion and glass plate projects.

6. Microform Materials

6.1 Included Materials

This category includes:

• 16mm roll microfilm
• 35mm roll microfilm
• Positive microfilm
• Negative microfilm
• Silver gelatin, diazo, and vesicular film
• Microfiche
• Aperture cards
• Microfilm containing newspapers, books, manuscripts, records, drawings, or other source documents.

6.2 General Approach

Microform materials are already surrogates of original documents. The primary goal is usually legibility, completeness, accurate sequencing, and support for OCR and access. However, preservation files should still be created in a stable, well-documented format with sufficient tonal information to support future derivative creation.

When a single physical microform item contains multiple distinct intellectual units, the vendor may separate those units into approved subdirectories for navigation and downstream processing. This intellectual segmentation must not interrupt or reset the physical frame sequence. Frame numbering shall remain continuous across the complete barcode-level object, from the first captured frame through the last.

6.3 Recommended Baseline Specifications

6.4 Reduction Ratio and Source-Sized PPI

When PPI is specified relative to original page size, the vendor shall document the method used to determine or estimate reduction ratio. If the reduction ratio is unknown, the vendor shall document assumptions and notify the Library if the source material cannot reasonably meet the required effective resolution.

6.5 Microfilm OCR

For OCR projects, the vendor shall provide project-specific OCR deliverables. Searchable PDF alone should not be the only OCR deliverable unless explicitly approved.

Possible OCR deliverables include:

• Searchable PDF
• Plain text
• ALTO XML
• hOCR
• METS/ALTO packages
• OCR confidence reports
• Exception reports for unreadable frames or pages.

The vendor shall identify source conditions likely to limit OCR quality, such as poor exposure, skew, density variation, bleed-through, blurred frames, damaged film, handwritten text, unusual typography, mixed languages, or complex layouts.

6.6 Aperture Cards and Technical Drawings

Aperture cards and microforms containing technical drawings, maps, or oversized originals may require higher effective resolution, special cropping, or delivery structures. Project-specific scopes should define these requirements separately.

7. File Naming and Directory Structure

7.1 General Naming Variations

All files delivered under this agreement shall follow a consistent, underscore-delimited naming convention based on the Library-issued 14-digit barcode identifier (pattern: 33433\d{9}). Filenames shall use one of the following two structures:

1. Standard Workflow (Reflective Materials, Slides, Transparencies, and Microform):
   [barcode]_[side-or-sequence]_[role].[extension]

2. Dual-Track Negative Workflow (Film and Glass Negatives Only):
   [barcode]_[component]_[side-or-sequence]_[role].[extension]

Multi-unit intellectual segmentation does not create a separate filename pattern. When a single physical item contains multiple distinct intellectual units, files shall retain the applicable standard filename and shall be organized into unit subdirectories within the barcode-level bag, as described in Section 7.5.

Zero-Padding: All page, frame, and asset sequences must be zero-padded to a strict five-digit (5) width (e.g., 00001). Unit directory identifiers must be zero-padded to a strict three-digit (3) width (e.g., u001).

7.1.1 Multi-Unit Organization and Absolute Physical Sequence

A unit represents a distinct intellectual work or content grouping identified within one physical barcode-level object. Unit divisions are organizational and descriptive; they do not create new physical objects, new barcode identifiers, or separate BagIt packages.

For multi-unit items:

• The barcode-level bag remains the sole delivery package for the physical item.
• Unit subdirectories shall be named u001, u002, and so forth, in the order in which the units first appear on the physical carrier.
• Unit identifiers shall appear in directory paths and metadata, but not in asset filenames.
• The physical frame sequence shall begin at 00001 and continue without resetting at unit boundaries.
• All preservation, service, access, OCR, and sidecar files derived from the same physical frame shall use the same absolute sequence number.
• Sequence numbers must not be duplicated across unit directories. Any intentional gap caused by an omitted, unreadable, or uncaptured frame must be documented in the applicable exception report.

For example, if u001 contains physical frames 1–980 and u002 contains physical frames 981–1650, the final frame in u001 shall use sequence 00980, and the first frame in u002 shall use sequence 00981. If the TIFF files are later gathered from all unit directories and sorted by filename, they will retain the original physical order of the complete item.

7.2 Naming Elements, Components, and Role Codes

7.3 Mandatory Sidecar Metadata Requirements

The vendor shall deliver file-level metadata utilizing individual, matching JSON sidecar files for every primary digital asset produced. Standing or bulk metadata files delivered in lieu of individual sidecars do not satisfy this requirement.

Strict 1:1 Asset Pairing: Every single image, document, or derivative file delivered—including all preservation masters, service masters, access files, and OCR files—must be accompanied by exactly one corresponding JSON file. Combining or nesting metadata for multiple files into a single master JSON array or bulk manifest is strictly prohibited under this requirement.

Exact Character Matching: The filename of the JSON sidecar must match the base filename of its paired asset character-for-character, shifting only the file extension to lowercase .json. For example, [filename]_pres.tif must be paired with [filename]_pres.json, and [filename]_access.jpg must be paired with [filename]_access.json. Any case mismatches, truncation, or spacing discrepancies between the asset file and its sidecar file will result in mandatory batch rework.

Directory Co-location: Each JSON sidecar file must reside in the exact same payload directory as its paired asset. For standard items, this will normally be the bag’s data/ directory. For multi-unit items, both the asset and its sidecar must reside together in the applicable unit subdirectory, such as data/u001/ or data/u002/.

Data Ingestion and Schema Compliance: The internal structural formatting, required fields, and data values populated within each individual JSON sidecar file must strictly adhere to the external metadata workflow and schema validation rules outlined in Section 8.

7.4 Delivery Examples

Scenario A: Standard Reflective Photo Print with Front and Back (No Component Code)

Barcode ID: 33433123456789

• Front (Recto) Preservation Master & Sidecar: 33433123456789_r_pres.tif and 33433123456789_r_pres.json
• Front (Recto) Access JPEG & Sidecar: 33433123456789_r_access.jpg and 33433123456789_r_access.json
• Back (Verso) Preservation Master & Sidecar: 33433123456789_v_pres.tif and 33433123456789_v_pres.json

Scenario B: Complex Dual-Track Transmissive Negative (Component Required)

Barcode ID: 33433987654321

• Raw Negative Preservation Master & Sidecar: 33433987654321_negative_00001_pres.tif and 33433987654321_negative_00001_pres.json
• Inverted Positive Preservation Master & Sidecar: 33433987654321_positive_00001_pres.tif and 33433987654321_positive_00001_pres.json

Scenario C: Microfilm Reel Containing Multiple Distinct Intellectual Units

Barcode ID: 33433555554444
Physical structure: Pamphlet 1 occupies frames 1–980; Pamphlet 2 occupies frames 981–1650.

• Pamphlet 1, first frame: data/u001/33433555554444_00001_serv.tif and data/u001/33433555554444_00001_serv.json
• Pamphlet 1, final frame: data/u001/33433555554444_00980_serv.tif and data/u001/33433555554444_00980_serv.json
• Pamphlet 2, first frame: data/u002/33433555554444_00981_serv.tif and data/u002/33433555554444_00981_serv.json
• Pamphlet 2, final frame: data/u002/33433555554444_01650_serv.tif and data/u002/33433555554444_01650_serv.json

The unit directory changes at the intellectual boundary, but the filename sequence remains continuous across the complete physical reel. Corresponding preservation, access, OCR, and JSON sidecar files shall use the same absolute frame number and reside in the same unit directory as the service file.

7.5 Directory Structure: BagIt Packaging Rules

One Bag per Barcode: Each unique physical barcode identifier shall be delivered as one independent, self-contained, BagIt-compliant directory named exactly by its barcode (for example, 33433987654321/). A barcode-level object must not be divided into multiple bags solely because it contains multiple intellectual units.

Multi-Unit Payload Organization: When a barcode-level object contains distinct intellectual units, the units shall be represented as subdirectories beneath the single bag’s data/ directory. Unit directories shall be named u001, u002, and so forth, in the order in which the units first appear on the physical carrier. Descriptive titles shall be recorded in metadata rather than embedded in directory names.

Single Manifest Coverage: The root bag’s manifest-md5.txt must include every payload file in every unit directory using its full relative payload path (for example, data/u002/33433555554444_00981_pres.tif). Unit directories must not contain separate bagit.txt, bag-info.txt, or manifest files.

Absolute Sequence Across Units: Sequential filenames shall represent the physical order of the complete barcode-level object. Sequence numbering must continue across unit boundaries and must never restart at 00001 for a later unit.

Example 1: Basic Reflective Directory Layout (Photo Print with Front and Back)

33433123456789/                                  <-- Root folder named by barcode
├── bagit.txt                                    <-- BagIt declaration
├── manifest-md5.txt                             <-- Checksums for all files beneath /data
├── bag-info.txt                                 <-- Bag administrative metadata
└── data/                                        <-- Payload directory
    ├── 33433123456789_r_pres.tif                <-- Front/recto preservation master
    ├── 33433123456789_r_pres.json               <-- Matching sidecar JSON
    ├── 33433123456789_r_serv.tif                <-- Front/recto service master
    ├── 33433123456789_r_serv.json               <-- Matching sidecar JSON
    ├── 33433123456789_r_access.jpg              <-- Front/recto access image
    ├── 33433123456789_r_access.json             <-- Matching sidecar JSON
    ├── 33433123456789_v_pres.tif                <-- Back/verso preservation master
    ├── 33433123456789_v_pres.json               <-- Matching sidecar JSON
    ├── 33433123456789_v_serv.tif                <-- Back/verso service master
    ├── 33433123456789_v_serv.json               <-- Matching sidecar JSON
    ├── 33433123456789_v_access.jpg              <-- Back/verso access image
    └── 33433123456789_v_access.json             <-- Matching sidecar JSON

Example 2: Complex Dual-Track Negative Directory Layout (Frame 1 of Roll)

33433987654321/                                  <-- Root folder named by barcode
├── bagit.txt                                    <-- BagIt declaration
├── manifest-md5.txt                             <-- Checksums for all files beneath /data
├── bag-info.txt                                 <-- Bag administrative metadata
└── data/                                        <-- Payload directory
    ├── 33433987654321_negative_00001_pres.tif   <-- Raw negative preservation master
    ├── 33433987654321_negative_00001_pres.json  <-- Matching sidecar JSON
    ├── 33433987654321_positive_00001_pres.tif   <-- Inverted positive preservation master
    ├── 33433987654321_positive_00001_pres.json  <-- Matching sidecar JSON
    ├── 33433987654321_negative_00001_serv.tif   <-- Raw negative service master
    ├── 33433987654321_negative_00001_serv.json  <-- Matching sidecar JSON
    ├── 33433987654321_positive_00001_serv.tif   <-- Inverted positive service master
    ├── 33433987654321_positive_00001_serv.json  <-- Matching sidecar JSON
    ├── 33433987654321_negative_00001_access.jpg <-- Raw negative access image
    ├── 33433987654321_negative_00001_access.json <-- Matching sidecar JSON
    ├── 33433987654321_positive_00001_access.jpg <-- Inverted positive access image
    └── 33433987654321_positive_00001_access.json <-- Matching sidecar JSON

Example 3: Multi-Unit Microfilm Directory Layout (Two Pamphlets on One Reel)

In this example, u001 contains frames 00001–00980, and u002 contains frames 00981–01650. The ellipses indicate additional files following the same naming and sidecar-pairing rules.

33433555554444/                                  <-- One root bag for the complete physical reel
├── bagit.txt                                    <-- BagIt declaration
├── manifest-md5.txt                             <-- Checksums for files in both unit directories
├── bag-info.txt                                 <-- Bag administrative metadata
└── data/                                        <-- Payload directory
    ├── u001/                                    <-- First intellectual unit: Pamphlet 1
    │   ├── 33433555554444_00001_pres.tif        <-- Physical frame 1 preservation master
    │   ├── 33433555554444_00001_pres.json       <-- Matching sidecar JSON
    │   ├── 33433555554444_00001_serv.tif        <-- Physical frame 1 service master
    │   ├── 33433555554444_00001_serv.json       <-- Matching sidecar JSON
    │   ├── 33433555554444_00001_access.pdf      <-- Physical frame 1 access file
    │   ├── 33433555554444_00001_access.json     <-- Matching sidecar JSON
    │   ├── 33433555554444_00001_ocr.xml         <-- Physical frame 1 coordinate OCR
    │   ├── 33433555554444_00001_ocr.json        <-- Matching OCR sidecar JSON
    │   ├── ...
    │   ├── 33433555554444_00980_pres.tif        <-- Final physical frame in u001
    │   └── 33433555554444_00980_pres.json       <-- Matching sidecar JSON
    └── u002/                                    <-- Second intellectual unit: Pamphlet 2
        ├── 33433555554444_00981_pres.tif        <-- Sequence continues; it does not reset
        ├── 33433555554444_00981_pres.json       <-- Matching sidecar JSON
        ├── 33433555554444_00981_serv.tif        <-- Physical frame 981 service master
        ├── 33433555554444_00981_serv.json       <-- Matching sidecar JSON
        ├── 33433555554444_00981_access.pdf      <-- Physical frame 981 access file
        ├── 33433555554444_00981_access.json     <-- Matching sidecar JSON
        ├── 33433555554444_00981_ocr.xml         <-- Physical frame 981 coordinate OCR
        ├── 33433555554444_00981_ocr.json        <-- Matching OCR sidecar JSON
        ├── ...
        ├── 33433555554444_01650_pres.tif        <-- Final physical frame on the reel
        └── 33433555554444_01650_pres.json       <-- Matching sidecar JSON

8. Embedded Metadata and External Metadata

8.1 General Approach

The Library utilizes a multi-tiered metadata strategy to maintain digital object lineage. Technical and administrative metadata are captured at two distinct levels: minimal metadata embedded directly within file headers, and robust, file-level external metadata delivered via the JSON sidecar files specified in Section 7.3. External metadata files serve as the primary descriptive and validation mechanism for repository ingestion.

8.2 Embedded Metadata Requirements

The vendor shall embed baseline technical and administrative metadata directly into the headers of all TIFF and derivative files where supported by the file format. Embedded metadata fields must be populated programmatically during capture and processing, and may include:

• Unique identifier / Barcode
• File title or document name
• Library/institution name and credit line
• Copyright or rights statement (if supplied by the Library)
• Source collection name (if supplied by the Library)
• Capture date and timestamp
• Digitization vendor name
• Capture hardware metrics (Camera/scanner make, model, and lens information)
• Capture software name and version number
• Resolution (Sampling frequency) and bit depth
• Assigned color space profile (ICC Profile)
• Image pixel dimensions and orientation
• Standard technical EXIF, XMP, IPTC, and TIFF header fields

8.3 Checksums and Fixity

Cryptographic checksums used for file fixity validation must be delivered via the external BagIt manifests (manifest-md5.txt) as outlined in Section 7.5, rather than embedded as the primary fixity mechanism inside image headers or duplicated inside item sidecars. The mandatory algorithm for all project delivery manifests is MD5.

8.4 External Metadata Workflow and JSON Schema Validation

To generate the mandatory 1:1 file-level JSON sidecars required by Section 7.4, the vendor shall execute a three-phase metadata aggregation and synthesis workflow:

Phase 1: Library-Supplied Source Baseline

Prior to production or upon shipment delivery, the Library will provide the vendor with a standardized project inventory spreadsheet in XLSX format (as specified in the Inventory Spreadsheet Specification). This file acts as the authoritative intake data source for the project and provides item-level baseline data, including:

• Administrative Tracking: schema_version and project_code
• Primary Identifiers: Library barcode (barcode matching ^33433\d{9}$), division_code, bnumber, classmark, aspace_component_id, collection_id, and item_title
• Physical Object Classification: Controlled vocabulary pairings for object_type and object_format, alongside any physical_condition_notes observed at selection
• Known Multi-Unit Structure: When identified before capture, unit_index and unit_title for distinct intellectual units contained within a single physical barcode-level object (for example, multiple pamphlets on one microfilm reel). Unit boundaries discovered or refined during capture must be recorded by the vendor as part of the production metadata.

Phase 2: Vendor-Generated JSON Synthesis

The vendor must programmatically extract the item-level fields from the Library’s intake spreadsheet and map them into their corresponding schema objects (administrative, identifiers, source). The vendor’s processing scripts must then synthesize this baseline data with file-level operational metadata captured dynamically during production to generate individual 1:1 JSON sidecar files.

Per the JSON Sidecar Schema Specification, the capture-specific properties the vendor must inject into each sidecar include:

• Asset Metadata (asset): The exact referenceFilename (strictly validated against the project naming regex pattern) and the designated fileRole (pres, serv, access, or ocr).
• Sequential Capture and Unit Tracking (source.sequence): The integer sequenceNumber (for example, 24, rendered as 00024 in the filename), the applicable unitIndex, the two-sided object side indicator (r for recto, v for verso), and a human-readable sequenceLabel depicting physical reality (for example, "Recto", "Page 42", or "Front Cover"). For sequential multi-unit items, sequenceNumber must represent the absolute physical sequence across the complete barcode-level object and must not reset when unitIndex changes.
• Digitization Process Audit (digitizationProcess): Granular hardware and software audit trails, including captureDevice (manufacturer, model, lens, serialNumber), captureSoftware (manufacturer, productName, version), and the specific optical calibrationTarget utilized during the capture session.
• Operator & Organization Tracking (digitizer): Vendor administrative data, including operator (firstName, lastName) and organization (name).

(Note: To maintain separation of concerns, file sizes, pixel dimensions, and ICC profiles remain embedded within image headers per Section 8.2, while MD5 cryptographic checksums remain strictly within external BagIt manifests per Section 8.3. Unit membership is represented by the data/u###/ payload path and the corresponding unit metadata; it is not encoded in the asset filename.)

Phase 3: Schema Validation

The final structural composition, key-value pairings, nesting logic, and required fields of the delivered JSON sidecars must strictly validate against the formal JSON Schema specification provided by the Library.

Schema Provision: The authoritative, live JSON Schema file (digitized_image_schema.json) is maintained and published by the Library at the following canonical endpoint:

• Canonical Schema URI ($id): https://nypl-research.github.io/digital-imaging-resources/schemas/digitized_image_schema.json

Mandatory 100% Pre-Delivery Validation: The vendor shall implement automated command-line schema validation (using industry-standard tools such as ajv-cli or Python’s jsonschema) as part of their 100% Quality Control pipeline (Section 9.1). Every single delivered JSON sidecar file must pass validation against the Library-supplied schema without error. Any files containing malformed JSON syntax, invalid data types, unmapped properties (additionalProperties: false), regex filename mismatches, or structural non-compliance will result in the immediate rejection of the entire delivery batch.

9. Quality Control Requirements

9.1 Vendor 100% QC

The vendor shall perform quality control before delivery. Unless otherwise specified, vendor QC shall include 100% review or automated validation for:

• File presence
• File naming
• One barcode-level bag per physical item
• Directory structure and approved u### unit assignments, where applicable
• Sidecar co-location with each paired asset
• Sequence completeness
• Continuous absolute sequence numbering across all unit directories, with no resets or duplicates
• Checksum creation
• File format validation
• ICC profile presence and correctness
• Bit depth
• Color mode
• Resolution metadata
• Pixel dimensions
• Corrupt or unreadable files
• Manifest completeness
• OCR deliverable presence, if applicable.

9.2 Vendor Visual QC

The vendor shall visually review files for issues including:

• Blurred focus
• Motion blur
• Incorrect exposure
• Clipped highlights or shadows
• Color imbalance
• Newton’s rings
• Dust or debris
• Reflections or glare
• Cropped text or image content
• Incorrect orientation
• Excessive skew
• Moiré or scanner artifacts
• Missing pages, frames, or sides
• Incorrect negative inversion
• Inconsistent tonal rendering
• Visible handling damage or newly discovered condition issues.

Unless a 100% manual visual review is explicitly funded in an SOW, the vendor shall conduct a manual visual inspection on a statistically valid random sample (minimum 10%) of each batch.

9.3 Technical Validation Tools

The vendor shall use appropriate validation and analysis tools, which may include:

• JHOVE for file format validation and characterization
• ExifTool for embedded metadata review
• OpenDICE, AutoSFR, GoldenThread, or equivalent tools for image quality conformance testing
• Checksum tools capable of generating MD5 manifests
• OCR validation or confidence reporting tools, where applicable.

9.4 Library Pilot Review

Before mass production, the Library may review a pilot batch. The pilot batch should be representative of the full project and may include:

• 25–50 images, or another agreed sample size
• Multiple formats and conditions
• Fronts/backs or rectos/versos
• Negative and positive versions for transmissive materials
• OCR output, if applicable
• Metadata records
• File manifests
• Checksum manifests
• QC reports
• Target images.

The Library may use the pilot to approve:

• Image quality
• Cropping
• Orientation
• Naming
• Directory structure
• Multi-unit boundaries, unit directory assignments, and absolute sequence continuity, where applicable
• Metadata structure
• Negative inversion look and tonal handling
• OCR package structure
• QC reporting format.

Full production shall not begin until the Library approves the pilot batch, unless the Library waives this requirement in writing.

9.5 Acceptance and Rework

Deliverables are not accepted until the Library completes its review and confirms that files, metadata, OCR, and documentation meet project requirements.

The vendor shall correct vendor-responsible errors at no additional cost. Rework may be required for:

• Missing files
• Incorrect file names
• Incorrect sequence, including duplicate numbers, gaps without approved exception documentation, or sequence resets at unit boundaries
• Incorrect unit directory assignment or delivery of separate bags for units belonging to one physical barcode-level object
• Sidecar files placed outside the directory containing their paired assets
• Incorrect or missing checksums
• Corrupt files
• Incorrect bit depth, color profile, or file format
• Poor focus
• Cropped content
• Unauthorized image processing
• Clipped tonal values
• Incorrect negative inversion
• Incomplete metadata
• Incorrect OCR package structure
• Incomplete or inaccurate manifests
• Failure to follow approved specifications.

5 - Barcode Assignment and Application Recommendations

Barcode Assignment and Application Recommendations

Status: Discussion draft
Purpose: Establish a practical, scalable barcode framework for preparing image-based collection materials for vendor digitization.
Scope: Physical collection materials selected for outsourced image-based digitization, including bound volumes, manuscripts, photographs, negatives, transparencies, glass plates, microforms, oversized materials, and mixed archival collections.

1. Purpose

Reliable barcode assignment is a foundational requirement for vendor digitization. A barcode provides the persistent physical identifier that connects:

• the source collection object or enclosure;
• the Library’s inventory and descriptive systems;
• vendor shipment and production tracking;
• digital filenames and JSON sidecars;
• BagIt packaging and delivery manifests;
• quality-control and rework workflows; and
• the returned physical material and resulting digital assets.

Unlike Audio and Moving Image workflows, image-based collections do not currently follow one uniform institution-wide practice for determining which physical level should receive a barcode. The appropriate level may be obvious for a single bound volume or microfilm reel, but less obvious for a manuscript box containing many folders, a box of photographic prints, or a slide box containing hundreds of individual images.

This document proposes a consistent decision framework while recognizing that barcodes may be recorded in different systems depending on the collection and material type. It focuses primarily on:

1. what a barcode should identify;
2. which physical level should be barcoded;
3. where and how a barcode should be applied;
4. how parent containers and subordinate digitization units should relate;
5. how barcodes should support vendor production and digital delivery; and
6. the minimum information that must be recorded before materials leave the Library.

2. Executive Recommendation

The Library should distinguish between two barcode roles.

2.1 Container Barcode

A container barcode identifies a custody, storage, or transport container such as:

• an archival box;
• a microfilm box;
• a slide box;
• a negative box;
• a portfolio;
• a map folder;
• a tray; or
• another top-level housing.

The container barcode supports:

• location and movement control;
• shipment reconciliation;
• box-level counts;
• parent-child relationships;
• return verification; and
• top-container management in systems such as ArchivesSpace.

A container barcode does not automatically become the identifier used for digital filenames or BagIt packaging.

2.2 Digitization-Unit Barcode

A digitization-unit barcode identifies the physical unit that is treated as one independently controlled digitization object.

The digitization-unit barcode is the identifier used for:

• the vendor inventory record;
• digital filenames;
• JSON sidecars;
• BagIt root directories;
• quality-control reports;
• exception and rework tracking; and
• repository ingest.

Examples of digitization units include:

• one bound volume;
• one manuscript folder;
• one photographic print in an individual enclosure;
• one photograph album;
• one microfilm reel;
• one roll of film negatives;
• one glass plate;
• one map in an individual folder; or
• one physically coherent group intentionally digitized as a single object.

2.3 Parent-Child Relationship

When a container holds multiple digitization units, both levels should be represented:

Container barcode: 33433111111111
├── Folder barcode: 33433222222222
├── Folder barcode: 33433333333333
└── Folder barcode: 33433444444444

The container barcode supports custody and location. Each child barcode identifies a separate digitization package.

This distinction prevents one barcode from being forced to serve incompatible purposes.

3. Core Policy Principles

3.1 Barcode the Smallest Stable, Meaningful Control Unit

The digitization-unit barcode should identify the smallest physical unit that is:

• stable enough to handle independently;
• meaningful within the collection’s existing arrangement;
• practical to inventory and reconcile;
• expected to remain intact during vendor processing; and
• appropriate to represent as one digital package.

The smallest individual sheet, photograph, or frame should not automatically receive a barcode. Granularity should be driven by control, retrieval, arrangement, access, and production needs—not simply by the number of images created.

3.2 Do Not Barcode Every Digital Image

A barcode identifies a physical source unit, not every resulting digital file.

Pages, frames, rectos, versos, and derivatives are distinguished through:

• sequence numbers;
• side indicators;
• file-role codes;
• negative and positive components where applicable; and
• file-level JSON sidecars.

3.3 One Active Barcode Must Identify One Physical Control Unit

A barcode must not be reused for another item or container.

When an item is rehoused, the existing active barcode should normally remain associated with the same physical control unit. If a replacement barcode is required, the prior barcode must be retained in the record as inactive or superseded rather than silently reassigned.

3.4 Barcodes Must Not Encode Descriptive Meaning

The number should function as a persistent unique identifier. Collection, format, division, date, box, folder, and project meaning should be stored in metadata rather than inferred from the barcode number.

3.5 No Barcode Without a Record

Every barcode assigned for digitization must be logged before shipment.

At minimum, the barcode record must identify:

• what the barcode represents;
• the parent container, when applicable;
• the collection or catalog record;
• the material type;
• the responsible division;
• the current location; and
• the system or inventory in which the barcode is recorded.

3.6 Apply Barcodes to Housings, Not Collection Surfaces

The default practice should be to apply barcode labels to an appropriate enclosure rather than directly to original collection material.

Examples include:

• archival folders;
• envelopes;
• sleeves;
• four-flap enclosures;
• phase boxes;
• clamshell boxes;
• microfilm boxes;
• negative envelopes;
• backing cards; and
• protective wrappers.

Direct application to an original object should occur only when allowed by an established Library labeling policy and approved for that material category.

3.7 The Vendor Must Not Create or Reassign Library Barcodes

The Library must assign and record all authoritative barcodes before shipment.

A vendor may:

• scan and validate supplied barcodes;
• report missing, duplicated, damaged, or unreadable labels;
• use temporary internal production identifiers; and
• propose unit boundaries during a pilot.

A vendor must not:

• generate replacement Library identifiers;
• reassign a barcode;
• alter parent-child relationships;
• split or combine digitization units without authorization; or
• treat an internal vendor identifier as the Library’s authoritative barcode.

4. Definitions

5. Decision Framework

Use the following questions in order.

Step 1: Is the material already cataloged or retrieved as an independent item?

Examples:

• a cataloged book;
• a bound manuscript volume;
• an individually described map;
• an individual photograph;
• a microfilm reel;
• a glass plate.

Recommendation: Assign one digitization-unit barcode to the item or its dedicated enclosure.

Step 2: Is the material a container holding multiple independently meaningful units?

Examples:

• a manuscript box containing folders;
• a photograph box containing individually sleeved prints;
• a slide box containing separately organized groups;
• a box containing multiple volumes.

Recommendation: Assign:

1. one container barcode to the box or outer housing; and
2. separate digitization-unit barcodes to the subordinate units that will become independent digital packages.

Step 3: Are the subordinate units too granular to barcode individually?

Examples:

• hundreds of individual sheets within one correspondence folder;
• individual pages in a volume;
• individual frames on one microfilm reel;
• individual exposures on one negative roll;
• individual slides that are not separately described or retrieved.

Recommendation: Barcode the enclosing stable unit and distinguish the subordinate images through sequence metadata.

Step 4: Does one physical carrier contain multiple intellectual works?

Examples:

• one microfilm reel containing several pamphlets;
• one bound volume containing several separately titled works;
• one scrapbook containing multiple sections.

Recommendation: Retain one digitization-unit barcode for the physical carrier unless the contents are physically separated and independently controlled.

Represent internal intellectual divisions using:

• unitIndex;
• unitTitle;
• u### directories inside the BagIt data/ directory; and
• an uninterrupted absolute sequence across the complete physical item.

Step 5: Would the proposed barcode level create an unmanageably large or ambiguous digital object?

Consider:

• number of folders;
• expected image count;
• independent descriptive records;
• restrictions or rights differences;
• format changes;
• expected retrieval;
• likelihood of partial rework;
• vendor production routing; and
• repository ingest requirements.

Recommendation: Move the digitization-unit barcode down one meaningful physical level, normally from box to folder or from folder to individually enclosed item.

6. Recommended Barcode Levels by Material Type

7. Detailed Recommendations for Common Scenarios

7.1 Bound Books and Volumes

Assign one digitization-unit barcode per physical volume.

The barcode should be applied according to the following preference order:

1. a dedicated preservation enclosure;
2. a removable barcode flag, wrapper, or book band;
3. an approved location on a modern or general-collection binding; or
4. another location approved by Collection Management or Conservation.

Do not:

• place a barcode over original labels, inscriptions, stamps, or decorative elements;
• treat separate pages as separate barcode units;
• use one barcode for an entire multi-volume set; or
• apply an adhesive label directly to a rare or vulnerable binding without approval.

For a multi-volume work:

Volume 1 → one barcode and one BagIt bag
Volume 2 → one barcode and one BagIt bag
Volume 3 → one barcode and one BagIt bag

7.2 Boxes of Correspondence and Other Foldered Records

The recommended default is:

• one container barcode for the archival box; and
• one digitization-unit barcode for each folder selected for digitization.

Do not barcode every letter or sheet unless the collection is already arranged, described, and retrieved at item level or the project explicitly requires item-level digital objects.

Example:

Box barcode: 33433111111111
├── Folder 1 barcode: 33433222222222
│   └── 126 page images
├── Folder 2 barcode: 33433333333333
│   └── 83 page images
└── Folder 3 barcode: 33433444444444
    └── 211 page images

The folder barcode—not the box barcode—is used for the filenames and BagIt root of each folder-level delivery.

The box barcode is retained in the inventory as parentBarcode.

A folder may contain many pieces without requiring sub-item barcodes. The vendor should preserve physical order and assign page-level sequence numbers beneath the folder barcode.

When to split a folder into multiple barcode units

A folder should be divided into multiple barcode units only when:

• it already contains clearly established subfolders or packets;
• the units are separately described;
• separate rights or restrictions apply;
• the physical volume cannot be safely handled as one unit;
• different formats require separate production workflows;
• the units are expected to become separate access objects; or
• Collection Management or archival processing approves a physical subdivision.

Digitization staff or vendors should not independently reorganize archival folders solely to reduce image counts.

7.3 Photographic Prints

For individually described or independently retrieved photographs, assign one barcode per photograph and apply it to the photograph’s enclosure.

One barcode may govern multiple captures of the same object, including:

• recto;
• verso;
• mount;
• sleeve;
• enclosure;
• caption;
• label; and
• associated detail views.

For photographic groups that are not item-level described, use the folder, envelope, packet, or other coherent housing as the digitization unit.

The project plan should state whether access and repository objects will be created:

• per photograph;
• per folder;
• per packet; or
• per box.

7.4 Negatives, Transparencies, and Slides

Sheet-film and glass negatives

Assign one barcode per individually controlled negative or plate enclosure.

The same barcode governs both delivery tracks:

[barcode]_negative_00001_pres.tif
[barcode]_positive_00001_pres.tif

Do not assign separate barcodes to the negative and positive renderings. They are digital representations of the same physical source.

Roll film

Assign one barcode per physical roll or stable strip unit defined by the project.

Individual exposures are represented through sequence numbers rather than barcodes.

Slides and transparencies

Natively positive slides and transparencies do not use the word positive in the filename.

For large slide collections, the digitization unit may be:

• an individual slide;
• a slide page;
• a tray;
• a box;
• a photographer-defined group; or
• another stable arrangement unit.

The project must define the selected level before barcoding begins. Item-level barcoding should be used when individual slides are already described, retrieved, or expected to become separate repository objects. Group-level barcoding may be more practical for large, minimally processed collections.

7.5 Microfilm

Assign one digitization-unit barcode per physical microfilm reel.

Do not assign new physical barcodes to pamphlets, issues, volumes, or other intellectual units contained within the same reel unless they are physically separated carriers.

When a reel contains several intellectual works:

33433555554444/
└── data/
    ├── u001/
    ├── u002/
    └── u003/

The reel retains one barcode and one BagIt bag.

Internal unit membership is represented through:

• unitIndex;
• unitTitle;
• u### directories; and
• absolute sequence numbers that never reset across the reel.

7.6 Oversized and Flat Materials

Assign one digitization-unit barcode per independently controlled map, poster, broadside, drawing, or other oversized object.

Apply the barcode to:

• the object’s folder;
• a polyester sleeve;
• a portfolio;
• a wrapper; or
• another approved enclosure.

A flat-file drawer, portfolio, or transport folder may also receive a separate container barcode.

Do not apply the barcode directly to the image surface, verso, mount, or backing unless specifically approved.

7.7 Mixed-Format Boxes

Mixed-format boxes should receive a container barcode. Subordinate digitization units should be assigned based on the smallest stable, meaningful housing.

Examples:

Box barcode
├── Folder barcode: correspondence
├── Envelope barcode: photographic negatives
├── Volume barcode: ledger
└── Folder barcode: maps and diagrams

Separate child barcodes can support different vendor routing and technical specifications while preserving the parent box relationship.

8. Barcode Placement and Labeling

8.1 General Placement Rules

Barcode labels should:

• remain visible without disturbing the collection object;
• be placed consistently across a project;
• include the human-readable 14-digit number;
• avoid seams, folds, fasteners, edges, and curved surfaces;
• avoid existing descriptive labels and annotations;
• remain scannable when the unit is packed normally;
• be applied to the enclosure body rather than a removable lid when practical; and
• be tested with the intended scanner after application.

8.2 Recommended Placement Zones

These zones are proposed starting points and require confirmation from Collection Management and Conservation.

8.3 Label Materials

The Library should adopt approved label stock for at least three application categories:

1. folders and box-board;
2. approved book covers or book enclosures; and
3. plastic, metal, or other non-paper housings.

One adhesive and label stock should not be assumed safe or effective for every surface.

Final material specifications should be reviewed by Conservation and Collection Management before implementation.

8.4 Temporary Barcode Control Sheets

For vendor digitization, each digitization unit should also receive a removable barcode control sheet or lead card when practical.

The control sheet may include:

• scannable barcode;
• human-readable barcode;
• collection title;
• box and folder number;
• item or unit title;
• expected sides or sequence;
• special handling notes;
• restriction flags; and
• project code.

The control sheet should be placed at the beginning of the digitization unit and used by the vendor to initialize production tracking.

Unless specifically required as documentation, the control sheet should not be delivered as a preservation or access image.

9. Recording Barcodes and System Responsibilities

The final institution-wide system of record may vary by collection type. This policy should therefore establish a minimum cross-system model without requiring one application to solve every use case immediately.

9.1 Cataloged Items in Sierra

For cataloged books and other item-level materials, the digitization-unit barcode should be recorded in the applicable Sierra item record when Sierra is the authoritative physical-item system.

The project inventory should also include:

• Sierra bibliographic identifier;
• item record identifier, where available;
• call number;
• division;
• title; and
• current location.

9.2 Archival Containers in ArchivesSpace

ArchivesSpace should be used for top-container barcodes where boxes, reels, trays, portfolios, or similar containers are represented as top containers.

A local decision is still required for recording folder-level or item-level digitization barcodes when those units do not correspond to ArchivesSpace top containers.

Possible implementation options for review include:

• a local structured field;
• a user-defined field;
• an external identifier;
• a linked digital-preparation record;
• a controlled project registry keyed to the ArchivesSpace component URI; or
• a future collections-management integration.

9.3 SPEC

Because SPEC is expected to be deprecated, new barcode policy should not depend on SPEC as the sole authoritative system.

Existing SPEC identifiers and records may be retained and crosswalked where needed, but the future workflow should remain functional without new SPEC development.

9.4 Interim Barcode Registry

Until a durable institution-wide system is selected, the Library should maintain a controlled barcode registry for image digitization.

The registry may initially be a governed table, database, or standardized project spreadsheet, provided that:

• barcode issuance is controlled;
• duplicate values are prevented;
• changes are auditable;
• parent-child relationships are retained;
• system record identifiers are included; and
• the registry can export the vendor inventory format.

The project inventory sent to the vendor is a production manifest, not necessarily the permanent system of record.

10. Minimum Barcode Metadata

Each barcode record should include the following fields.

11. Vendor Inventory Requirements

Before shipment, the Library must provide the vendor with an inventory that:

• includes every digitization-unit barcode;
• identifies parent container barcodes;
• distinguishes container records from digitization-unit records;
• states the expected digitization granularity;
• records box, folder, volume, reel, or item designations;
• provides titles and collection identifiers;
• identifies known multi-unit physical items;
• flags restricted or fragile materials;
• identifies expected file roles;
• defines expected sequence behavior; and
• includes any approved exceptions.

The vendor must reconcile the physical shipment against the inventory before production begins.

12. Quality-Control Requirements

12.1 Pre-Shipment QC

The Library should verify 100% of assigned barcodes for:

• uniqueness;
• correct number length and format;
• scan readability;
• correct placement;
• correct physical association;
• correct barcode role;
• parent-child relationship;
• system or registry entry;
• inventory inclusion;
• consistency between human-readable and encoded values; and
• absence of duplicate or conflicting active barcodes.

12.2 Vendor Intake QC

At intake, the vendor should verify:

• every expected container was received;
• every expected digitization unit was received;
• each barcode scans successfully;
• barcode values match the inventory;
• parent-child relationships match the physical packing;
• no unit contains an unexpected duplicate barcode;
• no expected barcode is missing; and
• any discrepancy is reported before production.

12.3 Production QC

The vendor should validate that:

• filenames begin with the digitization-unit barcode;
• the barcode in each JSON sidecar matches the source unit;
• file roles and naming structures are correct;
• unit boundaries have not caused sequence resets;
• no container barcode was mistakenly used in place of a child digitization barcode;
• no temporary vendor identifier appears as the Library barcode; and
• all assets remain associated with the correct physical unit.

12.4 Return QC

Upon return, the Library should confirm:

• all containers and digitization units were returned;
• the physical hierarchy matches the outgoing inventory;
• barcode labels remain present and legible;
• no barcodes were altered or replaced without authorization;
• rehousing or unit changes are documented;
• the digital packages correspond to the expected digitization-unit barcodes; and
• all exceptions and rework items are resolved or tracked.

13. Exceptions

Any departure from these recommendations should be documented in the project scope or barcode plan.

Common exceptions may include:

• extremely high-volume slide or aperture-card collections;
• unprocessed collections lacking stable folder structure;
• materials that cannot safely receive or retain an enclosure;
• objects with pre-existing identifiers that cannot be replaced;
• externally owned or borrowed materials;
• items requiring conservation before labeling;
• one physical carrier containing unusually complex intellectual structure; and
• projects where repository constraints require a different digital-object level.

An exception record should state:

• the affected collection or project;
• the standard rule being modified;
• the approved alternative;
• the responsible approver;
• the metadata and packaging implications; and
• the duration of the exception.

14. Roles and Responsibilities

15. Required Project-Level Barcode Plan

Every image-digitization project should complete a barcode plan before large-scale preparation begins.

The plan should identify:

1. the physical material types included;
2. the proposed container level;
3. the proposed digitization-unit level;
4. whether any child barcodes are required;
5. where each barcode role will be recorded;
6. who will issue, apply, and quality-check the labels;
7. the approved label stock and placement;
8. any material requiring Conservation review;
9. the expected relationship between barcodes and digital packages;
10. treatment of internal intellectual units;
11. expected shipment and return reconciliation;
12. known exceptions; and
13. the pilot sample used to test the approach.

16. Pilot and Approval Process

Before barcoding an entire collection, the project team should test the proposed model on a representative sample.

The pilot should include, where applicable:

• one simple item, such as a bound volume;
• one foldered archival box;
• one photographic group;
• one negative or transparency format;
• one multi-unit microfilm reel;
• one oversized or fragile object; and
• one mixed-format container.

The pilot should test:

• barcode level;
• label placement;
• scan readability;
• inventory structure;
• parent-child relationships;
• vendor intake;
• filename and BagIt generation;
• JSON-sidecar mapping;
• QC reporting; and
• physical return reconciliation.

The barcode plan should be revised after the pilot and approved before full production.

17. Implementation Roadmap

Phase 1: Policy Review

Circulate this draft to:

• Collection Management;
• Conservation;
• Archival Processing;
• Cataloging;
• Sierra stakeholders;
• ArchivesSpace stakeholders;
• Digital Imaging Services;
• Metadata Services Unit;
• curatorial divisions; and
• Procurement or vendor-management staff.

The review should focus on gaps, unacceptable risks, system constraints, and format-specific exceptions.

Phase 2: Establish Barcode Governance

Define:

• who controls barcode issuance;
• which barcode ranges are approved;
• whether container and digitization-unit barcodes use the same number pool;
• how duplicate prevention is enforced;
• how replacements are handled;
• how cancelled numbers are retained; and
• who owns the interim registry.

Phase 3: Define System Mappings

Document how the minimum barcode metadata maps to:

• Sierra;
• ArchivesSpace;
• SPEC during transition;
• the interim barcode registry;
• the vendor inventory spreadsheet;
• the JSON sidecar; and
• the preservation or access repository.

Phase 4: Approve Physical Application Standards

Conservation and Collection Management should approve:

• label stock;
• adhesives;
• label dimensions;
• print quality;
• placement zones;
• direct-application exceptions;
• barcode-control sheets; and
• rehousing requirements.

Phase 5: Pilot

Select one or more representative projects and test the full workflow from barcode assignment through digital delivery and physical return.

Phase 6: Publish Operational Instructions

Convert the approved policy into:

• a concise staff decision tree;
• illustrated placement instructions;
• a barcode-registry data dictionary;
• a pre-shipment QC checklist;
• a vendor intake checklist; and
• project-specific barcode-plan templates.

18. Questions Requiring Institutional Decision

The following issues should be resolved during stakeholder review.

1. System of record: Where should folder-level and item-level digitization barcodes be permanently recorded when Sierra and ArchivesSpace do not provide a natural item record?
2. Barcode issuance: Which team owns the barcode number pool and prevents duplication?
3. Folder-level policy: Should folder-level digitization barcoding be the default for all fully digitized archival boxes, or only for vendor projects?
4. Pre-existing barcodes: When may an existing container or item barcode be reused as the digitization-unit barcode?
5. ArchivesSpace representation: Should folder-level barcode relationships be stored in ArchivesSpace, in an external registry, or both?
6. Repository object level: Does the future DAMS or repository expect one object per barcode, and can it support parent-child relationships?
7. High-volume exceptions: What is the threshold at which individual barcoding becomes impractical for slides, aperture cards, photographs, or negatives?
8. Label application: Which surfaces and label materials are approved by Conservation?
9. Staffing: Which staff group will barcode, scan, record, and quality-check materials before shipment?
10. Backlog: Will this policy apply only to new vendor projects or also guide retrospective normalization?
11. Barcode control sheets: Should lead sheets be mandatory for every digitization unit or only for selected formats?
12. Vendor discovery: What should happen when a vendor finds previously unidentified intellectual units or physical subdivisions?
13. Mixed-format routing: When should one folder be split into multiple digitization units because its contents require different capture workflows?
14. Restricted content: Can one barcode package contain both restricted and unrestricted content, or must those units be separated?
15. Replacement policy: How should missing, damaged, or duplicated barcode labels be replaced and documented?

19. Proposed Default Rules for Initial Adoption

Pending broader review, the following rules are recommended as an initial institutional baseline:

1. Use one digitization-unit barcode per physical volume, reel, folder, individually enclosed photograph, negative, plate, map, or comparable stable unit.
2. Use a separate container barcode for boxes, trays, portfolios, and other housings that contain multiple digitization units.
3. For manuscript and correspondence collections, barcode the box and each folder selected for digitization; do not barcode every sheet.
4. Use the digitization-unit barcode—not the parent container barcode—for filenames, JSON sidecars, BagIt roots, QC, and ingest.
5. Maintain parent-child relationships in the barcode registry and vendor inventory.
6. Apply labels to housings rather than directly to original materials.
7. Do not create separate barcodes for rectos, versos, pages, frames, access derivatives, or negative/positive digital tracks.
8. Retain one barcode for a multi-unit physical carrier such as a microfilm reel; express internal units through metadata and subdirectories.
9. Require all authoritative barcodes to be assigned and recorded by the Library before shipment.
10. Pilot and document exceptions before large-scale production.

20. Recommended Supporting Documents

This policy should ultimately be accompanied by:

• Barcode Decision Tree: One-page staff guide for choosing the barcode level.
• Barcode Placement Guide: Illustrated format-by-format placement instructions.
• Barcode Registry Data Dictionary: Required fields, controlled values, and validation rules.
• Project Barcode Plan Template: Project-level decisions, responsibilities, and exceptions.
• Pre-Shipment Barcode QC Checklist: 100% validation steps before packing.
• Vendor Barcode Intake Checklist: Reconciliation and discrepancy-reporting requirements.
• Replacement and Exception Procedure: Rules for damaged, missing, duplicate, or superseded labels.
• System Mapping Appendix: Sierra, ArchivesSpace, SPEC, registry, inventory, and repository crosswalks.