When a PDF Catalog Is Just a Pretty Mess of Data
Auction house catalogs are beautifully produced documents. Sotheby's, Christie's, and their peers invest heavily in print and digital catalog design — high-resolution images, elegant typography, lot descriptions that read like art criticism. But beneath that polish sits a structured dataset waiting to be extracted: artist names, lot numbers, estimated values, mediums, dimensions, provenance notes, sale results.
The problem is that a catalog — even a digitized one — is not a database. It is a presentation layer. When a researcher, analyst, or collector needs to query, sort, or cross-reference that information, the PDF becomes an obstacle. Working with 877 artwork records from a single Sotheby's catalog makes this tension concrete. At that scale, manual copy-paste is error-prone and unsustainable. The question is how to move from unstructured catalog pages to a clean, queryable Excel workbook that actually holds up under analysis.
Done badly, this kind of conversion produces a spreadsheet full of merged cells, inconsistent artist name formats, dimensions recorded as free text, and missing provenance fields that someone will have to clean up later at significant cost. Done well, the result is a normalized relational-style table that feeds directly into pivot tables, VLOOKUP chains, or Power Query refreshes without a single manual fix.
What Proper Catalog-to-Database Conversion Actually Requires
The shape of this work is more disciplined than it appears from the outside. There are four things that separate a rigorous conversion from a rushed one.
First, field schema design happens before any data entry begins. The column headers are not obvious — deciding whether "Artist" is one column or three (last name, first name, nationality) has downstream consequences for every sort and filter the database will ever support.
Second, controlled vocabulary and lookup tables govern fields like medium, period, and condition. Free-text entries in these fields destroy groupability. "Oil on canvas," "Oil/Canvas," and "o/c" are three representations of the same value that Excel will treat as three different categories.
Third, dimension data requires a defined parsing convention. Catalog dimensions appear in formats like "61 × 46 cm" or "24 × 18 in." — and sometimes both. A well-built schema stores height and width as separate numeric fields in a single unit system, with the original string preserved in a raw notes column.
Fourth, provenance and exhibition history are semi-structured text fields that need boundary rules. Without them, these fields balloon unpredictably and become unsearchable.
Building the Schema and Executing the Conversion
Designing the Field Architecture
For an 877-record art catalog, the working schema typically runs to around 30 columns. The core fields cover lot number, artist last name, artist first name, nationality, birth year, death year (or "living"), title, date of work, medium (controlled), support (controlled), height in cm, width in cm, depth in cm (for sculpture), edition information, catalogue raisonné reference, estimate low, estimate high, hammer price, and currency.
Additional fields handle provenance (one text field per provenance line, often needing three to five separate columns labeled Provenance 1 through Provenance 5), exhibition history, literature references, condition notes, and lot status (sold, passed, withdrawn).
The estimate and price fields deserve particular attention. Sotheby's catalogs publish estimates as ranges (e.g., £40,000–60,000). Storing these as a single merged text field makes them useless for analysis. Splitting into Estimate_Low and Estimate_High as numeric fields, with currency stored separately, allows for immediate aggregation and comparison across the dataset.
Controlled Vocabulary and Data Validation
Before any records are entered, dropdown validation lists should be built for Medium, Support, Currency, and Country of Origin. In Excel, Data Validation with a named range works well here. A separate sheet — call it "_Lookups" — holds the master lists: roughly 40 medium values (Oil, Watercolor, Gouache, Pastel, Acrylic, Mixed Media, etc.) and 15 support values (Canvas, Paper, Board, Panel, Linen, etc.).
When a catalog entry reads "gouache and ink on laid paper," the correct approach is to record "Gouache" in Medium, "Paper" in Support, and capture the full original text in a Medium_Raw column. This preserves fidelity to the source while keeping the analyzed fields clean.
Artist names need a normalization pass. Catalog entries sometimes appear as "Jean-Michel Basquiat," sometimes as "Basquiat, Jean-Michel," and occasionally with accents inconsistently applied. A consistent format — Last, First — stored across two columns, with a concatenated display formula in a third column (=B2&", "&A2), handles both storage and display needs without duplication.
Dimension Parsing and Unit Conversion
Dimensions from a Sotheby's catalog appear in multiple formats across 877 lots. Some entries give metric only, some give imperial only, and some give both. The conversion rule should be: store everything in centimeters, with a formula-driven conversion where needed (1 inch = 2.54 cm, applied as =ROUND(D2*2.54,1) for any imperial-source value).
For entries like "61.5 × 46.2 cm (24 ¼ × 18 ⅛ in.)," the height and width values are extracted directly. For entries that give only inches, the conversion formula runs against those values. The original dimension string goes into a Dimensions_Raw column. With these three columns — Height_cm, Width_cm, Dimensions_Raw — the data supports both precise filtering (show all works smaller than 50 × 50 cm) and audit trails back to the source.
Structuring Provenance and Sale Results
Provenance text in auction catalogs follows a loose convention: each provenance line represents one ownership transfer, often with location and date. Storing these across five dedicated columns (Prov_1 through Prov_5) captures most catalog entries, with a Prov_Overflow field for unusually complex histories.
Sale results — hammer price specifically — are often recorded post-sale. Building the schema to accommodate a Hammer_Price column and a Sale_Status column (Sold / Passed / Withdrawn) from the start means the workbook can be updated after the auction without restructuring. A simple ratio formula (=IF(Hammer_Price>0, Hammer_Price/Estimate_Low, "")) gives immediate above/below estimate context for each lot.
What Goes Wrong When This Work Is Underestimated
The most common failure is skipping the schema design phase entirely and starting to type data directly into a blank spreadsheet. Without a defined column structure, field names drift across sessions — "Artist Name" becomes "Painter" in row 200 and "Creator" in row 400. Fixing this retroactively across 877 rows costs more time than building the schema correctly at the start.
Free-text medium fields are a close second. A dataset where medium is recorded as uncontrolled text might contain 60 or more unique values for what are actually eight distinct categories. Running a PivotTable on that field produces meaningless output. The fix — a find-and-replace normalization pass — is tedious and still leaves edge cases.
Dimension data stored as a single merged text string is similarly problematic. "48 × 36 in." sitting in a single cell cannot be filtered by size without a manual parsing step. At 877 records, building that parsing step after the fact typically takes several hours and introduces its own errors.
Another consistent issue is inconsistent currency handling. When a catalog covers lots with estimates in GBP, USD, and EUR — which Sotheby's multi-session catalogs often do — storing the currency symbol inside the price cell ("£40,000") instead of in a separate Currency column makes aggregation impossible without a cleaning formula.
Finally, treating the conversion as finished when the last row is entered is a mistake. A proper quality pass — spot-checking 10% of records against the source catalog, running a COUNTBLANK check on required fields, and validating that no estimate_low value exceeds estimate_high — typically catches errors in 3-5% of records even in careful work.
What to Take Away From This Kind of Work
The core discipline here is schema-first thinking. Every decision about field structure, controlled vocabulary, and unit convention made before row one is entered pays back multiple times over in analysis quality and maintenance time. An 877-record catalog is large enough that shortcuts compound into serious problems, but small enough that a well-designed schema makes the dataset genuinely useful in a single working session.
If this kind of structured data extraction and normalization work is something you would rather hand to a team with established processes for it, you might explore how others have tackled similar challenges — like converting a Sotheby's catalog of 877 artworks into a structured Excel database or organizing 3,500 contacts into a structured Excel database.