Just finished my own overthinking of recipe structures.
I figure that a recipe is more or less an upside-down tree!
Where you start with a list of all the nodes (ingredients)
Have a n:1 relationship with the next series of nodes (steps)
until you finish at a single node (the dish you're trying to make)
So instead of having a separate chunk of "here's my ingredients" and "let me repeat the ingredients and one by one instruction until the end" I figure you can display the upside-down tree to convey more information with less words.
Well, it would be more like a directed acyclic graph, not a tree, because you can re-use nodes.
(And it's not even necessarily acyclic, because eg sourdough or master stock is perhaps best modelled as a cycle.)
In any case, looking at a recipe as a tree or a graph is a very limited view:
A great recipe isn't a list of steps to produce 'something'. A great recipe has a dish in mind with a specific taste (or a specific family of tastes with knobs you can turn), and the author has worked out what parts of the recipe you need to adapt in what ways to compensate or take advantage of current local conditions.
Eg some days it's warmer than others, so you need to adjust your fermentation times. Or some parts of the world have harder water than others. Or your available veggies might have different amounts of moisture etc.
From a slightly pedantic point of view that misses the point of cooking or baking, I disagree about the ability to re-use nodes.
If you have a recipe that uses 150g flour in step 1, then later uses 350g flour in step 4, then you actually have two separate ingredients:
1. 150g plain flour
2. 350g plain flour
It may useful to present an ingredient summary for the purposes of shopping which collects that to 500g flour, but from when trying to represent the recipe, it's actually two different ingredients, and it'd be a false re-use to try to re-use the node or try to treat those ingredients as a single ingredient of greater quantity.
Just because two things appear otherwise identical, doesn't mean they are.
I sometimes see a similar issue in software development and re-use of classes or functions. Two different cases happen to need identical handling, so get put through the same code paths. Then later it turns out one case needs to be treated slightly differently, so that path ends up with special casing, and you get a mess of special handling with case statements or "bool treatDifferently" parameters.
If things are conceptually different, then treat them differently, don't assume false commonality.
It's a bit philosophical, but I'm not sure you can really execute the same steps twice. A cycle would imply you can get stuck baking something forever.
When you come back to do the "same" operation again, you're fundamentally dealing with different items, even if it doesn't appreciably appear to be the case.
You might have different criteria for evaluation, but something has fundamentally changed.
Let's look at the simplest case you might be tempted to model as a cycle:
> "Salt to taste"
Now, that would traditionally be modelled in a flowchart as a cycle:
1. Add salt
2. Test taste. Too little salt? Go to step 1. Else go to step 3.
3. End.
However, in strict modelling terms, I'd argue there's a hidden parameter, "number of saltings attempted".
You wouldn't repeat that a hundred times and keep adding salt, after a while you'd suspect that your taste-buds had gone or the salt had gone funny.
So rather than a cycle, it's actually a series of steps with a hidden step counter, which eventually has different outcomes.
The graph of that state machine suggests that you repeat the cycles indefinitely. But I have it on good authority that real world turnstiles only have a finite coin box. [citation needed] So there's some extra hidden state.
You'll also need to break up intermediate products. An egg breaks down into yolk and whites. Whites may be used for different purposes, one of them foam. Foam might be broken down further.
In particular the lemon meringe pie. You separate whites and yolks to prepare the filling and the meringue separately before merging them in the last step.
>it'd be a false re-use
Technically, recipes are monoidal pre-orders and I guess you could find arguments against what you propose in the mathematical foundation, unfortunately I'm not versed enough in category theory to articulate it properly.
> From a slightly pedantic point of view that misses the point of cooking or baking, I disagree about the ability to re-use nodes.
For example, if you make the "Lobster, Poached with Shellfish, Pear, and Kale" from the 11-madison park cookbook, you will make a "white balsamic vinaigrette" which is then used directly to make the "Pear Glaze", "Pickled Mustard Seeds", and "Pear marmalade" components. (The pickled mustard seeds also go into the "Pear marmalade" component.)
you can divide it into multiple containers, where they become multiple objects, each participating in a different (sub)recipe. node as use of unit-item, not the physical bunch of item itself. instance, not type.
Except the completion of the preparation of various nodes may have to be synchronized to that of other nodes - i.e. the steps can not be parallelized in the general case. Some nodes expire, experience changes in temperature or moisture distribution and so on. In that sense, there is additional context that your model doesn't account for that may preclude certain nodes from being combined.
How often do you see that knowledge expressed in the recipes themselves?
Microdata doesn't need to _fully_ describe something. It's not describing to a machine how to perform the recipe, it's just annotating the text with useful metadata. It's metadata, doesn't need to be full data.
Doesn't mean that there aren't users that would desire a GANTT chart for a recipe (or set of them) if given the opportunity from enough data. Getting an entire meal out on time is one of the oldest schools of project management, after all.
Well, it’s often in the steps; stuff like, while the sauce is simmering, prepare the vegetables… just before the sauce has reduced, add the red wine. And some is just implicit knowledge that comes with experience, true.
I also haven’t seen a site that actually turns that into a neat visualisation, but as an amateur chef, properly timing steps of a recipe is definitely important.
I’m inclined to agree with GP though that a good model should be able to capture that.
To me it looks like having the timing for each step is enough (schema.org already supports that).
You can then _decide_ what to paralellize (maybe you want to take it slow, maybe you have another person to help you, etc).
To me, it sounds way simpler. Specially for those writing or annotating the recipes. You're thinking of the reader, but the writing is important too, it's the hidden cost of making super detailed models.
You also often have ingredients or intermediate products that are used in more than one step so a tree is not ideal. You could duplicate those ingredients/intermediates but that would not be helpful.
And for more complex meals, time planning becomes more important so that everything is ready to serve together.
To be honest, I kind of prefer when a recipe treats duplicate ingredients as completely separate. Rather than that "use 300g of the butter here, use the rest here" approach which is harder to follow.
That works well for a basic off-the-shelf ingredient, but what if you needed a complex dressing/sauce/broth/marinade/spice mix that was later used in multiple combinations. You'd want to make that all in one batch.
Some dishes require more overlap, which will be tricky to write in this format.
E.g. taking the pan juices and turning that into a sauce. It's a separate process/dish, yet wholly dependant on the other process completing a critical step.
Here is an example from Cooking for Engineers - Lemon Bars. If you scroll down to the recipe you can see it uses all-purpose flour twice and lists it two times on the left side of the table.
This makes it real hard to determine the total amount of flour needed. Maybe add another column to the left, that sums up all the ingredients, in the format you might get it at the store. Then the second column becomes the mise en plas step, where the base ingredients are divided and prepared/chopped/grated etc.
Problem is column 1 and 2 wont necesarily have ingredients on the same row...
> I think of them as 2 different nodes, 2 instances of the same type of ingredient.
But this is inconvenient during the shopping step of the process. There you want all uses of an ingredient (possibly across multiple recipes) collapsed into 1 node.
> The use case I'm solving for myself is easy lookup while I'm cooking
This is a constant source of stress for me cooking from cookbooks I otherwise like. I prefer to measure on-demand, and wish the steps would just duplicate the quantities of the ingredients "whisk in the olive oil (1/4 cup)" instead of "whisk in the olive oil" so I don't have to scan the list of ingredients and figure it out
Duplicating the nodes is also far from ideal when the reused node is not a raw ingredient but an intermediate with possibly complex dependencies itself. Duplicating the whole subtree would not be helpful.
I would say that it gets a bit more complex than that.
some recipes can produce multiple related dishes, and some ingredients can have multi-step substitutions. So Graph would be a better representation.
you could join multiple dishes into final 'abstract' dish to force it into tree-esque shape with some shuffling hopefully, but i think that's unnecessary limitation - especially if you consider that some recipes give you some compound ingredients(stocks for example) as side-output that you might want to use in future!
This is a great case for using that information for planning future dishes you could cook for free.
under the hood I have it more like a graph with levels. The traversal is from all of the "leaves" to a single node rather than from the head node towards the leaves as in a traditional tree. The upside-down tree is more for a visual for the reader.
At the moment I don't have a recipe that outputs 2 end states but entirely possible since it's more of a graph under the hood.
Interesting. Also allows for some fun ‘expansion’ in recipes. A leaf node may be ‘chicken stock’ but you could link to a recipe that boils down to that one ‘chicken stock’ node if you want to DIY it.
In a previous job I worked for a site doing natural language parsing on recipes.
We noticed one of our partner websites had an unusual number of unique ingredients. It turned out every ingredient was a link to another recipe to make that ingredient, along the lines of your idea.
However for some reason (presumably SEO) they took this to the extreme and everything was a recipe. Including apples.
The recipe for “apple” is
1. Take 1 Apple
2. Eat and enjoy
But since Apple is a prerequisite for this recipe, infinite looping is a risk in the kitchen now
overthinking some more: your idea is great but it removes the one feature that classic recipes have: sequencing.
You can have the best of both world, though, if the branches in your tree had some kind of timing associated.
Like when you make lasagnas, the bolognese takes 1 hour to cook, while the bechamel takes less than 10 minutes. You need to have a way to say: "while the bolognese is reducing, make the bechamel"
I’ve been cooking with recipes quite a bit lately (before it was just random stuff) and I must say that sequencing is always wrong.
Unfortunately they all seem to assume that chopping, cleaning and moving stuff around is all done in 0 time. I wish the recipes would take this into account more.
Because of this I actually would prefer the plain tree organisation more.
mise in place is the art of reducing all that other stuff to as close as zero time as possible during the cooking, and many recipes expect the cook to read through first and identify what can be prepared/placed in advance. https://en.wikipedia.org/wiki/Mise_en_place
That is fine for professional recipes, when you cook for dozens of people. But for home cooking, if they say 25-35 minutes prep time 40-60 minutes cooking time, I’d expect them to count the cutting in there.
In fact, going through a project management basics training at work recently reminded me that cooking recipes are isomorphic to project plans. Which makes DAGs an obvious natural representation for a recipe, and incidentally, makes the Gantt chart one of the best ways of looking at it.
A Gantt chart for a single recipe may make some sense, but doesn’t really add value. A Gantt chart for a whole dinner — I’m making these six dishes, figure out what I have to do when — is much more interesting. But for this to be passive, the edges on your DAG need to carry metadata about how long the action can/must/should be delayed (no active work), and the nodes (tasks) must carry metadata on how long the task takes. For example, after a whipping my egg whites, they can’t just sit there for two hours; and boiling my pasta water may take at least 12 minutes, but I’d rather not leave it on the boil for another 30.
> the edges on your DAG need to carry metadata about how long the action can/must/should be delayed (no active work), and the nodes (tasks) must carry metadata on how long the task takes.
Yes, those are all constraints that need to be stored there. Some of them are fixed, others can be computed when optimizing the plan.
It's also information you should have specified on the recipe. Most of it usually isn't, as it's either obvious[0] or the recipe author doesn't even realize it's a parameter.
--
[0] - Some obvious to anyone, some obvious to someone very experienced at cooking. Confusing them makes things really difficult for beginners.
I find "higher level" format issues to be of greater concern. These are issues like: is the recipe structured in a way that makes the prep/process flow clear, makes it obvious when a certain ingredient needs to be prepped but divided into multiple parts for use in different stages, or when different stages lead to products that are combined and subsequent poisons in the workflow?
Was just about to say the same thing. I don't care as much about the structure but the presentation. Something I have also disliked is how recipes are standardized around ingredients and quantities at the top and steps below. I often have a recipe open on my phone and I find its a non-optimal instruction set.
Have been doing something exactly like yourself to split it into functionally two parts, there is the shopping list and for me the optimal steps of prep/cooking which includes the quantity for each item.
Presentation and structuring is really, really important. The best I've found so far is a multicolumn format: https://i.imgur.com/w0UrJt5.png
Column 1 is the quantity. This doesn't really belong in the first column but it matches traditional ways of writing things and doesn't cause any actual trouble to do it that way, so whatever, we can do it that way. Column 2 is the ingredient. And column 3 is the cooking instructions. The rows are then grouped (shaded) by which ingredients go into which cooking instructions.
You can scan down columns 1 and 2 to get a prep / mise en place list, or just column 2 to get a shopping list (possibly involving deduplication if an ingredient is called for more than once), then execution is just running down column 3. The only real problem with execution is when it gets nonlinear (you want to overlap steps 3 and 4 in that recipe, for example) but that's a problem with any format I know of.
It's not perfect, but it works really, really well, and better than any other format I've ever seen.
...also now I want chili since it's cold and wet here in Seattle. And I should probably revise that recipe to reflect what I really do, but it's just chili, it's pretty tolerant of whatever you have lying around....
Take a look at my website, https://letscooktime.com/ and let me know what you think of the way I render recipes. There is an internal representation like this:
1. A recipe is composed of multiple components
1. A component is composed of ingredient requirements and steps
1. An ingredient requirement is a tuple of an ingredient and a quantity
I found good success using this model for recipes, specially complex baking recipes like breads with multiple repeat ingredients.
For myself, the one thing missing the quantity of items inside of the recipe itself. I am often using my phone to read a recipe while cooking and its annoying to have to scroll back and forth to see how much of something I need to add. I have all the ingredients out and ready, just tell me in the steps how much of a seasoning I need to be adding.
Yes! Phone screens are too small to show both the instructions and the ingredients at the same time. To address that in CookTime, I highlight any instance of an ingredient found in the recipe instructions and show the quantity if you click/tap on it. I could change it to just show it unconditionally if that wasn't apparent when you looked at a recipe (like this one for example https://letscooktime.com/Recipes/Details?id=ed962bb3-64b7-42...)
I gave your example the instruction "Reformat in two-column format, with the ingredients listed on the left side as they are used" (i.e. the style used in Julia Child's _The Art of French Cooking_) and chatgpt failed horribly.
Many years ago I experimented with making recipes into Gantt charts. For more complex recipes this proved incredibly useful. I spent some time trying to automate turning some of the recipe formats into Gantts, but it was pretty cumbersome. I'll bet a good LLM would make this achievable now.
For an example, here's a gantt chart for Beef Bourguignon:
I use a version of this preparing for the holidays when I have multiple dishes all trying to finish at approximately the same time.
I use a vertical grid format, top to bottom, with rows bucketed into 10 minute increments. Columns are different cooking implements, so I can ensure I am not over allocating space in the oven/microwave/whatever nor my ability to manipulate the next dish.
Makes it trivial to assess where I am in preparing everything on game day. Also, it gives me a historical artifact for the meal. Which is unexpectedly neat to reference.
After reading another comment here about a recipe being an “upside down tree” I now understand what at least this format is trying to accomplish.
It has some really nice properties, but trades off a key feature of the gantt format: your hands can only be doing one thing at a time. With the gantt format it’s very clear what you are supposed to be doing at any time and it preserves the order of operations. It doesn’t express how things are combined, however, which the tree format accomplishes.
My motivation for the gantt format was to prevent getting “meanwhiled” by a recipe. You are chugging along, and think you are in good shape, and come across that dastardly word in a recipe: Meanwhile. Turns out you should have beaten the eggs to a stiff whip 15 minutes ago.
> but trades off a key feature of the gantt format: your hands can only be doing one thing at a time. With the gantt format it’s very clear what you are supposed to be doing at any time and it preserves the order of operations.
In the cookingforengineers.com (COE) format, the order is to do each step in the first column and then move right to the next column and do those steps, etc.
Hmm interesting. But I have to confess I have no idea, intuitively, how to read that format. I’m sure it works once you understand it, but if you need an instruction manual for the format then maybe you’ve lost the plot a bit.
I was having this discussion with a workmate. Where this approach really shines is when you need arrange a number of recipe (for example, for a dinner party). Being able to put together different recipe modules into a meal, then know when to do each section would be fun. Though totally over thinking it.
Oh, I really like the idea of using Gantt charts for meals. If you're trying to serve a bunch of hot dishes at the same time in the end and are constrained in terms of keep warm/crispy/moist options, starting/stopping things at the right time can be critical.
I've also spend a bit of time thinking about recipe formats because I wanted to write down some recipes for my website. Ended up making a custom yaml-based format after looking at the available options and after a while scrapped that again to make a new toml-based format to make it a bit easier to write.
Some notable features is a mini DSL to refer to ingredients in the instruction text and also have parse-able times and temperatures so on the frontend it's easy to switch units with javascript. This is combined with a simple database of ingredient IDs which contains (translated) names and for some of them the density so you can swap the recipe between volume and weight measurements.
Here's my favorite format, which my sister and I made. It doesn't work well for all recipes, but it does for lots of them. Minimizes words, easier to visualize steps.
The replies to this post are, unfortunately, very indicative of the negative side of the "(pseudo-)engineering mindset", which is rather close to the model-constructing mindset inherited from economics (reductionism, hiding any variety incurred by real world complexity, etc).
I don't see very many people here who seem to really have done a lot of cooking, consider it a serious hobby or profession, etc.
None of these proposals pass the smell test as being able to capture anything beyond the most basic of recipes.
Though I'm a software engineer, my main user is my mother-in-law who was a nurse all her life and now likes to bake. Check out for example, this multi-component recipe for Brazilian empadas: https://letscooktime.com/Recipes/Details?id=bc786a2f-50ec-4f...
No way. The professionals I've seen use way, way simpler formats, often just simple lists of ingredients with very minimal instructions.
If anything, these formats capture way too much information. For example, you can't really measure cooking times reliably unless you do sous-vide, if you want to be precise, measure temperature.
I actually agree with this. There's a ton that's between the lines in professional recipes and often much that you can't really put on paper you just have to learn at the foot of the master or try enough times you rediscover the same insights.
My critique should be amended to emphasize that it's about naively constructing a model that picks and chooses elements to include based on availability, convenience, etc rather than one built by studying actual chefs and cooks and learning how they think about recipes.
I can say for myself at least that for many classes of dish I barely pay any attention to the specific details in the recipe. I've made thousands of braises, I just need to know the key elements and the rest just sort of fills in (perhaps there's a comparison to musical proficiency here). I'm less concerned with "brown the meat for X minutes on each side" than "brown to mahogany". I don't find it useful when a recipe says how long to reduce a sauce, but when it says what kind of reduction in volume I should be looking for, that can be helpful. In practice I just have an image of the final product and can taste to tell if I've cooked out the acidity and water sufficiently for how I want the dish to taste.
To put a finer point on it, knowing which elements of a recipe are standard procedure and which are distinct and important to the character of the dish is an acquired skill and not something any system that describes recipes as strict assembly instructions can quantify or even qualify.
First of all, you can't really model exactly what chefs do algorithmically. Or you can, maybe, but you shouldn't do that in a recipe. Unless you are building an autonomous robot-chef arm. I've seen these in China, they only cook very simple dishes.
What developers tend to forget, the recipe is a tool, and it helps chefs put together a dish. A mere combination of ingredients and maybe cooking techniques is usually sufficient for that. It is NOT an algorithm.
That's why I liked the 3 column layout linked somewhere else in this topic better than the cooking for engineers forget: it has less information which makes the things that matter stand out more.
you're complaining so this is a good place for my complaint. coming at this from another angle, I think "the unix way" is to write your recipe so it looks like a recipe written for a human; but be careful to be rigidly precise in following a uniform format and then command line tools/scripts can parse the recipe to create an ingredients list, double the recipe, etc.
to your point, add structure/features/"coding standards" as you need for automatic processing, but otherwise you have a perfectly written recipe to whatever standards you hold.
rather than unix, what I see up and down this page is Dave Cutler slicing and dicing of data to the point of incomprehensibility. You know how you guys all loved markdown so much that you've embraced it and are now adding so many features that make it as unreadable as html? don't do that again and again, learn not to do it.
(btw I have cooked extensively and at somewhat high levels of precision (tricky sauces, souffles etc)
My wife worked in a higher end catering kitchen and the "recipes" she brought home were crazy to me. They have little instruction other than ingredient ratios and sometimes an extremely rough outline of the technique. I guess a lot of experience is needed to fill out the gaps. As a home cook I would not have been able to follow them without more info.
semweb tech is extensible, you could write a specialized schema or ontology to express more detailed information if you want to.
Think search engines for example. This "cooking time" is often displayed as metadata when you search for recipes. You're just annotating a field for the search engine to display in the results.
Schema.org exists for that. Indexing larger granules of metadata. It is built on RDF so if you need something more specialized, you can use the standards to extend it.
This is actually a fun ontology to think about. You'll need to model pans, ovens and all sorts of cooking hardware. I don't see that knowledge often displayed in recipe websites, so microdata probably isn't the best for a specialized system like that. It would probably use the extended schema/ontology just internally, then publish simplified cooking times for indexing.
I’ve recently been caught up on noodling on the combinatorics of cooking food. I wonder if a structured recipe format would be helpful to explore the ‘solution space’ of any given dish.
For example, think of all the decisions required to specify a curry dish:
How do you cut/mash your garlic and ginger and onions? (If you even add all of those ingredients)
Do you use whole or ground spices? What about for each spice? Cardamom pods or ground cardamom?
Do you toast each spice?
How long do you cook your onions?
And so on. Eventually you get to an absolutely gigantic amount of options that all generate a somewhat similar dish, but with key sensory differences. They may all be ‘chicken tikka masala’ but I’d argue you’d have a very different eating experience across that decision spectrum.
I think this may also play (specifically for Indians) into the idea that moms is best. It’s probably because mom’s is universally unique and you crave that nostalgia.
I'm not confident in any recipe format that I've seen discussed in this thread.
Do any of the recipes you've seen online or elsewhere every bother to talk about what sort of kitchen is needed? Granted, 99% of the time it's just the standard western kitchen (stove/oven/fridge/mixer), but some recipes require less common appliances. A brick pizza oven, or maybe a sous vide machine.
The data might benefit from being in a different format than the file format itself... even that might need to be different than the presentation software. Do I want to be chained to the software, or does this need to be some open format like epub? How would I search through 500 recipes, or 500,000? Do I want to search through that many, do I want to keep that many or purge the not-so-great ones? Earlier in the thread, someone was complaining that they don't want the ingredient list and numbered list instructions at the top... so is this something like html plus optional stylesheets? God help me, xml and xslt?
Why are they giving me fixed ingredient quantities, rather than ratios and quantity-to-serving numbers?
Do recipes need to link up? If I'm making thousand island dressing or tartar sauce, should I be able to tap a hyperlink to a sweet pickle recipe? How would that even work if I had multiple sweet pickle recipes?
Perhaps it’s just me, but I’ve cooked recipes off of 50 year old, grease stained index cards written in barely legible cursive, whose ink has all but rubbed entirely away. And it was fine. Worrying about recipe format is like trying to improve reading as a technology. The state of the art is both really simple and really old. It’s hard to mess up (format-wise, recipe content can definitely suck) and it’s hard to improve.
Much more important to me: is the listed cooking time of onions accurate.
I get the desire to computerize it. Think of all the automation that can be done! Automatic shopping lists! Unit conversions! Scale up or down! Not to mention having a good think about how to organize things appeals to the data-driven mind.
But I find cooking to be resistant to this sort of thing, at least if you have a family. Meal planning is more of a negotiation than a tallying of numbers. You tend to cluster around a few, well-honed recipes that are repeated often. And when you're cooking, having a piece of paper or an index card attached to the vent hood or whatever with a magnet is far more user friendly than having to wake up a tablet or a phone.
(Not to mention passing recipes down through the generations. It's not the same to bequeath the recipes to your grandchildren by saying "give me a ssh key and I'll rsync these MySQL tables to your VPS".)
As someone that's written a whole lot of code parsing both complex XML and JSON, I'd go with a more restrictive JSON format over a more idiomatically correct and elegant (from the data perspective) XML format any day. Complex XML sucks for storing structured data unless it's as restrictive as a JSON document, and then...
The simple use case for XML is always easy, but then it always ends up looking like this:
<step>prepare fruit
<step>prepare <ing variety"bartlet anjou comice">pear slices</ing> from a <ing state="unprepped">pear</ing>
<step>wash</step>
<step>trim
<step>remove stem</step>
<step>peel</step>
</step>
<step>
<step thickness=".25mm">slice</step>
</step>
</step>
<step>...
Plain text is great and all as a display format but it sucks even more than XML to parse as a data format.
You can make JSON that's just as stupid as XML but especially if you have people hand-writing XML, it invites a lot of complexity for a little more expressiveness. If you need to, you can always have flatter XML markup in JSON fields to avoid the large scale recursive structural insanity when parsing.
My gut feeling is that there's something going on here with dueling priorities between (A) the best editing experience with a plain text editor vs. (B) the clearest storage format. This leads to things like "too much inlining" or "too much duplication".
In contrast, imagine relaxing the everything-in-notepad requirement, imagine a renderer that can easily display cross-referenced materials in a readable way. Or a step beyond that, an editor which also gives you "jump to definition" etc.
That change permits a much more internally-consistent XML file, such as one where "materials" and "steps" are separate sections, and any step can references a material that is being used as input or output, with something like <mat_ref id="sliced_uncooked_apples"/> .
I see the value in using xml for simple markup and standardized entities/references but the flexibility makes navigating whole documents more cumbersome. I think that using it inline is a good idea, but above the paragraph level I don’t see the benefit of using it at all. Even in the supremely consistent world of open doc xml, parsing is a bear of a task. For something like this requiring a fraction the complexity, it should either force more internal structure— XML markup in json fields representing ingredients lists, etc— or just decide it’s for presentation only and go with HTML or rtf.
I probably also have a different perspective on both of these topics than most. I’ve dove a lot of automated document work, and also was a chef so I’ve got a more structured, less prosaic approach to recipes.
I was reading through this and caught myself thinking "man, if you want people to read your recipe then just write it", and for that plain text or some minimal markup still works wonders...
That's great for writing recipes for someone to read as recipes, but it's not very useful if you're trying to create a collection of structured data from recipes.
This is one of the golden applications of LLMs. You can see the variety of structured formats proposed in comments, the different use cases, and honestly it seems like a bad idea to privilege any single format. Instead, you as a data consumer can use LLMs to parse common language recipes into the structured format most appropriate to your needs. DAG or linear? JSON or XML? You decide!
If your primary use case is displaying individual recipes that makes good sense. Less-so if you need reliable calculations at a larger scale. For example, if I was making planning software for a catering company, they’d want to know how many cases of onions they need this week for the 9 events with different menus. I don’t trust LLMs for that level of accounting yet. Hopefully soon!
There actually is the BatchML stardardized recipe format, even if it's a different kind of recipes I'm talking about. ISA-88 recipes for describing pharma/chemical batch production processes.
This hurts a little to read. Think about the use cases for recipes:
- Shopping
- Scaling up/Scaling down
- Finding ratios of key ingredients when you're looking at multiple recipes to figure out a dish or what's wrong with the last recipe you tried
- Mise en place, which is conventionally omitted except in very detailed recipes
- Planning cooktimes
- The actual cooking process
And as a home cook, I'm not personally experienced with commercial use cases, but there's even more there: costing servings, menu planning, mise across several dishes with common ingredients, etc. Having seen some commercial recipes, pros will frequently use very simple lists of ingredients and just a few notes on technique. Bakers will use baker's percentages.
The weird "cooking for people who insist on modeling the world in complicated categories" format doesn't support these very well, but it sure helps with "is grinding the whole spices a substep of combining the spice mixture?".
another to add to the list is high-altitude modifications. using mark bittman’s guidelines ingredients and temperatures become a function of altitude. recently i’ve been using llms to make the modifications for me.
I've also been thinking entirely too much about a good recipe structure.
For now I've ended up on ingredients being more or less recipes themselves, and recipes being recursive (as in, recipes use other recipes to create new recipes). Some recipes you can either buy & make yourself. For example, sweet soy sauce: easy enough to make but you could also just buy it in the store. The resulting structure is basically:
Recipe:
directions: rich text
storageInstructions: rich text
prepTime: minutes
cookTime: minutes
priceEstimateperServing: money
ingredients: RecipeIngredient[]
// other fields (e.g. tags, id, name, slug, purchaseableAt, nutrients, etc)
RecipeIngredient:
recipeId: reference to recipe
ingredientId: reference to recipe as well
// Allows grouping ingredients (e.g. "sauce", although the sauce could be a recipe of its own instead)
group: string | null
There's some challenges with this though:
- If you have a shopping list, how do you determine in a complex recipe which "recipes" you'll purchase and which you'll make from scratch (UX issue)
- Some recipes may have alternatives instead (for example: if allergic to X, substitute with Y)
- It puts a lot of burden on the recipe writer.
- Some recipes don't scale linearly with just the ingredients, but perhaps also the cookware (baking a cake for example). Cooklang docs talk about this as well.
Scaling of recipes could be done with a measurement-aware type. Something similar to frinklang[0] for example.
This is something I get (better ways at storing and using information.
I like the of a list of ingredients with the quantity in the top and then repeated in the steps (if no quantity is mentioned in the steps its implied the whole ingredient is used). This makes sense in that you may need to have on hand 3 tbs of butter but 2 get melted and mixed in step 3, and 1 is used to grease the pan in step 5.
The next dimension would be a language/glossary of preparation terms (slice apple - how? radially or into x thickness sheets?) This would be helpful for those without any clue on common actions and maybe later for automation. Though cooking is way more an art than just a set of steps and standard unit quantities.
With a glossary you could search for recipes that use grated apples or recipes that use a food processor, or don't use an oven, etc.
Since people are posting their respective recipe formats, I'll throw in one created by a friend from college. I haven't tried any recipes in this format, but the color coding of processing/ingredient blocks to the vertical time axis and clear listing of how ingredients get processed together are appealing.
I've had multiple recipes on common recipe sites in which, mid-cooking I've realized were missing steps, didn't mention reserving a portion for later, or some elements were not impacted by the serving size multiplier. A diagram of some sort could help me reduce my error rate.
Nice, I have also created a language for recipe based on cook-lang (I didn't use cook-lang because I was not convinced by the syntax). The language is called recipe-lang[0] and it powers https://www.reciperium.com
Check it out, I've open sourced as well a syntax highlight for vscode, a cli for the terminal, a tutorial and a playground, and the wasm modules.
The way ingredients and other things are described. I felt that explaining that a single word ingredient, requires @ only, but if you use multiple words, you have to use @ingredient with space{}, with the empty `{}` at the end can be too complicated to explain.
I felt that for someone who is not familiar with these things, it can be confusing. In recipe-lang the explanation is IMO simpler: wrap the ingredient with `{}`, there are no ambiguities. {salt} or {ingredient with space}, it's quite clear where the ingredient starts and end.
Once they learn that, everything else is a prefix of the curly braces, timer? t{}, link to another recipe? @{}, material? &{}. I'm considering for images something like i{} but I haven't had time to experiment with it.
I'm entirely in the "make it easy" camp. I'd rather spend more time gathering, cooking and eating recipes than developing an over-complex schema which I have to think about all the time. I found this [0] which converts markdown and just keep my recipes in Obsidian with a simple ChronoSync to periodically upload stuff to the family recipe website. I did dabble with a scraper that turns web recipes into this same markdown format which is quite fun but really just simple as possible is the way for me!
Cooklang seems pretty much perfect for every use case I can think of.
I would probably prefer a more generic syntax if I were doing it from scratch, but then I'd just wind up with HTML and it wouldn't be as good for recipes.
I could see a more structured approach being useful if you were following one step at a time on a tablet, so maybe that scales better to more complicated recipes?
Most of the stuff I cook is simple enough it all fits on one screenful anyway, on the rare occasion I even use a recipe at all, so I'm not quite sure what the best approach is to cover very complex recipes.
Should include a field for how much the person documenting the recipe loves/loved the cook.
Then I can search by "love" field <= 0 and get the best recipes. Because let's face it-- everything with the highest love field is really being documented for the documenter. But if it's zero (or even better, negative), that's likely to be a good recipe.
Imagine: "I hated that guy sooo much, but damned if he didn't make the best potatoes au gratin." That's a recipe I want to try.
IMHO for mostly text data where you need a bit of custom formatting(e.g. cooking recipes) I would probably choose to go with AsciiDoc and then just adapt a rendering engine to make it look pretty. This way you get all the tooling and learnings that AsciiDoc has accumulated over the years and avoid having to spend time on a DSL and edge case detection that inventing a new standard will require.
Also the people writing recipes (my parents for example) are _most definitely_ not going to learn a DSL, they just want a text box where they can type whatever they want. If you care about having structured data, other humans with more structured proclivities need to do that for you.
Interesting... this kind of codifies what I usually have ChatGPT do with recipes I find. I have it standardise the measurements (I like a mix of weights in grams and volumes in Imperial; sue me), give me a list of utensils and containers, what order I need to have those implements in, and an estimate of time required in each phase of the recipe.
Thinking of good recipe format I think there are quite a many things that could or maybe should be included. Like ratios, maybe minimum and maximum scaling. Portition size, both as main meal or as side. And then total use of ingredient if used in multiple steps.
Here's an idea. A recipe is ultimately a checklist. It's essentially a multi-flow checklist with parts that need to be done sequentially and other parts that can be done in parallel.
So if we had a checklist format, we could easily derive a recipe format from that.
I was looking into the table format for my app[0], but then the notes at the end made me reconsider: Tabular Recipe Notation Patent Pending (Michael Chu)
cooklang is very nice but not all parsers seem willing to display comments or metadata. Eg there are two plugins for obsidian but neither seems willing to display the recipe description or anything else that isn’t a step.
You might also want to consider why you want your recipes to be machine readable. I loved the idea in theory but unless you’ve integrated this with your smart larder/fridge or something it might not be useful.
With latest LLMs I feel there is less and less need to be structured about authoring recipes.
I now jot down rough notes in Obsidian when I make a meal I like, and let AI re-format it if I want to share the full recipe with somebody. This also lets me control the output: if I’m sending the recipe to somebody who is new to cooking, I might ask for a more detailed output than if they were only interested in my flavour combinations or specific techniques.
Yeah, personally I'd use markdown too, at this point it is easier to use llama-3.1-8b to parse markdown / text into your JSON format of choice than it is to massage recipes into a specific markup like Cooklang.
Recipes should be handled like love and fights. Feelings. Understanding of the non-understandable. Emotional to the smell. Adventures to the mouth. Travelling with it. Close your eyes and let it flow from the tongue, dream of where you are with that taste.
Cooking is more like life than mixing things. There is a hidden magic to it. It's the closest thing to magic next to programming.
Exactly like programming. It can get to you and will swallow you whole if you let it.
Go eat now. Eat well. Sleep well. Love well. That is the essence of a good life.
Where you start with a list of all the nodes (ingredients)
Have a n:1 relationship with the next series of nodes (steps)
until you finish at a single node (the dish you're trying to make)
So instead of having a separate chunk of "here's my ingredients" and "let me repeat the ingredients and one by one instruction until the end" I figure you can display the upside-down tree to convey more information with less words.
An example being https://cookbook.cstebbins.com/recipe/bul-koki
With the underlying tree structure looking like https://assets.cstebbins.com/cookbook/images/bulkokiTree.png