Food, recipes and language

A pparently humans have been writing, sharing and storing recipes for their food preparation for quite a long time. The first written recipe (besides beer’s appearing in the old Sumerian hymn) dates back thousands of years. I do know nothing about it, but according to a quick search there are many sources where to look into. An interesting finding: Recipe tablets from the Yale Babylonian Collection, previously thought to contain pharmaceutical formulas, have been decoded by French Assyriologist and gourmet chef Jean Bottero. The three Akkadian tablets, dating to about 1700 BC, revealed, Bottero wrote in a description of his find, “a cuisine of striking richness, refinement, sophistication and artistry, which is surprising from such an early period. Previously we would not have dared to think a cuisine 4,000 years old was so advanced.”

Apicius’ “De Re Coquinaria” (“On Culinary Art,” also sometimes translated as “Of Culinary Matters”) had been preceded by other recipe anthologies by the Greeks, but most of these works are lost, according to Bottero, save for a few quotations that were preserved in the work of Athenaeus of Naucratis, who lived in the second century. Athenaeus mentions the names of as many as 20 cookbook authors, but none of their work survived in its original form. And in the Bible, while food is mentioned, there are no conventional recipes. (source)

Computerized Cooking by David A. Mundie (Culinary Softwary Systems, 1985), is an inspiring booklet about recipes.. (A book on food which I would never praise more is Harold McGee’s On food and cooking)

The De Re Coquinaria (Apicius, first century CE), So, how a recipe from “De Re Coquinaria” was? For example, a kind of dessert (with English translation):

Aliteri - patina versatilis: nucleos, nuces fractas, torres eas, et teres cum mele, pipere, liquamine, lacte et ovis. Olei modicum.

ANOTHER DISH, WHICH CAN BE TURNED OVER [ A Nut Custard ] THE DISH, CALLED TURN-OVER, IS THUS MADE: CRUSH VERY FINE WALNUTS AND HAZELNUTS TOAST THEM AND CRUSH WITH HONEY, MIX IN PEPPER, BROTH, MILK AND EGGS AND A LITTLE OIL.

Quoting from the English Translation of De Re Coquinaria of Book IV, II.2 (by Joseph Dommers Vehling, 1936, who apparently had a knowledge of Latin not adequate to the task – source): This laconic formula indicates a custard poached, like in the preceding, in a mould, which, when cooled off, is unmoulded in the usual way. This patina versatilis is in fact the modern crême renversée, with nuts. It is characteristic of Apicius for incompleteness and want of precise directions, without which the experiment in the hands of an inexperienced operator would result in failure.

The Italian translation (source, source2) reads as

Torta soda da arrovesciare: Abbrostisci pinocchi e gherigli di noci, e tritali con mele, pepe, savore, latte ed uova. Poco d’olio.

It is clear that the style of recipes left very much to the reader: ingredients (quantity and exact type), directions and cooking instructions. Over the centuries cooking books evolved: from expensive tools for professionals they morphed into mass-printed instruction books for middle-class housewives, gourmet amateurs and alike. Now nothing is easier than finding thousands of look-alike recipes for something. Apps and dedicated web sites. Most of it is not very much useful, for two reasons: first, I cannot trust random people posting their recipe online; second, even if the recipes are good, they are too many to do anything even on a tiny fraction on them. So we go back to keeping a personal journal of recipes, annotations, and culinary experiments.

Recipes, books and software

A ccording to microformats and pesto websites, and some google searches, the following is a list of recipe formats related to cooking software. The main player in this game now is google, that has developed a recipe format used for SEO and AI (in a sense: to let google assistant read aloud the recipe directions). Even if that is meant to be a format for web developer, not cooking people, it makes sense to take it into consideration.

Human-readable:

• Meal-Master: very widely used text format. Easy to read, parse and write. An archive of recipes: 158,000+ MM Recipes From Around the World.
• MasterCook: it has a text format MXP, and a XML format MX2 and binary versions (MCX,MC2,MZ2).
• (Now You’re Cooking NYC export text files)

XML-based:

• The Recipe Markup Language RecipeML (revised 2002).
• REML: The Recipe Exchange Markup Language (last updated in 2005).
• RecipeBookML (created in 2005, now extinct). Archived 2014 page
• CookML (last updated 2018)
• Eat Drink Feel Good Markup Language is now referenced only in a 2007 blog post, which is about its first article (2005).

YAML-based:

• A (the most) complete set of properties, and a YAML-based recipe language is discussed in Open Recipe Format. The language is very complete, but not formally defined (at least, on the website), and a little bit too verbose for a human.
• A similar approach is pyprika, which is a Python library for parsing and managing recipes. It gives support for recognizing a human-friendly representations of quantities and measurements normally seen in cook books, and parsing a custom YAML spec for storing recipes on disk.

Binary files:

• Big Oven (CRB)
• Cook’n (DVO)
• Living Cookbook (FDX)
• Mac Gourmet (Mgourmet)

Engineering cooking:

• RxOL, proposed at the end of the essay Computerized Cooking by David A. Mundie (Culinary Softwary Systems, 1985), together with a now extinct software Cocina. Very concise, elegant, but extinct.
• Example of a Cooking for engineers recipe in tabular format: Simple Tiramisu (2004). A relative language has been discussed, but I did not find a reference to it.
• Another very interesting language specification is pesto, which is human-readable, precise and rich, and inspired by RxOL. Pesto is a text-based human-editable and machine-transformable cooking recipe interchange format
• Google structured data format for recipes (JSON-LD) is a gigantic power character on the scene.

Similar to google’s recipe data format, the draft microformat h-recipe contained the following minimal properties.

p-name: the name of the recipe
p-ingredient: describes one or more ingredients used in the recipe.
p-yield: Specifies the quantity produced by the recipe, like how many persons it satisfies.
e-instructions: the method of the recipe.
dt-duration: the time it takes to prepare the meal described by the recipe.
u-photo: an accompanying image.

p-summary: provides a short summary or introduction.
p-author: person who wrote the recipe, optionally embedded with h-card.
dt-published: the date the recipe was published.
p-nutrition: nutritional information like calories, fat, dietary fiber etc.
p-category: recipe categories/tags.

Other formats add other properties (see google for a very exhaustive list). Are they necessary? It depends. What is the needed level of details in instructions and ingredients?

A finely-grained set of instructions can be read by an unskilled person, or a robotic machine. On the other hand, and expert cook does not need precise ingredients or detailed instructions: the recipe is just a memory aid, better written laconically. So, a format for recipes should allow to express all the shades between the ends of the recipe styles spectrum.

Goal: a language which is easy to read and write (Meal-Master), renders well on the web (MarkDown), flexible, and that can be parsed to enrich the text with all useful attributes, when possible (?). Why not a nice web solution such as MyCookBook or CookPad? Basically because of the long-term unpredictability of any such project. And leveraging google technology might be interesting per se.

If the format will be parsed by a (pythonic) parser, somewhen in the future, it will be possible to let google assistant read aloud the directions, plan meals according to menus cost and nutrition, optimize the time spent in the kitchen and buying groceries, and so on. There is already ChowDown which is working well and adding microdata. Just: I would like to have a bit of thinking about the textual format first.

Language (flexible) specification

W hat is the language intended for? First, for my personal use. Which means I might want to use it as a memory tool, a set of detailed instructions to try and test new recipes (possibly machine-readable), or as a tool to search and find recipes I know already (menu-making).

1. A very simple DSL (Domain Specific Language) in python (can it be describe as EBNF grammar? Lark or textx?). Use it to pre-process markdown hugo recipe files and add JSON-LD data.
2. Back-end archiving (sqlite?) with search, menus, nutritional information, validation; front-end with html rendering, javascript ingredient quantities calculator, timers, walk-through mode, optional text/mode.
3. Blend together hugo, markdown and a few extra for the instruction tree.

Recipe structure

Base-format: hugo markdown, with a preamble.

Example of preamble, in hugo front matter, in TOML format (equivalent formats: JSON, YAML). Here every possible more or less useful set of variable-value pairs can appear. Numbers according to locale, ISO format for dates, duration in time units, calories and macros in suitable units. All parameters are optional, except the title. Alternatives are separated by |.

+++
title|name|recipe= "Manzo alla california"
author= "-dlf"
version= "2.1"
date= 2019-08-02
lastmod= 2019-08-05
yield|servings= 6
lang= "it"
tags=  ["dinner","traditional","meat"]
category|cat= ["Secondi", "Carne", "Taxonomy-Term"]
preptime|prep_time|preparazione= 1.5 h 
cooktime|cook_time|cottura= 0.5 h 
difficulty= 4/5 
id|index|rid= "i0310450"
cost|costs|costo= 20€
country= Italy 
allergies= ["noci","latte"]
nutrition|calories= 540 kcal/100g 
macros= [ proteins, carbo, fat ] 
+++

Example of structure of a recipe:

+++
TOML header
+++

.. markdown summary/introduction/abstract .. 
here a reference to the `SOURCE` of the recipe, 
maybe `EQUIPMENT`, `NOTES`, ...


# Ingredients 

 - ingredient1 (qty)
 - ingredient2 
 - [optional ingredient3]
 - (ingr4 | ingr5) //alternative (inline comment)

EQUIPMENT|ATTREZZATURA: casseruola, fornelli 

> note (alternatives to ingredients, preparation ... ) 

# instructions | directions | preparation 
 
..  whatever chunk of markdown (list or not) .. 

> note (how to serve, to preserve, ... ) 
...

Ingredients

Each ingredient has quantity, expressed in some units; no quantity equals qb quantity (quanto basta); it might be expressed in a range; the ingredient can be optional, or can have alternative forms. Some annotation about preparation can be useful. Examples:

• Polpa di manzo, 800gr
• 800 gr polpa di manzo
• 800 gr polpa di manzo (a tocchi)
• 800 gr polpa di manzo (a tocchi; rosolata in casseruola con aglio e cipolla)
• Polpa di ( manzo | vitello ) 800gr (» a tocchi e rosolata)
• Polpa di [ manzo | vitello ] 800gr
• Polpa di manzo/vitello 800gr
• [aglio due spicchi] (opzionale)
• 1/2 cipolla
• Sale, pepe, glutammato.

Units could be metric, SI, US or imperial, or whatever. It is important that that they are explicit. Approximately, the following holds (precise measure are different).

If possible I would like to have a very flexible format. Any number (decimal, fraction, mixed, easy expressions), any unit in any position of each ingredient could be located and parsed (?). Then the rest is the ingredient name, which could be matched for nutrition data and cost, if a db is available. For example, ingredient input text in CookPad is normalized and the numeric quantity, wherever typed, is moved to the head of the string.

Directions | preparation

The ingredients are processed with tools/equipment (pot, pan, oven, knife, …), actions (cut, boil, bake, mix, …). Is it really necessary to tag the verbs used? The nice languages/microformats met above are not really for a human eye reading. Good ideas from RxOL and pesto: single-character operators (RxOL: unary operator =, parallelize +, binary operand /, * reference, # variant, | alternative, ; final comment), (pesto: + ingredient, & tool, > result, | alternative, * reference, % directive, [..] action).

I’d rather prefer:

• [@ ...] for the location (pan, oven, cutting board, bowl, …) when possible;
• [!10 min] for setting a timer of 10 minutes, or [⏰10 min];
• and the actions either uppercase or boldface, or whatever markdown. Maybe emojis or Unicode arrows.
• All literal symbols should refer to equipment, in a direct or indirect way, and appear between brackets (and with an argument if needed).

For example, Apicius' dessert would be:

• [@pan] middle hot:
  • ADD walnuts and hazelnuts (crushed very fine), TOAST them [!3 min]
  • CRUSH with honey
  • MIX in pepper, broth, milk and eggs and a little oil.

But any separator would work: with more details it would read as

• [@pan] middle hot: ADD walnuts and hazelnuts (crushed very fine), TOAST them; CRUSH with honey;
• [@bowl]: MIX in pepper, broth, milk and eggs and a little oil. ADD ➡️ [@pan]: COOK [⏰10 min]

The nice little clock ⏰ (from emojify) can help visualize the timer. Other Unicode symbols might help as well. Useful to pre-process markdown and replace short versions ⏰ = !, and ➡️=->.

Other symbol? Maybe ⬅️ for adding to the left… Just all of the symbols should appear between brackets (and brackets should never precede a left parenthesis).

Do I need photos? Not at all. I am not sure about emojis or visual hints (they might be useful) but photos are a kind of clutter.