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. In the first part of this discussion, we outlined the pitfall of not utilizing existing bibliographic metadata standards and the limitations of relying on unstructured digitized content in culinary history environment.  This second part elaborates on the challenges faced by structured food history databases and historical culinary ontologies.

---

Unlike those unstructured databases discussed in the previous part, there are a smaller number of culinary history databases that are structured. These include resources like The Sifter, CoReMA, and ckbk. Among this small selection most have used unique approaches to structuring data entry and discovery. A common first step among these projects is to define the structure and components of a recipe. But as any recipe historian knows, this is already a challenge as “some [recipes] are very detailed, some are rather vague.”[1] Historical recipes can include much that doesn’t fit a standard structure, such as associations with feast days, a cook’s personal notes, lists of ingredients, and other procedural cooking instructions. These may also be accompanied by engraved carving diagrams, photographs of the finished dish, or, more recently, video demonstrations. Determining what should or should not be included in recipes is not easy.

Just as the purpose for reading a recipe from a cookbook determines which aspects of the text are relevant for the reader (sometimes to cook the dish, but sometimes for some culinary escapism), several needs may determine a database’s recipe structure. For example, commercial internet search engine providers encourage publishers of online, digital-first recipes to use Schema.org’s standard Recipe schema. This schema provides a common structure for recipes’ ‘how-to’ aspects, including ordered instructions, preparation times, ingredients, and nutritional data. This schema invites us to consider recipes as independent creative works separate from, but linked to, a cookbook or manuscript. Unfortunately, this schema also homogenizes recipe formats—historical or modern—to benefit search algorithms. And, of course, this comes at the expense of the sometimes crucial but highly variable culinary information found in and around the edges of historical recipe texts.

The Sifter and CoReMA project share similar recipe metadata structures that include ingredients, equipment, and cookbook concepts while also taking language and historical variation into context. The Sifter is an open, public, and mediated culinary history website that allows users to enter individual recipes as sections within a cookbook or other culinary work. The Sifter’s database does not contain full-text recipes. Instead, a researcher enters each recipe’s name and page number and then indicates which ingredients, tools, or methods are mentioned within the recipe text. CoReMa adopted an alternative approach of annotating digitized recipe text or images with a culinary semantic model comprising classes such as ‘ingredient’ and ‘instruction.’ Each recipe word or sentence from the source text is annotated and linked to a dictionary of ingredients and tools (figure 4). A standard structure for specifying recipe metadata, such as what defines a recipe or an ingredient, would provide a common language to facilitate description, identification, and content interoperability without constraining technical designs.

Even if digital collections choose common structures for recipe data, having a common vocabulary to populate those structures is still challenging. One remedy for this common problem among academic databases is to use standardized vocabularies and ontologies. In standardized ontology, concepts are predefined in a thesaurus that mediates conceptual classification. CoReMa has used the knowledge graph Wikidata’s open, standardized ontology by integrating it as the project’s vocabulary lookup. For example, all historical recipes that include the ingredient ‘saffron’ are, in turn, linked to the WikiData entry saffron (Q25434). This demonstrates that using shared metadata sources as a taxonomy of common culinary or food concepts can improve interoperability and reduce duplication of metadata creation. In theory, The Sifter database could link the entry for ‘saffron’ from its index of ingredients to saffron (Q25434 ), too, thus interlinking the databases together.

The ‘farm to fork’ food ontology, FoodOn, with its focus on food production and agriculture, describes a ‘pasta food product’ (FOODON_00001211) as ‘A food made from an unleavened dough of wheat or buckwheat flour and water, sometimes with other ingredients such as eggs and vegetable extracts.’ It also includes categories for pasta, such as canned, dried, fresh, frozen, or wet-packed cereal grain products, as well as 92 processed pastas, 40 of which are macaroni food products (figure 5). This differs from Wikidata which describes pasta (Q178) as an “Italian food made from flour, eggs, and water and shaped in different forms, usually cooked and served with a sauce” and is simultaneously a type of shelf-stable food, a kind of groat, pasta and legume, and a sort of dish or specific food preparation.

However, even these ontologies may not immediately suit culinary historical purposes. If for no other reason than the determinedly contemporary nature of these ontologies, work would be required to historicize their definitions and classifications. Furthermore, in addition to the same type of crosswalking issues that database structures share, there is also a conceptual problem within many food ontologies—that food concepts can be both different and the same. For example, while “pasta” has a different meaning when it’s an ingredient in a recipe versus when it’s a recipe in itself, at the same time, it also means the same thing…pasta. This is a crucial idea for culinary history, as a pasta historian would likely wish to find results about both. Unfortunately, most ontologies do not account for such linkages. However, FoodOn and WikiData get close in their semantic web-style focus on relationships between concepts.

These posts outline challenges and opportunities when considering common standards for sharing recipes and culinary data between food history researchers. Preexisting bibliographic structures of organization and discovery could allow food history databases to focus on food history instead of media classification. A taxonomy of subjects could be leveraged to standardize concepts. Ideally, this would be done by an open data source such as WikiData to make good use of community collaboration and existing infrastructure. The crux of the problem is that no existing ontology properly considers food historically, nor the complex cognitive connection and disconnection of food concepts.

As we have examined existing projects and culinary history corpora, we have repeatedly asked if data would be better off structured, unstructured, or just linked. Our view is that by primarily focusing on the relationships between and among concepts, whether structured or unstructured, any historical textual format could remain undisturbed while its metadata interlinked and vice versa. It’s time for digital culinary history to come into its own—it has all of the beginnings of a data-rich, analytical study. We feel that with just a little communication, coordination, and standard-setting, it could really cook.

---

1. Craig Fox, “On Making Sense of Recipes,” HUMANA.MENTE Journal of Philosophical Studies Volume 13, issue 38 (2020): 229–54. https://www.humanamente.eu/index.php/HM/article/view/327.

---

---