Pruzhany Chronicles
Interactive Edition Guide
Introduction
The Pruzhany Chronicles transforms the archived pages of two historical Yiddish newspapers into a vivid portrait of a community on the eve of its destruction. Using generative AI to read the surviving editions from Pruzhany, Poland, the project extracts local entities—individuals, businesses, life events—and weaves them with Holocaust databases, library collections, and yizkor books to reassemble a data-driven record of the town's final years.
This guide walks through one edition—December 16, 1938—to document how a newspaper scan becomes a structured database. Each section details one layer of the data model, from physical text extraction through semantic event mapping, with every value drawn from the live edition bundle. Work is ongoing to process the approximately 500 remaining editions of the Pruzaner Sztyme and Pruzaner Lebn spanning 1934–1939, preserved by the Historical Jewish Press.
Three-Layer Architecture
The data model separates the newspaper content into three increasingly semantic layers, plus a cross-cutting enrichment layer. This separation reflects a fundamental insight: the physical layout of a newspaper page, the editorial structure of its content, and the real-world events it describes are three distinct things that happen to share the same physical medium.
Edition at a Glance
This guide explores the 1938-12-16 edition of the Pruzhaner Shtime — 4 pages containing 7,873 words across 170 text blocks, organized into 77 content units. The enrichment layer adds 163 named individuals, 61 locations, and 3 documented events.
Entity Counts
Pages & Blocks (Layer 1)
The physical layer represents the newspaper as the OCR pipeline sees it. Each of the 4 pages is divided into text blocks — contiguous regions of text identified by their bounding box coordinates on the page image. These coordinates allow the digital edition to link every piece of transcribed text back to its precise location on the original newspaper.
Page Summary
| Block ID | Bbox [x, y, w, h] | Transcription | Conf. | Content Unit |
|---|---|---|---|---|
| blk-1938-12-16-p1-r001 | [918, 140, 1479, 102] | אקציע פון קק"ל! שטיצט די חנוּכה | — | |
| blk-1938-12-16-p1-r002 | [2295, 282, 686, 64] | PRUŻANER SZTYME | — | |
| blk-1938-12-16-p1-r003 | [1739, 301, 373, 54] | פרייז 10 גר. | — |
Content Units (Layer 2)
Content Units represent the editorial structure of the newspaper. Each unit is a coherent editorial object — an article, a notice, an advertisement, a congratulatory message, or an obituary. A single Content Unit may span multiple physical blocks (for example, an article that flows across two columns).
Showing 57 ad units. Select a type above to browse.
| ID | Printed title · Supplied title | People | Locs |
|---|---|---|---|
| cu-1938-12-16-i0101 | Headline: JNF Hanukkah Campaign | 0 | 0 |
Page location Page 1 1
block Yiddish Textאקציע פון קק"ל! שטיצט די חנוּכה English TranslationSupport the Hanukkah campaign of the JNF! | |||
| cu-1938-12-16-i0103 | אקדמית חנוכה נהדרתA splendid Hanukkah academy | 2 | 2 |
| cu-1938-12-16-i0104 | א פייערלעכע חנוכה אקאדעמיעA festive Hanukkah academy | 0 | 2 |
| cu-1938-12-16-i0105 | רחל פאמעראניעץ חיים שור חתונה געהאטMain Wedding Announcement: Rachel Pomeranietz & Chaim Shor married in Buenos Aires, Dec 10, 1938 | 2 | 3 |
| cu-1938-12-16-i0106 | צו דער חתונה פון אונזער ליבער טאכטער און שוועסטער רחל מיט ה' חיים שור פאטער דוד פאמעראניעץ, כייקע, זעליק, לאה'לע שאפירא (הי), יצחק פאמעראניעץ (ארגענטינעWedding greetings to Rachel Pomerantz from her family | 7 | 2 |
| cu-1938-12-16-i0107 | למחותננו ר' דוד פומרניץ (פה), בנו יצחק (ארגנטינה) ולבננו זליק, חייקה ולאה שאפירא יחזקאל שאפירא ומשפחתו (פה) דוד (ירושליםWedding greetings from Yechezkel Shapiro and family | 9 | 3 |
| cu-1938-12-16-i0108 | אונזער פלימעניק און קוזין דוד פאמעראניעץ בערל קאפלאן און פאמיליעFrom Avraham-Yitzchak and Berl Kaplan | 5 | 0 |
| cu-1938-12-16-i0109 | אונזערע פריינט פאמיליעס פאמעראניעץ־שאפירא איטקע, משה טשערעטשעווסקי און קינדערFrom Itke and Moshe Cherechevsky | 4 | 0 |
| cu-1938-12-16-i0110 | אונזערע פריינט פאמיליעס פאמעראניעץ־שאפירא צירל, בנימין עלמאן און קינדערGreetings from Tzirl and Binyamin Elman | 4 | 0 |
| cu-1938-12-16-i0111 | אונזער קוזין דוד פאמעראניעץ ריבטשע, משה יודעוויטשFrom Kaplan and Judewicz families | 8 | 0 |
| cu-1938-12-16-i0112 | אונוער קוזין דוד פאמעראניעץ לייבל (פיעסקFrom Shimon Birnbaum and Leibel | 5 | 3 |
| cu-1938-12-16-i0113 | אונזער קוזין דוד פאמעראניעץ העניע, לייב שו"ב פרוזשאנסקי און קינדערFrom Henye and Leib Pruzhanski | 6 | 0 |
| cu-1938-12-16-i0114 | אונזערע פריינט פאמיליעס פאמעראניעץ־שאפירא יעקב פערלשטיין און פאמיליעHearty Mazel Tov from Jacob Perlstein | 3 | 0 |
| cu-1938-12-16-i0115 | אונזער פריינט דוד פאמעראניעץ בעלטשע, אליהו פאמעראניעץWedding greetings from Belche and Eliyahu Pomerantz | 6 | 0 |
| cu-1938-12-16-i0116 | ר חל! צו דיין חתונה מיט ה' חיים שור אסתר זאוועלעווסקי (קאמעניעץGreetings from Teigl, Dare, Lashe, and Esther | 7 | 3 |
| cu-1938-12-16-i0117 | אונזער פריינט דוד פאמעראניעץ פאמיליעס ליפשיץ־פאמעראניעץ סגלFrom Lifshitz-Pomerantz families | 3 | 0 |
| cu-1938-12-16-i0118 | אונזערע גוטע פריינט פאמיליעס פאמעראניעץ שיינדל, אהרן סופר, פריידקע, וואלפקע עלמאןFrom Spector and Elman families | 8 | 0 |
| cu-1938-12-16-i0119 | חברטע רחל! דבורה, לייבל שאפירא און טעכטערלFrom Dvora and Leibl Shapiro | 4 | 0 |
| cu-1938-12-16-i0120 | די פאמיליעס פאמעראניעץ שאפירא אפרים־מיכל פרוזשאנסקי שו"ב און פאמיליעFrom Ephraim Michel Pruzshansky | 3 | 0 |
| cu-1938-12-16-i0121 | מזל־טוב! די פאמיליעס פאמעראניעץ שאפירא יוסף קליינערמאן און קינדערFrom Yosef Kleinerman and children | 3 | 0 |
Life Events (Layer 3)
Life Events represent the semantic layer — real-world occurrences that generated newspaper coverage. The Pomerantz–Shor wedding, for instance, produced 27 Content Units: a formal announcement from the bride's father plus 26 congratulatory messages. The event groups these Content Units together and records each unit's role (primary announcement, congratulation, or mention).
This edition contains 3 events with associated Content Units. Each event links to the shared record of the same happening across issues.
| Event Name | Type | Source | Main people | Units |
|---|---|---|---|---|
| Death of Chaim Feldman | Death | edition | 1 | 2 |
| Birth to Rivka Kaplan-Judewicz and Moshe Judewicz | Birth | edition | 3 | 23 |
| Wedding of Rachel Shor (née Pomeraniec) and Chaim Shor | Wedding | edition | 2 | 27 |
Community Connections Made Visible
The table above shows individual events in isolation. But the real power of the semantic layer emerges when events are cross-referenced — revealing how the same people appear across different life events, their relationships reconstructed from the newspaper's own pages.
Social overlap between two life events in the 1938-12-16 edition
The Enrichment Layer
The three layers above capture what is in the newspaper — its physical form, editorial structure, and the events it describes. The enrichment layer goes further: it adds structured knowledge drawn from external research, transforming brief textual mentions into richly annotated records. Every named person, place, organization, and topic becomes a node in a growing knowledge graph.
This enrichment accumulates gradually. The current edition represents a snapshot of ongoing research — some entities have extensive biographical data and verified Holocaust fates, while others remain skeletal entries awaiting further investigation. The Data Quality section quantifies these gaps.
Five Entity Types
The sections that follow explore each entity type in detail. Here is what the enrichment layer captures for this edition:
References are maintained in both directions — a person lists all content units where they appear, and each content unit lists all people mentioned in it — supporting different access patterns depending on whether you're exploring an entity or reading an article.
People
The enrichment layer identifies 163 individuals mentioned in this edition. Each person entity includes biographical data and, where possible, research into their fate during the Holocaust. This research draws on databases from Yad Vashem, the Arolsen Archives, memorial books, and other sources.
For most individuals in this edition, their Holocaust fate remains unknown — a common challenge in Holocaust research. The fate classifications range from definitive ("Perished," "Survived") to probabilistic ("Likely Perished," "Likely Survived" based on their known location and circumstances).
22 people connected by 182 family relationships across 1 family groups
Locations
The enrichment layer includes 61 geographic locations, organized in a hierarchical tree reflecting administrative containment: streets sit within towns, towns within districts, districts within regions, and regions within countries.
Each location is linked to external geographic databases (Wikidata and GeoNames) for interoperability with the European Holocaust Research Infrastructure (EHRI). Locations of Holocaust significance include structured metadata about ghettos, camps, and massacre sites.
The map below shows how this single newspaper edition connected readers across four continents — from the Pruzhany heartland to the Argentine diaspora, from Eretz Israel to Newfoundland. Dot size reflects the number of content units mentioning each location. Click any dot to see its details in the tree below.
Click any location in the tree to see its details. Use Expand All to see the full hierarchy.
country Belarus 0
region Brest Region 0
town Pruzhany 14
country Canada 0
country Israel 0
country Lithuania 0
country Poland 2
Pruzhany
- Type
- town
- Coordinates
- 52.5567, 24.4567
- Content Units
Topics & Organizations
Topics (0)
Topics categorize Content Units by theme, grouping related editorial content regardless of physical position in the newspaper.
Organizations (44)
Organizations mentioned in the newspaper include local businesses, community institutions, and cultural organizations, linked to the Content Units where they appear.
Data Quality & Coverage
Where is the data complete, and where are the gaps? This section examines field coverage across the edition's entities and visualizes the Holocaust fate research that underpins the biographical data. These metrics help assess readiness for using this edition as ground truth when processing future editions.
Field Coverage
Percentage of entities where key fields have been filled in (excluding “unknown” values for Holocaust fate).
Holocaust Fate Distribution
Each square represents approximately 1% of the 163 named individuals.
Timeline
Birth and death years of named individuals, relative to the newspaper's publication
Technical Reference
This section documents key design decisions in the data model — the choices that aren't obvious from the data itself but matter for reviewing correctness and extending the model for future editions.
Why String IDs?
All entity identifiers are semantic strings like person-rachel-pomerantz or cu-ball-announcement rather than auto-incrementing integers. This choice offers several
advantages:
- Self-documenting: You can read the data without looking up IDs in a separate table
- Prefix-based polymorphism: The UI can determine entity type from the prefix (
person-,cu-,location-), enabling a single selection variable to hold any entity - Stability: IDs don't change when the database is rebuilt (unlike auto-increment)
- Debuggability: Log messages and JSON output are human-readable
ID Prefix Reference
| Prefix | Entity Type | Example |
|---|---|---|
page- | Page | page-1938-12-16-4 |
blk- | Block | blk-5746 |
cu- | Content Unit | cu-13685 |
event- | Event | event-pomerantz-shor-wedding |
person- | Person | person-rachel-pomerantz |
location- | Location | location-pruzhany |
topic- | Topic | topic-lifecycle-events |
org- | Organization | org-kehillah-pruzhany |
Why snake_case?
All field names use snake_case (e.g., holocaust_fate, unit_ids) for consistency with the SQLite database layer. Earlier versions used
camelCase, but the migration to a relational database standardized on snake_case throughout the
stack.
Why Separate Files?
Each data layer is stored in its own JSON file because each has a different authoring cadence:
- Pages/Blocks: Change when OCR is re-run or corrected
- Content Units: Change during editorial curation
- Enrichment: Accumulates gradually through research
- Life Events: Curated as editorial understanding deepens
Separation allows independent updates without merge conflicts. The Edition Bundle (1938-12-16-edition.json) contains the five
projected issue documents. Repeated source text is stored once in its text table; the
accompanying JSON Schema describes those references. Each person's detail_path links
to their public facts and sources across issues. People share a fixed set of shards. Both the issue
and those shards come from the same privacy projection.
Event Source Classification
Events carry a source field distinguishing their provenance:
edition— Events documented in the newspaper itself (weddings, bar mitzvahs, community news)historical— Events added from external Holocaust research (ghetto establishment, deportations, massacres)
Events of type holocaust_event always have source: 'historical'. This
classification ensures that the newspaper's own voice is never confused with retrospective
knowledge.
רייזטשע און משה יודעוויטש מעלדן וועגן געבורט פון זייער טעכטערל
Rivtche and Moshe Judewicz announce the birth of their little daughter
— for Tzvia