By James Edward Malin and Gary Thompson
This two-part post elaborates on three problems inhibiting the building and connecting of culinary research databases: obstacles to combining historical mediums, differences in data entry structures, and challenges of historical culinary ontologies. It could be said that culinary history’s multidisciplinarity nature makes it difficult to marshal a level of cohesion to tackle such problems. Still, food history’s access to so many methodologies should provide or inspire solutions. Hopefully, in elucidating these challenges, we may begin to discuss and develop the best principles and practices for gastro-historical databases in the future.
With the preponderance of new technology, interest, and a critical mass of digital and digitized gastro-historical material available online, the era of digital culinary history should be here. However, the lack of cohesion among digital infrastructures and data types has led to an online environment of highly disconnected and siloed culinary historical research tools. Even among historical cookbook databases, for example, concepts like recipes, ingredients, and cooking directions may be defined, organized, and structured differently. “Pasta” in one database, for example, has few ways to crosswalk to “pasta” in another. Therefore, a researcher must retry their query over and over again, in different ways: perhaps “pasta” as a recipe in one collection (Figure 1), “pasta” as an ingredient in another (Figure 2), and “maccheroni” in yet another.
Today, food history can be conducted through digital facsimiles of cookbooks, restaurant menus, food magazines, newspaper advertisements, and more. Many culinary historical databases rely on the principle of providing access to this digitized, searchable but unstructured content. Some examples include Food and Drink in History, the Hathi Trust’s Food Studies Collection, the Home Economics Archive: Research, Tradition, History, the Manuscript Cookbook Survey, and many more. Within any one of these, a simple keyword search “pasta” returns a simple list of its occurrences across millions and millions of documents (Figure 3).
It may seem obvious, but until recently, all cookbooks were books. We mention this not because it is novel but because not all historical cookbook databases utilize the longstanding and preexisting systems and standards of bibliographic description, organization, discovery, and access developed by librarians over centuries. These systems primarily sought to compress book metadata into standardized, searchable information units almost always backward-compatible with their precursors. They grew from the once ubiquitous index-card catalog to the They will only continue to evolve and improve.
However, not utilizing existing metadata standards can mean expending effort recreating bibliographic systems that don’t have much to do with food history. For example, one data point in a food history database is a cookbook’s author. This seems like a standard and straightforward data point to capture. But what happens if the author’s name is spelled differently in two texts? Do you stay accurate to both texts or just one? What if there are multiple authors listed in a cookbook? Do they get listed jointly, or must the database developer find a way to supply multiple author categories? How do you encode an author that is an organization and not a person? Must one transliterate names from foreign scripts and languages? How do you handle anonymous works or pen names? As you see, capturing “author” is a deceptively complex task.
But librarians have already encountered all these questions and many others. They’ve created systems and standards, shared toolkits and databases for this one, simple data point, and many others. ‘Authors’ are generally located in 1XX MARC fields, which include 100s (Personal Names), with variables such as $b Numeration, for names with hereditary identifiers (like “III” or “the second,”) or $e, Relator term, which specifies the controlled “MARC Code List for Relators” that person has with the work. While 100s have three indicators for different name elements and 17 different variables, 110s (Corporate Names)—used when the work is authored by a group or organization—has three indicators and 20 variables. These include $b, subordinate unit, for a corporate author associated with a larger body, and $c, Location of meeting, primarily used by proceedings. For both, numbered fields $0-$8 connect to yet another separate database of 10.9 million standardized names, managed by the Library of Congress Name Authority Cooperative Program (LC/NACO). The Program for Cooperative Cataloging that oversees NACO, is a group of career catalogers who meet monthly to discuss, add, remove, or augment names within this database. And remember…this is all for one, seemingly simple data point: author. How could one compete with such a comprehensive, standardized system, built over centuries? Furthermore, why would you when it is mostly completely open and free? Why try to recreate the wheel when the existing system is there for the taking? Furthermore, what culinary historian would choose to fuss over the tedium of bibliographic information instead of focusing on something gastronomic?
In the next part of this discussion, we explore the challenges faced by structured culinary history databases, and the opportunities for a future that could provide the best of both unstructured and structured worlds—having our cake and eating it too. To say nothing about spelling variation…