My "everything goes" dish: Finnish karjalanpaisti pork cubes seasoned with Vietnamese sauces then braised and shimmered in miso soup, Japanese style, with fried eggs and wakame. Served with Italian penne pasta.
When I used to live with one of my ex-girlfriends, we absolutely loved indulging in exotic food tours once every few weekends. Usually it was just me cooking up the meal because she had this belief that she has terrible taste and everything she touches turns sad and soggy. One weekend I decided that I wanted to help her become more confident and also that I want the cooking to be more like a couple thing with back-and-forths and each one supporting the other. So we sat down with the recipe for a fairly complicated dish and tried to figure out how we can best divide the tasks among ourselves.
Traditionally, cooking recipes are written into two sections, an ingredient list and a list of step-by-step instructions on how to transform to the ingredients into the final dish. But the instructions are written as if they all have to be done in a linear fashion. It's not really clear what depends on what and what can be done in parallel and it's easy to lose track of where you are in the recipe. Also, in order to understand what happens to each ingredient, you have to carefully scour the instructions to find similar matching words to the ingredients.
This is not great for collaboration! So we started putting the ingredients and the instructions to the same space and drew out lines connecting ingredients if there are some actions transforming them into something new, recursively until we reach the final dish.
Cog au vin recipe from BBC Good Food (https://www.bbcgoodfood.com/recipes/coq-au-vin)
This is a bit hard to explain in words so here is an example of my transcription for Gennaro Contaldo's fantastic bolognese recipe from Jamie Oliver's YouTube channel (whole-heartedly recommended, this Italian grandpa must be seen to believe; and you can click/tap on the image for a bigger view):
It is now very clear from a glance that in order to make bolognese, you have to make the ragù and the pasta, and in order to make the ragù, you have to make the sofrito, and in order to make the sofrito, you have to have these certain ingredients cooked in this certain way, etc. It's turtle all the way down! And we can now see that the pasta, stock, sofrito can be done separately (some recipes are more parallelizable than others; the first one that we tried was a great example but we lost that piece of A4 paper, sadly, and I don't even remember what we cooked that day exactly anymore).
It's basically an example of directed acyclic graphs (DAG). A graph is a computer science term for what we would usually call a network. A graph consists of nodes (also called vertices) and edges linking the nodes together. A graph is directed if the edges have direction, i.e. A → B is not the same as B → A. In our case, the direction implies time dependency: the ragù must be done before the final dish. A graph is acyclic if there is no possible sequence of linking between a node and itself. It would be silly if we could go from the final dish back to diced celery 😅.
For now, as far as I know, there is no intuitive tool yet to create this kind of graph for personal use. I'm currently handwriting all my recipes into Microsoft OneNote but you may have success with a mind-mapping tool.
I can imagine this method of representation being part of a bigger cooking knowledge management system. You could have recipes depending on each other and/or reusing parts of each other. For example, the recipe for Spaghetti Bolognese calls for sofrito as the base for the sauce. Many other Italian ragus also call for sofrito. We could have them all depend on a single sofrito as one of the ingredients.
Once you have the recipes broken down into structured data, you can do all kinds of interesting queries on top of it. For example, you can automatically estimate recipe difficulty by analyzing the complexity of the graph: how many nodes and edges are involved, longest path to the finished dish among other metrics like centrality. We can also add weights to the nodes to represent price, relative rarity to find in a particular locale (Latundan banana "chuối tây" is basically impossible to find in Finland, oh that richly sweet taste...) or to edges to signify difficulty or average known time to complete certain actions. These weights will add up to combine with other metrics to form a complexity assessment. Or we can do graph similarity indexing to recommend relevant recipes.
<aside> 💡 Even though this idea first started out as a way to write down cooking recipes, I believe it is applicable to any assembly process. IKEA instructions booklets, for example, could benefit greatly from a redesign in this direction. Computer system admins and data researchers have long used DAG's for setting up data processing pipeline. And I wouldn't be surprised to find that the food scientists working on industrial recipes for massive large-scale food production are already using this representation. They might even think that this is such an obvious and trivial thing to talk about.
</aside>
Unsurprisingly, being such a natural way of looking into cooking instructions, this method has been discovered by many people, independently. But so far no one has successfully popularized it yet. A quick survey reveals several papers, interestingly a significant number of which are by Japanese researchers:
Flow Graph Corpus from Recipe Texts Shinsuke Mori, Hirokuni Maeta, Yoko Yamakata, Tetsuro Sasada [2014] https://pdfs.semanticscholar.org/7f88/398e8928d32366ebf725eb457cb2fa3a94bf.pdf
This paper focuses on the computational linguistics aspect of automatically extracting the semantic graph from textual recipes. They have developed tools for manually annotating recipes text and released a corpus of 266 annotated recipes here. Note that they haven't actually developed a machine learning tool to do the actual extracting yet. Section 7.3 on possible applications is quite an interesting read.
Cooking Recipe Search by Pairs of Ingredient and Action — Word Sequence v.s. Flow-graph Representation — Yoko Yamakata, Hirokuni Maeta, Takuya Kadowaki, Tetsuro Sasada, Shinji Imahori, Shinsuke Mori [2017] https://www.jstage.jst.go.jp/article/tjsai/32/1/32_WII-F/_pdf/-char/ja
Further research by the same leading authors. This time they had built the automated conversion tool and now focused on the problem of searching recipes accurately where simpler methods like bag-of-words modeling fail to pick up on the nuances of the search intent.
Recipe Sub-goals and Graphs: An Evaluation by Cooks Lucy Buykx, Helen L. Petrie [2012] https://www.researchgate.net/publication/257758092_Recipe_Sub-goals_and_Graphs_An_Evaluation_by_Cooks
This paper focuses on the usability of the DAG recipe representation compared to the traditional textual format. The control group got the traditional long-form version of a recipe, another group got the same recipe but broken down into small steps and the last group was given the DAG form (they call this the "overview" form). From the paper: "The overview condition was rated significantly higher in terms of understandability and organization than the control condition and a number of comments confirmed that this was the preferred recipe representation for most participants."
Predicting the Structure of Cooking Recipes Jermsak Jermsurawong, Nizar Habash [2015] https://www.aclweb.org/anthology/D15-1090.pdf
Very similar in focus and seems to be a response to [Mori, 2014] but they have come up with an actual automated graph constructor from text. It seems they are aware of each other since [Mori, 2017] refers to this paper.