item_id |
VRA Core 4 — work.refid; local app primary key |
Object ID# |
Main screen
PP generates its own sequence; reconciliation needed at import |
Our Field
Every photograph in the system needs a unique ID number that belongs to it and only it. We use item_id for this instead of the accession number because some accession numbers are shared across many photographs — the same accession number can appear on 39 different items. item_id is the one number that never repeats and never changes. Every search result, every link in the cataloging app, and every edit record points back to this number.
Source Schema
VRA Core 4 (a widely used description standard for visual materials developed by the Visual Resources Association) recommends that every item get a locally assigned unique identifier. The idea is simple: when two systems — say, your cataloging database and a regional digital portal — need to talk about the same photograph, they need a shared number that means the same thing to both. This field provides that anchor.
PastPerfect
PastPerfect’s equivalent field is called Object ID#, and PastPerfect assigns its own numbers automatically — they will not match HCHS’s item_id numbers. When we import our records into PastPerfect, we will need a translation table that connects each HCHS item_id to the number PastPerfect assigns it. Think of it as a cheat sheet that lets the two systems recognize the same photograph.
|
accession_no |
VRA Core 4 — work.refid (accession context); local YYYY.NNN.NNNNN convention |
Accession# |
Main screen |
Our Field
The accession number records the gift event — a single number that groups everything received from a donor in one donation. About 97% of HCHS accession numbers follow the pattern year.sequence.item (for example, 1998.012.00143). Knowing which accession an item came from is essential for donor relations, for pulling a group of related items off the shelf, and for collection-level research (‘show me everything from the 1998 McMurtrie donation’).
Source Schema
Standard cataloging practice distinguishes between the item identifier (which is unique to one photograph) and the accession number (which is shared by every photograph in the same donation batch). This mirrors how archives actually work: a donor brings in a box, that box gets an accession number, and every item inside that box gets the same accession number along with its own item number. Keeping the two separate lets you answer both ‘where does this specific photo go?’ and ‘what else came in with it?’
PastPerfect
PastPerfect’s Accession# field on the main catalog screen maps directly to this field — no translation needed. PastPerfect uses the accession number to link individual catalog records back to the donor record in its Accessions module. Multiple photographs can share the same accession number in PastPerfect, which matches how HCHS data is structured.
|
legacy_accession_no |
Local (pre-2026 crosswalk identifier) |
Old# |
Main screen |
Our Field
Before HCHS adopted the current numbering system, items were given shorter, simpler accession numbers (for example, 1977.21 or 1994.25.04). Those old numbers appear on physical labels attached to items, in donor correspondence, and in older finding aids and publications. If someone looks up a photograph by its old number — the one written on the back of the print — we need to be able to find it. This field keeps the old number alive as an ‘also known as’ reference.
Source Schema
Whenever an institution changes its numbering system, a translation field for the old numbers is standard practice. The old number is not the active identifier — we do not use it for anything new — but it provides a permanent bridge between the past and the present. Without it, any publication or finding aid that cited the old number becomes a dead end.
PastPerfect
PastPerfect has a dedicated Old# field on the main catalog screen built specifically for this purpose — storing a predecessor number from a previous system. This is an exact match for what we need, requiring no workaround or custom field.
|
series_code |
Local organizational code (A, B, D, MU…) |
Other# or custom field |
Main screen
41.7% filled; internal HCHS code |
Our Field
Long before the current accession numbering system, HCHS organized its catalog into named series identified by letter codes — A, B, D, MU, and others. These codes appear on about 41% of records and still mean something to staff who know the collection. Even though the codes are internal shorthand that outsiders would not understand, they have real value for sorting and browsing, and we preserve them so that knowledge is not lost.
Source Schema
Historical collections often have internal filing codes that predate modern cataloging standards. These codes represent organizational decisions that made sense at the time and that long-time staff rely on. Good metadata design makes room for these local codes rather than throwing them away — they carry institutional memory even when they do not follow any outside standard.
PastPerfect
PastPerfect’s Other# field on the main screen is designed for additional identifying codes that do not fit its primary identifier fields. The series code can go there, or HCHS can create a custom field with a clear label like ‘Series Code’ to make it self-explanatory to anyone who looks at the record. If using Other#, document what it contains in your PastPerfect setup notes.
|
item_number |
Local (two-part subseries.item-variant) |
Other# or custom field |
Main screen
41.7% filled |
Our Field
The item number is a two-part code (for example, 3.2a) that places an item within its series — a subseries number, an item number, and sometimes a variant letter. Like the series code, it appears in about 41% of records and encodes how the collection was physically organized before the current numbering system. We keep it because it appears on physical labels and in internal finding aids, and discarding it would strand staff who still use it for retrieval.
Source Schema
Two-part local numbering systems are common in collections that were organized before modern cataloging standards existed. They often reflect physical arrangement — which shelf, which box, which position in a run. Preserving them in the record is an acknowledgment that the way an institution organized its collection is itself historical information worth keeping.
PastPerfect
Same approach as series_code: use PastPerfect’s Other# field or create a custom user-defined field. If you need to store both the series code and the item number in PastPerfect and Other# can only hold one, put one in Other# and create a custom field for the other — or combine them with a clear separator (e.g., ‘B / 3.2a’) and note the format in your documentation.
|
item_number_parsed |
Local (derived/normalized app key; do not edit) |
Object ID# (app natural key; same reconciliation as item_id) |
Main screen
System-derived; never manually edited |
Our Field
This is the cleaned-up version of the item number that the cataloging application uses internally to look things up. The software needs a version of the item number that is always formatted the same way — no extra spaces, no inconsistent punctuation — so it can reliably find the right record. This value is generated automatically and must never be changed by hand; editing it would break every link in the app that points to this item.
Source Schema
Behind every user-friendly catalog display there is an internal lookup key the software actually uses to find records. That key needs to be perfectly consistent — even a small formatting difference causes the software to fail. This field is that internal key. It is not a cataloging decision; it is a technical requirement of the application.
PastPerfect
Like item_id, this field conceptually lines up with PastPerfect’s Object ID# — the number PastPerfect uses internally to find a record. But PastPerfect assigns its own numbers, so a translation step is needed at import to connect what HCHS uses internally to what PastPerfect uses.
|
side |
Local structural field; PREMIS objectCharacteristics context |
Custom field required |
User-defined fields
PP has no native recto/verso field; Relations subscreen handles linking |
Our Field
Many photographs have two sides — the image on the front and markings on the back. The back (verso) of a photograph is often where the most useful information lives: a studio stamp, a handwritten name, a penciled date, a family note. The source spreadsheet has 2,093 back-of-photograph images. This field simply marks whether a scanned image is the front or the back of a two-sided item, so the software can display them as a pair and researchers can flip between them.
Source Schema
Archival and library practice has long recognized that a two-sided item — a photograph, a manuscript page, a document — may need two separate images, and those images need to be labeled so a viewer knows which is which. The front/back distinction is a structural description: it is not about what the image depicts, but about how it physically relates to another image of the same object.
PastPerfect
PastPerfect does not have a built-in front/back field for photographs. Its Relations subscreen lets you link two records together, but it cannot label which one is the front and which is the back. A custom user-defined field (for example, ‘Side’ with values ‘front’ and ‘back’) is the practical solution for storing this information in PastPerfect.
|
related_item_id |
VRA Core 4 — relation element; PREMIS linkingObjectIdentifier |
Relations subscreen |
Relations subscreen
PP Relations links records; field stays in HCHS DB as primary |
Our Field
When an image is the back of a photograph, or a close-up detail of a larger image, or one of several images in a set, it needs to be explicitly linked to the item it belongs with. Without that link, staff can only guess at the relationship from a shared accession number or similar item numbers — and guesses break down when numbering is inconsistent. This field stores the item_id of the related photograph, making the connection a solid, searchable fact.
Source Schema
Description standards for visual materials include a specific mechanism for recording that two items are related to each other — not just that they share an accession number, but that one is the back of the other, one is a detail of the other, or one is a copy of the other. This field carries the ID of the related item so the connection is explicit and the software can act on it — for example, showing a ‘view back of photo’ button.
PastPerfect
PastPerfect has a Relations subscreen that lets you link two catalog records together so staff can navigate from one to the other. That is the closest equivalent. The link itself will be maintained in the HCHS database, and PastPerfect’s Relations screen provides the navigable connection for anyone working in PastPerfect.
|
relationship_type |
VRA Core 4 — relation@type attribute |
HCHS DB only |
N/A
No PP equivalent; relationship type managed in HCHS system |
Our Field
Knowing that two photographs are related is not enough — you need to know how. Is one the back of the other? A close-up detail? A copy? One image in a sequence? This field specifies the type of relationship using a short list of approved labels (for example, ‘is back of,’ ‘is detail of,’ ‘is copy of,’ ‘is part of sequence’). That label is what tells the software whether to show a ‘flip to back’ button, a ‘see full image’ link, or a ‘next in series’ arrow.
Source Schema
Cataloging standards for visual materials distinguish between different kinds of relationships between items because they serve different purposes for researchers and for software. A copy relationship tells a researcher that this may be a reproduction of something held elsewhere; a front/back relationship tells the software how to display the pair. Without specifying the type, ‘these items are related’ is noted but not actionable.
PastPerfect
PastPerfect’s Relations subscreen accepts free-text notes about how two records are related, but it does not have structured relationship type labels that software can act on. This field stays in the HCHS database and drives the cataloging app’s navigation features. No PastPerfect equivalent is needed.
|
sequence_no |
Local structural ordering; VRA Core 4 relation.rank context |
Other# or custom field |
Main screen
Only relevant for known ordered series |
Our Field
When several photographs belong together in a known order — pages of a photo album, a survey of a building shot room by room, a series of portraits taken at the same session — this field records where each one falls in that sequence: 1, 2, 3, and so on. Without it, the software has to guess the order from item numbers or dates, which is often wrong for items originally arranged by a cataloger’s judgment. This field is optional and blank for most items; it is only filled in when the correct order is actually known.
Source Schema
Visual resource standards recognize that groups of related images often have a meaningful order that is separate from their catalog numbers. The position of an image within its group — first, third, last — is a structural fact about how the set was originally organized, not something that can be reliably inferred from identifiers or dates.
PastPerfect
PastPerfect has no dedicated sequence number field. For ordered sets, institutions typically write the position into the title or description (for example, ‘Image 3 of 12’) or use the Other# field. A custom user-defined field labeled ‘Sequence’ is a cleaner option. Since most HCHS items will not have a sequence number, this gap in PastPerfect has limited practical impact.
|
title |
VRA Core 4 — titleSet/title; CCO title construction rules |
Title |
Main screen
PP distinguishes Title from Description — same distinction as the target model |
Our Field
The current spreadsheet has no separate title field — one field is doing double duty as both a name for the item and a description of what it shows. We separate them because they serve different purposes: a title is the brief name that appears in search results, lists, and citations (‘Portrait of an unidentified woman, circa 1880’); a description is the fuller explanation of what the image contains. Most HCHS photographs were never given a formal title by their maker, so we construct a short descriptive title — which is exactly what professional cataloging practice recommends in this situation.
Source Schema
Cataloging standards for visual materials (including CCO, Cataloging Cultural Objects, a widely used content standard for describing images and artifacts) distinguish between a title and a description because they are used differently. A title needs to be brief and distinctive enough to identify an item at a glance. A description needs to be detailed enough to tell a researcher what the image actually shows. Using one field for both purposes means neither job gets done well.
PastPerfect
PastPerfect has a separate Title field and Description field on its main catalog screen — it is already set up to keep these distinct. Our title goes in Title; our descriptive text goes in Description. The fact that PastPerfect uses this same separation confirms it is the right structure.
|
description |
VRA Core 4 — descriptionSet/description; CCO scope note rules |
Description |
Main screen |
Our Field
The source spreadsheet has two description columns: a richer archival description (about 34% filled) and a shorter cleaned-up display description (about 99% filled). We merge these into one authoritative description field, giving priority to the richer version where it exists. Description is what a researcher actually reads to understand what they are looking at — it is the most important text field for visual materials because you cannot search a photograph the way you search a document.
Source Schema
Professional cataloging guidance specifies that a description of a visual item should be written in complete sentences, move from the general to the specific, and clearly distinguish what is actually visible in the image from what is being inferred or guessed. This matters because a researcher reading the description needs to know whether ‘this appears to be the Huntingdon Borough Hall’ is something the cataloger is certain about or only suspects.
PastPerfect
PastPerfect’s Description field on the main catalog screen accepts unlimited text, making it the right home for full descriptive prose. PastPerfect Online’s search indexes this field, so a well-written description directly makes items easier to find through keyword searches.
|
creator |
VRA Core 4 — agentSet/agent; CCO creator rules; LCNAF |
Photographer / Studio |
Main screen
PP has two separate fields: Photographer (individual) and Studio (corporate creator) |
Our Field
Creator is the photographer or studio that made the original photograph. Currently only 7.6% of records have this filled in — a significant gap worth closing over time. Knowing the creator matters because it is a key way researchers browse collections: ‘show me everything taken by Kline Studios’ or ‘find all photographs attributed to H.M. Eby.’ Some records will have an individual photographer’s name; others will have a studio name; some may have both.
Source Schema
Cataloging standards distinguish between an individual photographer and a commercial studio because they have different research implications and different name formats. For individuals, the standard format is Last Name, First Name. For uncertain attributions — where we think we know who took the photograph but are not sure — the entry should say ‘attributed to’ or ‘possibly’ to avoid stating a guess as a fact. Professional standards are explicit about this because false certainty in a catalog misleads researchers.
PastPerfect
PastPerfect’s Photos catalog has two separate fields on the main screen: Photographer for individual photographers and Studio for photography studios or other organizations. This matches the way our data is organized. Both fields are connected to PastPerfect’s built-in people name list, which helps keep name spellings consistent across all records.
|
date_created |
VRA Core 4 — dateSet/date; EDTF Level 1 |
Year Range (Earliest / Latest) |
Main screen
PP has two year fields for ranges; EDTF normalized form maps to these |
Our Field
The date a photograph was taken is essential for browsing collections chronologically, for contextual research (‘what was happening in Huntingdon County in 1905?’), and for determining copyright (photographs taken before 1928 are generally in the public domain in the United States). Our source spreadsheet has three different date columns that are inconsistently formatted. This field stores the date in a standardized format that computers can sort and filter reliably, even when the date is approximate or expressed as a range.
Source Schema
We use a standard called EDTF (Extended Date/Time Format, an international standard for expressing uncertain dates) to record dates like ‘approximately 1880’ or ‘between 1880 and 1890’ in a way the software can understand and sort correctly. A date written as ‘circa 1880’ means different things to different people; the EDTF version (~1880) means exactly the same thing to every system that understands the standard. This is the machine-readable version; a human-friendly version is kept separately.
PastPerfect
PastPerfect stores date ranges using two separate fields on the main screen: Earliest Year and Latest Year. For an exact year, both fields get the same number. For a range (1880 to 1890), Earliest gets 1880 and Latest gets 1890. PastPerfect does not understand the EDTF standard notation directly; the standardized form stays in the HCHS database, and the human-friendly display date goes into PastPerfect’s Date field.
|
date_created_display |
VRA Core 4 — date@dataDate display companion; CCO date display rules |
Date |
Main screen |
Our Field
The machine-readable date in the previous field (~1880) is precise for software but awkward for people to read. This field holds the human-friendly version that appears in the catalog display — ‘circa 1880,’ ‘July 1884,’ ‘ca. 1910–1920.’ Both versions are needed: the machine-readable one for sorting and searching; the display version for what researchers actually see. The source spreadsheet’s ‘Date (display)’ column feeds this field.
Source Schema
Cataloging standards acknowledge that the format best suited for computer processing and the format best suited for human reading are often different for dates. The machine needs a consistent, parseable format. The researcher needs a format that honestly communicates what is known — ‘circa’ signals an estimate; ‘July 1884’ signals precision. Both are correct; they just serve different audiences.
PastPerfect
PastPerfect’s Date field on the main catalog screen is a free-text field for the human-readable date. This is where ‘circa 1880’ or ‘July 1884’ goes. PastPerfect users see this field in catalog records and reports. It works alongside the Earliest Year and Latest Year fields, which drive date-range searching.
|
subject_topical |
LCSH / TGM (Thesaurus for Graphical Materials); VRA Core 4 — subjectSet/subject |
Subject |
People, Subjects, Classification subscreen
PP’s Subject field is controlled by its own authority file; TGM terms map directly |
Our Field
Subject terms let researchers find photographs by what they show — ‘floods,’ ‘iron furnaces,’ ‘street scenes,’ ‘portraits.’ The existing Subject column (38% filled) is not reliable because it mixes topical subjects, people’s names, place names, and notes like ‘MISSING’ and ‘no info’ all in one field. The target model gives each type its own field and uses a standardized list of approved subject terms so that ‘Flood’ and ‘floods’ and ‘1936 Flood’ all point to the same subject and return the same results.
Source Schema
The Library of Congress maintains a standardized list of approved terms specifically designed for describing what appears in photographs and other visual materials, called the Thesaurus for Graphical Materials (TGM). Using a standardized list means every cataloger uses the same term for the same concept — one cataloger does not write ‘flood’ while another writes ‘floods’ and a third writes ‘inundation.’ Consistent terms produce complete search results.
PastPerfect
PastPerfect has a Subject field on the People/Subjects subscreen that is connected to its own built-in list of approved subject terms. When set up to use the Library of Congress photographic materials list, PastPerfect can check entries against it. This field accepts multiple terms. PastPerfect Online searches it, so good subject terms directly improve how easily the public can find items.
|
subject_person |
VRA Core 4 — subjectSet/subject with person type; LCNAF |
People |
People, Subjects, Classification subscreen
PP has a dedicated People field separate from Subject |
Our Field
For a county historical society, ‘who is in this photograph?’ is often the first question a researcher asks. Genealogists make up a large part of historical society visitors, and they need to search by person name, not by general subject term. Right now, person names are mixed into the general subject field alongside topics and places, making name searches unreliable. Giving people their own dedicated field means a search for ‘Miller, John’ returns only records where John Miller actually appears — not every record that has the word ‘Miller’ anywhere.
Source Schema
People, places, and topics are three different kinds of subjects, and they work differently for research. A person name needs a standard form (Last Name, First Name, birth and death years if known) that keeps different people with the same name from being confused. The Library of Congress maintains a master list of standard name forms (called LCNAF, the Library of Congress Name Authority File) for known individuals and organizations. For local figures not on that national list, HCHS maintains its own local name list to achieve the same consistency.
PastPerfect
PastPerfect has a dedicated People field on the People/Subjects subscreen that is separate from the topical Subject field. This matches our separation of person names from topics. PastPerfect’s built-in people name list helps keep name spellings consistent. PastPerfect Online searches the People field independently, so genealogical name searches work correctly.
|
subject_place |
VRA Core 4 — locationSet/location (subject); Getty TGN |
Place |
Main screen
‘Place’ in PP = geographic subject (where depicted), NOT storage location |
Our Field
Where a photograph was taken is one of the most important search dimensions for a county historical society. A researcher studying Huntingdon Borough needs every photograph that shows Huntingdon Borough, not a mix of results from across the county. The existing geographic subject field is about 24.6% filled, and inconsistent — ‘Juniata Tp.’ and ‘Juniata Township’ and ‘Juniata Twp.’ all mean the same place but return different search results. Using a standardized list of approved place names fixes this and allows browsing from the county level down to the street level.
Source Schema
Getty Research Institute maintains a hierarchical reference list of place names (the Getty Thesaurus of Geographic Names, or TGN) that includes preferred name forms, variant spellings, and geographic hierarchy — so that ‘Huntingdon Borough’ is understood to be in Huntingdon County, which is in Pennsylvania, which is in the United States. This hierarchy lets a researcher search at any level and get consistent results.
PastPerfect
PastPerfect has a Place field on the main catalog screen for recording where a photograph was taken or what place it shows. This is completely separate from the Location subscreen, which records where the physical artifact is stored on a shelf or in a box. Subject place (what the photo shows) maps to the Place field; physical storage location maps to Home Location. The two are easy to confuse by name — document this distinction clearly for your staff.
|
collection |
VRA Core 4 — work.source; DACS collection-level context; local authority |
Collection |
Main screen
Direct mapping; PP Collection field is controlled by authority file |
Our Field
Collection is the named group an item belongs to — the McMurtrie Family collection, the National Register collection, and so on. There are 44 distinct collection names in the data, and this is the main way staff and researchers navigate the catalog. It is the answer to ‘where does this photograph live in the broader organization of the collection?’ This field is 100% filled and already consistent — one of the strongest fields in the existing data.
Source Schema
Archival practice organizes materials at several levels, and the collection is the top level — the broadest named grouping. It usually corresponds to a donor or a major theme: everything from a single family’s donation is one collection; everything assembled on a particular subject is another. Collection names tell a researcher which part of the archive to focus on and often signal whose perspective the materials represent.
PastPerfect
PastPerfect has a Collection field on the main catalog screen that maps directly to this field — no workaround needed. PastPerfect maintains a list of approved collection names to keep them consistent across all records. PastPerfect Online lets the public browse and filter by collection, making this field directly useful for discovery.
|
category |
Local controlled vocabulary; People/Subjects Classification context |
Classification |
People, Subjects, Classification subscreen
PP’s Classification field on the People/Subjects subscreen is the closest match |
Our Field
Category is a thematic grouping within a collection — Buildings, Portraits, Districts, Historic Markers, and so on. There are 1,202 distinct category values in the data, and 99.8% of records have one. It is the main secondary browse dimension: after a researcher picks a collection, they use category to narrow down. These categories are HCHS’s own terms, not taken from an outside list, but they are applied consistently and provide real organizational value.
Source Schema
Every institution organizes its collections in ways that make sense for its own materials and its own audience. A general-purpose national standard cannot anticipate every local grouping. Cataloging practice accommodates this by providing a ‘classification’ field for institutions to use with their own approved terms — with the expectation that the terms are applied consistently and managed, not left to each cataloger’s invention.
PastPerfect
PastPerfect has a Classification field on the People/Subjects subscreen that is designed for this kind of local thematic grouping. PastPerfect can maintain a list of approved category terms to prevent inconsistency over time. This field is available in PastPerfect Online browsing.
|
subcategory |
Local controlled vocabulary (extension of category) |
Custom field required |
User-defined fields
PP has no second-level classification field; custom field needed |
Our Field
Subcategory is a more specific grouping below the main category — only about 12% of records have one, and the values are longer descriptive phrases. Where it exists it adds useful context (‘Buildings’ becomes ‘Buildings: Commercial’ or ‘Buildings: Residential’). We keep it as an optional field. The goal is to gradually build a consistent list of subcategory terms rather than leaving it as free-form text that each cataloger writes differently.
Source Schema
A two-level classification system (broad category plus a narrower subcategory) is a practical way to add specificity without requiring a whole new set of browse filters. The subcategory narrows an existing category rather than introducing a new dimension. Standards accommodate this as a second tier in a classification scheme — useful where the data justifies it, optional where it does not.
PastPerfect
PastPerfect does not have a built-in subcategory field. If HCHS wants to store subcategory values in PastPerfect, a custom user-defined field is the solution. A simpler alternative is to combine category and subcategory in the Classification field using a separator, for example ‘Buildings: Commercial’ — easier to set up but harder to filter on later.
|
format_medium |
VRA Core 4 — materialSet/material; Getty AAT |
Object Name / Processing Method |
Main screen
PP uses two fields: Object Name (format type) and Processing Method (photographic process) |
Our Field
Format and medium records what kind of physical object the original is — a standard photograph, a glass plate negative, a daguerreotype, a postcard, a carte de visite, and so on. This field is well-filled (92.4%) with only 8 consistent values, making it one of the most reliable fields in the existing data. It matters for physical handling (glass plates require special care), for conservation planning, for knowing what equipment is needed to digitize an item, and for researchers who study specific historical photographic processes.
Source Schema
Getty Research Institute maintains a comprehensive reference list of art and material culture terms (called the Art & Architecture Thesaurus, or AAT) that includes detailed terms for photographic processes and formats. Using Getty AAT terms means ‘daguerreotype’ means the same thing at HCHS as it does at every other institution that uses the same list, making it possible for researchers to search across multiple collections for photographs made by the same process.
PastPerfect
PastPerfect’s Photos catalog uses two fields for this information: Object Name on the main screen (the broad type — ‘Photograph’) and Processing Method (the specific process — ‘Daguerreotype’ or ‘Wet plate glass’). Both are connected to PastPerfect’s built-in term lists. A daguerreotype goes in Processing Method; ‘Photograph’ goes in Object Name.
|
dimensions |
VRA Core 4 — measurementsSet/measurements; CCO dimensions rules |
Print Size / Dimension Details |
Main screen
PP has a Print Size lexicon field plus free-text Dimension Details |
Our Field
The physical size of the original artifact — height and width — matters for physical retrieval (what size housing does this need?), conservation (what size mat or mount?), and for research (some photographic formats were made in standardized sizes, so a size that does not match the standard tells you something). The existing Dimensions column is only 10% filled and inconsistently formatted. For new records we record dimensions as height × width in centimeters.
Source Schema
Professional cataloging practice specifies that dimensions should always be entered in the same order (height first, then width) and in the same unit (centimeters preferred). Consistent formatting lets you search for items of a specific size and lets researchers identify whether two photographs might have come from the same negative based on matching dimensions.
PastPerfect
PastPerfect has two fields for size on the main screen: Print Size (a list of standard photographic sizes like 4×6 or 8×10) and Dimension Details (a free-text field for anything that does not fit the standard list). Standard formats go in Print Size; measurements in centimeters go in Dimension Details.
|
notes |
VRA Core 4 — descriptionSet/description (notes type); D/AP pillar |
Notes |
Notes & Legal subscreen
Catch-all for unstructured content that doesn’t fit other fields |
Our Field
Notes is a catch-all for information that does not fit neatly into any other field — a cataloger’s observation about condition, a note that the item was displayed at a specific exhibition, a question about who appears in the photograph. The source spreadsheet’s Notes column is only 7.6% filled but the content that is there is genuine. The target model keeps this field but treats it as a last resort: any information that could go into a structured field should go there instead, so the notes field stays focused and useful.
Source Schema
Every catalog needs a free-text field for information that does not fit the structured fields — that is a given. The professional standard is that notes should hold only genuinely unstructured observations. If a piece of information could go into a dedicated field (a rights statement, a donor name, a subject term), it should go there. Using the notes field as a dumping ground for everything makes it impossible to search reliably.
PastPerfect
PastPerfect has a Notes field on the Notes & Legal subscreen — a free-text memo field for unstructured information. PastPerfect Online can search Notes content. This is also where donor restrictions are often recorded in PastPerfect when no dedicated restriction field is available. Keeping Notes focused — not using it for information that belongs in other fields — improves catalog quality over time.
|
digital_format |
PREMIS objectCharacteristics/format; IANA media type / PRONOM |
Custom field required |
User-defined fields
PP does not have a native digital format field; technical metadata lives in HCHS DB |
Our Field
Digital format records what kind of file the scan is — JPEG, TIFF, PDF, and so on. This field is 100% filled in the source data. It matters for long-term planning: TIFF files are archival quality and do not lose detail when saved; JPEG files lose a small amount of quality each time they are saved, making them better suited for access copies than for long-term preservation. Knowing the format lets administrators decide whether any files need to be upgraded to a better format before the originals deteriorate further.
Source Schema
A widely used digital preservation standard called PREMIS (Preservation Metadata: Implementation Strategies) identifies the file format as one of the most important technical facts to record about a digital file. The reason is practical: a file is useless if the software needed to open it no longer exists. Recording the format now ensures that future administrators know what they have and can plan accordingly if a format becomes obsolete.
PastPerfect
PastPerfect’s MultiMedia module links digital files to catalog records, but PastPerfect does not have a dedicated field for recording the file format in its Photos catalog. This information is most useful in the HCHS database for technical management. If it needs to appear in PastPerfect, a custom user-defined field is the way to add it.
|
file_size |
PREMIS objectCharacteristics/size |
Custom field required |
User-defined fields
100% filled in source data; stored in HCHS DB primarily |
Our Field
File size — how many bytes a digital file takes up — is a simple technical fact that is 100% filled in our source data. It serves several practical purposes: storage planning (how much space do we need to keep all our scans?), identifying suspiciously small files that might be thumbnail previews instead of full scans, and as an early warning signal — if a file’s recorded size suddenly changes, something may have gone wrong with the file.
Source Schema
Digital preservation practice records file size as a basic fact about a digital file at the time it was captured. File size alone cannot prove a file has not been altered — two different files could happen to be the same size — but an unexpected change in size is a reliable warning that something happened to the file. For a volunteer-run organization, tracking file size is a lightweight and practical way to catch file problems without the complexity of full cryptographic file verification.
PastPerfect
PastPerfect does not have a native file size field, and the practical value of displaying file size in PastPerfect is low. File size is managed in the HCHS database for technical use. It is not recommended to export it to PastPerfect unless there is a specific reason to do so.
|
digital_filename |
PREMIS originalName; local technical reference |
Media File (via MultiMedia module) |
MultiMedia subscreen
PP links files by path via MultiMedia; filename is implicit in the linked path |
Our Field
The digital filename — what the file is actually called in Google Drive — is the basic reference staff use to locate a scan. It is 100% filled in the source data. Right now, before full PastPerfect integration, it is the primary way to connect a catalog record to its image: you look up the record, find the filename, and search for that file in Drive. HCHS filenames also encode useful information — many include the accession number and a brief description.
Source Schema
Digital preservation practice recommends recording the original filename assigned to a file because filenames often carry information about the item and because they provide a stable reference if the file is later moved or copied to a new location. If you ever need to find a file that has been moved, the original filename is one of the best clues you have.
PastPerfect
PastPerfect links digital files to catalog records through its MultiMedia subscreen, where you attach a file by its path. The filename is part of that path rather than stored separately. Once HCHS links files to PastPerfect records through the MultiMedia module, staff will be able to open images directly from within PastPerfect. The filename field in the HCHS database serves as a reference in the meantime.
|
digital_file_path |
PREMIS storage/contentLocation; local technical reference |
HCHS DB only |
N/A
Full Drive path; useful for HCHS system, not exported to PP |
Our Field
The full Google Drive path — the complete chain of folders from the top level down to the file — is how the cataloging app knows exactly where to find an image. It is 100% populated in the source data. This is a technical reference for the current storage setup; if HCHS reorganizes its Drive folder structure or moves files to a different storage system, this field will need to be updated to match.
Source Schema
Digital preservation practice calls for recording where a file actually lives in storage — its address in the system — so that the file can be retrieved later, verified, or moved to a new location during a migration. For HCHS right now, that address is a Google Drive file path. This is the ‘where is it?’ field for the current infrastructure.
PastPerfect
The Google Drive file path is a technical reference specific to HCHS’s current storage setup and is not exported to PastPerfect. PastPerfect uses its own MultiMedia module to link files to catalog records. This field stays in the HCHS database only and will likely be superseded if HCHS moves to a different file storage system.
|
digital_object_id |
PREMIS objectIdentifier; Google Drive file ID |
Other# or custom field |
Main screen
Google Drive file ID; drives the thumbnail proxy in the curation app |
Our Field
Every file in Google Drive has a unique ID number that Google assigns and that never changes, even if the file is renamed or moved to a different folder. The cataloging app uses this ID to fetch the image for display — it is more reliable than using the filename or folder path, which can change. This field is 100% populated in the source data. If HCHS ever needs to reconnect catalog records to their image files after a reorganization, the Drive ID is the safest way to do it.
Source Schema
Digital preservation practice recommends recording a stable, permanent identifier for each digital file — not just its current filename or location, both of which can change. Google Drive’s file ID is that stable identifier for our current storage. Recording it now means that if files are ever moved, renamed, or migrated, we have a reliable reference to reconnect catalog records to their images.
PastPerfect
PastPerfect does not have a dedicated field for a Google Drive file ID. The Other# field on the main screen or a custom user-defined field can hold this value. If HCHS later links PastPerfect records to Drive images through the MultiMedia module, the Drive ID provides the stable reference needed to build those connections.
|
drive_folder_path |
Local technical reference (Drive folder hierarchy) |
HCHS DB only |
N/A
Drive folder hierarchy (levels 1–5); internal use only |
Our Field
The Drive folder path records how the image files are organized in Google Drive — the sequence of folders from the top level down to where each file lives. This is useful for batch operations (moving or renaming a group of files at once) and for troubleshooting when a file is missing or misplaced. It is assembled from the Drive Folder 1 through Folder 5 columns in the source spreadsheet. This is a technical reference, not a descriptive field.
Source Schema
Recording how files are organized in storage is a practical preservation measure: it captures the logic that whoever set up the Drive structure had in mind. There is no formal standard that governs this because every institution’s storage is different. For HCHS’s Google Drive setup, the folder hierarchy is the map of the digital collection, and recording it now ensures that organizational logic is not lost if the person who created the structure is no longer available.
PastPerfect
The Drive folder path is an internal technical reference specific to the HCHS database and does not map to any PastPerfect field. It stays in the HCHS database only. If files are ever migrated from Google Drive to a different storage system, the recorded folder path provides context for understanding how the collection was originally organized.
|
date_digitized |
PREMIS creationEvent/eventDateTime; DCMI Terms created |
Custom field required |
User-defined fields
PP has Catalog Date (when record was entered) but no separate digitization date |
Our Field
The date an item was scanned is a new field — there is no existing data for any of the 22,811 current records. We record it going forward because it answers two important questions: When was this scan made (which tells us what scanning technology was available at the time, and helps explain image quality)? And who scanned it on that date (which only means something if we know when it happened)? Fill this field for every new scan from now on.
Source Schema
Digital preservation standards treat the act of digitization — converting a physical object to a digital file — as an event worth recording, with a date, a person responsible, and a description of what was done. The date is the foundation: without it, knowing who scanned something and what equipment was used has no chronological anchor. These fields together create a basic history of how the digital collection was built.
PastPerfect
PastPerfect’s Catalog Date field records when a catalog record was entered into PastPerfect — not when the physical item was scanned. These are two different events. PastPerfect has no dedicated scanning date field. A custom user-defined field labeled ‘Date Digitized’ is the recommended approach, and labeling it clearly prevents confusion with Catalog Date.
|
digitizer |
PREMIS creationEvent/linkingAgentIdentifier (type: creator); VRA Core 4 agent |
Custom field required |
User-defined fields
No native PP scanner-credit field; custom field or Source subscreen note |
Our Field
Who did the scanning? Right now, this field is completely empty — there is no record in the existing data of who scanned any of the 22,811 items. This matters for accountability (if a scan is low quality, who do we talk to?), for training (if a particular volunteer’s scans consistently need to be redone, that is useful to know), and for institutional memory (volunteers who contribute hundreds of hours of scanning deserve to be credited). We cannot realistically fill this in for past scans without scanning logs, but we should record it for every new scan going forward.
Source Schema
Digital preservation standards distinguish between the original artifact and the digital scan, and recognize that someone is responsible for creating that scan. Recording who made the scan creates accountability — it turns an anonymous digital file into a documented act performed by a named person on a known date. This matters especially when many different volunteers are contributing to a digitization project.
PastPerfect
PastPerfect does not have a native field for scanner credit. The Source field on the Source subscreen is for who donated the item, not who scanned it — do not use it for this purpose. A custom user-defined field labeled ‘Digitizer’ or ‘Scanned by’ is the right approach. If creating custom fields is not practical, a clearly labeled note in the Source subscreen’s Notes field is the fallback.
|
scanning_equipment |
PREMIS creationEvent/eventDetail (equipment context); local technical |
Custom field required |
User-defined fields
Optional; record going forward; backfill not realistic |
Our Field
Scanning equipment records what scanner was used — make and model. A consumer flatbed scanner produces a different result than a professional overhead scanner or a specialized slide/negative scanner. Knowing what equipment was used helps administrators decide whether a particular batch of scans is good enough or whether the items should be rescanned with better equipment, and helps explain image characteristics that might be scanner artifacts rather than features of the original photograph. This field is optional and will be empty for most existing records.
Source Schema
Digital preservation standards recognize that knowing the equipment used to create a digital file is useful secondary context — the ‘with what’ that goes alongside ‘who’ and ‘when.’ It is less critical than recording the date and the person, but it adds precision. In a lightweight approach appropriate for a volunteer-run organization, a simple make-and-model text entry is sufficient — no need for the more complex structured records that enterprise systems use.
PastPerfect
PastPerfect has no native scanning equipment field. A custom user-defined field is the only option. Given that this field will be empty for most records, HCHS may reasonably decide to keep this information in the HCHS database only and not add a custom field in PastPerfect for it.
|
missing_flag |
Local technical status; PREMIS objectCharacteristics context |
Status (via ‘Missing’ value) |
Main screen
PP uses Status field for Missing; 163 items currently flagged |
Our Field
The missing flag marks items where the scan cannot be found in Google Drive — 163 records (about 0.6% of the collection) are flagged this way. When a file is missing, the cataloging app cannot show the image, and the item cannot be nominated for the 250 portal until the file is found or the item is rescanned. Tracking this explicitly lets administrators pull a list of all missing files at any time and prioritize recovery efforts.
Source Schema
Digital preservation monitoring includes checking that files are actually accessible — not just that a catalog record says they should exist. Recording ‘this file cannot be found’ as an explicit flag, rather than silently failing to display anything, makes the problem visible and actionable. It is a practical, lightweight version of the kind of file integrity monitoring that large digital archives perform automatically.
PastPerfect
PastPerfect handles this through the Status field on the main catalog screen, which includes ‘Missing’ as one of its approved values. When HCHS records are imported to PastPerfect, items with the missing flag set should receive Status=’Missing’ in PastPerfect.
|
item_status |
Local controlled vocabulary; PREMIS objectCharacteristics context |
Status |
Main screen
PP Status field is controlled by authority file; 5 source values map cleanly |
Our Field
Item status records the current state of an item — whether it is active and usable, whether its file is missing, whether no physical print is available, or whether it needs more descriptive work before it is ready for the public. This field is 100% filled and drives filtering in the cataloging app: curators can filter out missing items, and staff can pull a list of everything that still needs a description written. The values are HCHS’s own terms but are applied consistently.
Source Schema
A status field serves two purposes at once: it tracks the cataloging state of the record (is this fully described and ready?) and the technical state of the digital file (is this accessible?). Larger institutions typically have separate systems for these two things. For a small organization without a dedicated workflow system, a single combined status field is the practical choice — it gets the job done without the complexity.
PastPerfect
PastPerfect has a Status field on the main catalog screen controlled by its own list of approved status terms. The HCHS status values (Active, Missing, No Print, Active-Needs Description) map to PastPerfect’s terms, with ‘Active’ mapping to PastPerfect’s ‘Active’ or ‘Catalogued’ and ‘Missing’ mapping directly. ‘No Print’ may need to be added as a custom status term in PastPerfect’s settings.
|
copyright_status |
RightsStatements.org standardized statements; PREMIS rightsStatement |
Copyrights |
Notes & Legal subscreen
PP’s Copyrights field accepts rights text; RightsStatements.org URIs can be stored here |
Our Field
Before sharing any photograph publicly online, HCHS needs to know its copyright status. This field is currently empty for all 22,811 records — filling it in is one of the most important tasks for public access. Most HCHS photographs taken before 1928 are in the public domain in the United States. Most photographs from the twentieth century where the copyright holder is unknown fall into a ‘copyright undetermined’ category. We use a standard set of rights labels maintained at RightsStatements.org because they are recognized by major digital portals and are more precise than a handwritten note.
Source Schema
RightsStatements.org is a non-profit initiative maintained by digital heritage organizations that provides twelve standardized rights statements designed for cultural heritage institutions — covering situations ranging from ‘clearly in the public domain’ to ‘copyright is unclear’ to ‘in copyright, educational use permitted.’ Using these standard labels instead of custom text means that digital portals that aggregate content from many institutions (such as the Digital Public Library of America) can correctly display and filter items by rights status.
PastPerfect
PastPerfect’s Copyrights field on the Notes & Legal subscreen is a free-text field for rights information. It does not natively understand the RightsStatements.org labels, but you can enter them as text — for example, ‘No Copyright – United States: https://rightsstatements.org/vocab/NoC-US/1.0/’. PastPerfect Online does not currently filter search results by rights status, so this field primarily serves as a staff reference and as a source for export to aggregators that do recognize the standard labels.
|
credit_line |
Local institutional standard; DCMI Terms publisher context; CCO credit line rules |
Credit Line |
Source subscreen
Standard text; same value for every HCHS item |
Our Field
The credit line is the standard text that should appear whenever one of HCHS’s photographs is reproduced in a publication, a website, an exhibition, or a research report: ‘Huntingdon County Historical Society, Huntingdon, Pennsylvania.’ Every record should carry this text. It establishes institutional credit even for items that are in the public domain, ensures that HCHS gets recognized when its materials are used, and is the text that automatically appears in PastPerfect-generated labels and reports. Because it is the same text on every record, it can be applied to all 22,811 items at once without any individual research.
Source Schema
Professional cataloging practice distinguishes between copyright status (who legally owns the rights) and the credit line (what text should appear when the item is reproduced). A photograph can be in the public domain — meaning anyone can legally reproduce it — and still require a credit line, because credit is about acknowledging the institution that holds and preserves the original, not about legal ownership. Both are needed.
PastPerfect
PastPerfect has a dedicated Credit Line field on the Source subscreen built exactly for this purpose. It accepts the standard institutional text and automatically includes it in PastPerfect-generated labels, condition reports, and loan agreements. This is a direct match — no workaround needed.
|
donor_restrictions |
Local rights field; DACS conditions governing access context |
Notes (Notes & Legal subscreen) |
Notes & Legal subscreen
PP has no dedicated donor restrictions field; Notes subscreen is the fallback |
Our Field
Donor restrictions are conditions that a donor puts on how HCHS can use an item at the time of the gift — for example, ‘not for commercial reproduction,’ ‘do not display publicly without family approval,’ or ‘restricted for 25 years.’ These conditions can be more restrictive than copyright law, and they are legally binding through the deed of gift agreement. They must be recorded even when the restriction was communicated informally, because they affect every future decision about access and reproduction.
Source Schema
Archival description standards (including DACS, Describing Archives: A Content Standard, which is the professional standard for archival description in North America) specify that any restrictions on access or use should be stated precisely — not just ‘restricted by donor’ but what is restricted, under what conditions, and until when. Precise language lets staff make access decisions from the catalog record alone, without having to find and read the original donation paperwork every time.
PastPerfect
PastPerfect does not have a dedicated donor restrictions field in the Photos catalog. The Notes field on the Notes & Legal subscreen is the recommended location. Label each restriction clearly — for example, ‘Donor restriction: Not for commercial reproduction’ — so it stands out from general notes. Consistent labeling is essential so staff can recognize and act on restrictions when they appear.
|
reproduction_rights |
Local rights field; PREMIS rightsStatement (reproduction context) |
Copyrights |
Notes & Legal subscreen
Shares PP Copyrights field with copyright_status; label clearly |
Our Field
Reproduction rights answers a practical question: ‘Who do I ask permission from if I want to reproduce this photograph?’ HCHS holds the physical original but does not necessarily hold the copyright. For a photograph where the copyright belongs to the photographer’s estate, clearly noting ‘reproduction rights: Estate of [Name]’ prevents HCHS from accidentally giving permission it does not have to give. This field is separate from copyright status (which describes the legal situation) and from donor restrictions (which are gift-agreement terms).
Source Schema
Even when you know the copyright status of an item, you still need to know who to contact to actually get permission to reproduce it. Those are two different questions. Full rights documentation addresses both. For a practical implementation at a small institution, a brief free-text note naming the rights holder and any basic conditions is sufficient — detailed legal specifications are not needed.
PastPerfect
PastPerfect’s Copyrights field on the Notes & Legal subscreen can hold both copyright status and reproduction rights information in the same field. If both are present, label them clearly with separate lines — for example, ‘Copyright: Public domain’ on one line and ‘Reproduction rights: Estate of John Smith’ on the next — so staff can read both at a glance.
|
donor_provenance |
DACS immediate source of acquisition; VRA Core 4 sourceSet/source; LCNAF |
Source |
Source subscreen
PP Source field on Source subscreen; controlled by PP People Authority File |
Our Field
Donor provenance records who gave HCHS the original photograph or collection. Currently only 4.2% of records have this filled in, but where it is filled in the information is meaningful — James F. Sellers donated 308 items, EE Gibbs donated 468 glass photographs, and so on. Knowing who donated an item matters for donor relations, for stewardship (donors deserve to know their gift is being cared for), and for interpretation (a photograph donated by a professional studio has a different context than one donated by a local family). Many donations can be backfilled by looking at collection names and matching them to donor records.
Source Schema
Archival description standards (DACS, the professional standard in North America) specify that the immediate source of acquisition — who gave you the materials and roughly when — is one of the most important facts to record. It establishes the direct chain of ownership before the materials arrived at the institution. Donor names should be recorded consistently (Last Name, First Name for individuals; full organization name for institutions) so that all gifts from the same donor can be found together.
PastPerfect
PastPerfect’s Source subscreen has a dedicated Source field for recording the donor or acquisition source — a direct match for this field. PastPerfect’s built-in people name list keeps donor name spellings consistent across records. The Source subscreen also has a Source Date field for recording when the donation was made, which aligns with the archival practice of recording the approximate date of transfer.
|
custodial_history |
DACS custodial history (Element 5.1); PREMIS significantProperties context |
Provenance |
Source subscreen
PP has a dedicated Provenance field for ownership history narrative |
Our Field
Custodial history is the story of where an item has been before arriving at HCHS — who owned it before the donor, where it was stored, whether there were any intermediate transfers or changes of hands. This field will be empty for most items, and that is fine — it is optional. But for significant items the history is invaluable. A daguerreotype whose ownership history is traced from the original studio through three generations of a family to its donation to HCHS is a far richer historical document than an identical photograph with no recorded history.
Source Schema
Archival practice treats the history of an object’s ownership as part of its historical significance. An item’s history of custody can affect how we interpret its authenticity, its completeness, and its relationship to other materials that may have been separated from it along the way. This is not a structured field with specific data requirements — it is a narrative prose account of what is known, which varies greatly from item to item.
PastPerfect
PastPerfect’s Source subscreen includes a field called Provenance described as ‘detailed history of past ownership’ — a direct match for this field. It is a free-text memo field that accepts narrative prose of any length. This is the most precise PastPerfect match in the Source subscreen.
|
storage_location |
Local administrative field; DACS physical access context |
Home Location |
Location subscreen
‘Location’ in PP = physical storage, NOT geographic subject; entirely separate from PP ‘Place’ |
Our Field
Storage location records where the original physical photograph is kept in HCHS’s storage rooms — Box 3, Drawer 7, and so on. Currently only 4.4% of records have this filled in, and the entries that do exist are inconsistently formatted (‘Box #3’ vs ‘Box 3’ vs ‘box3’). This matters for physical retrieval: if a researcher wants to examine the actual photograph rather than the digital scan, staff need to know where to find it. Standardizing the format and filling in the blanks as items are physically handled are both high-value improvements that can happen gradually.
Source Schema
There is no national standard that governs how institutions label their storage locations, because every building and every collection is different. The important principle is internal consistency: every cataloger should use the same label for the same box or shelf, so that a location code in a catalog record reliably leads staff to the right place. Inconsistent formats (‘Box 3’ vs ‘Box #3’) mean some searches fail.
PastPerfect
PastPerfect has a Home Location field on the Location subscreen that records where the physical item is stored, using a four-level structure: Building, Room, Shelf, and Container. This is completely separate from PastPerfect’s ‘Place’ field on the main screen, which records where a photograph was taken. The naming is confusing — ‘Location’ and ‘Place’ sound similar but mean very different things in PastPerfect. Document this distinction clearly for your staff.
|
print_present |
Local physical condition indicator |
Condition / Notes |
Condition subscreen / Notes & Legal
1.9% filled; indicates whether a physical print exists alongside the negative or scan |
Our Field
This field flags whether HCHS holds a physical photographic print of an item, as distinct from a glass plate negative or other format. Currently only 1.9% of records have this filled in — it is mostly blank because the vast majority of records are prints, so noting ‘print present’ is redundant for most items. It is most useful for items where a negative is the primary holding and the question is whether a paper print was also kept.
Source Schema
Knowing what physical formats of an item an institution actually holds is a practical collection management need. It affects conservation priorities, what can be displayed in exhibitions, and what options exist for making reproductions. There is no formal national standard that governs how to record this — institutions define their own physical holdings fields based on the formats in their collections.
PastPerfect
PastPerfect has a Condition subscreen but no dedicated ‘print present’ field. For the small number of HCHS records where this is relevant, a note in the Notes & Legal subscreen is the most practical option — more straightforward than creating a custom field for data that appears in fewer than 2% of records.
|
negative_present |
Local physical condition indicator |
Condition / Notes |
Condition subscreen / Notes & Legal
1.0% filled; indicates whether a physical negative is held |
Our Field
This field flags whether HCHS holds an original photographic negative for an item, separate from a print or a digital scan. Currently only 1.0% of records have this filled in. Knowing a negative exists matters for conservation planning (negatives have different storage requirements than prints) and for reproduction options (a negative can generate new prints of high quality; a print used as the source for scanning loses a generation of quality). Like print_present, it is most meaningful for items in mixed-format accessions.
Source Schema
Same principle as print_present: knowing what physical formats an institution holds for a given item is a practical collection management decision. There is no external standard governing this — institutions define their own holdings indicators based on the formats in their collections.
PastPerfect
Same approach as print_present: PastPerfect has no dedicated ‘negative present’ field. For the small number of records where this matters, a clearly labeled note in the Notes & Legal subscreen is the most practical solution.
|
copy_count |
Local administrative field |
Copy# / Number of Objects |
Main screen
0.4% filled; PP has a copy count field natively |
Our Field
Copy count records when HCHS holds more than one copy of the same photograph — currently flagged on 93 records (0.4% of the collection). Multiple copies can arrive when prints from the same negative are donated separately or when two donors donate the same image. Knowing about duplicates affects practical decisions: Do we keep all copies? If one is damaged, is the other the backup? Should the duplicate have its own catalog record, or is a count on the main record sufficient?
Source Schema
Whether to create a separate catalog record for each physical copy or a single record with a copy count is a local cataloging decision — there is no external standard that mandates one approach over the other. HCHS’s current approach is a single record with a count, which is one of the two accepted options. Either approach is defensible as long as it is applied consistently.
PastPerfect
PastPerfect has a Number of Objects field on the main catalog screen for recording how many physical copies are held under a single catalog record — a direct match for this field. This is used when multiple identical copies are described together rather than as separate records.
|
date_cataloged |
DCMI Terms dcterms:created (for the record); PREMIS creationEvent (record creation) |
Catalog Date |
Main screen
PP Catalog Date records when the PP record was entered, not when the item was first cataloged in any system |
Our Field
Date cataloged records when a catalog record was first created. For the 22,811 existing records, this date is unknown — the source spreadsheet did not track when individual rows were added. Going forward, every new record should carry the date it was first cataloged. This enables useful reporting (‘how many items has the team cataloged this year?’) and establishes a baseline for the audit trail (‘when did HCHS first know about this item?’).
Source Schema
Cataloging practice distinguishes between facts about the original object (when was the photograph taken?) and facts about the catalog record itself (when was this description written?). Both are worth recording. The date of cataloging is particularly useful for tracking the progress of a digitization project and for understanding whether a record reflects current knowledge or was written many years ago.
PastPerfect
PastPerfect’s Catalog Date field on the main catalog screen records when the PastPerfect record was entered. For records imported from the HCHS database, this will be the import date — not the original cataloging date from the spreadsheet. For new records created directly in PastPerfect, it records when the cataloger created the record. The distinction between the original cataloging date and the PastPerfect entry date matters for audit purposes and should be documented.
|
