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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
Readit News
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
(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.
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.
So what you are saying is that cooking instructions need phi nodes?
https://www.cookingforengineers.com/
I wonder if they got it from Cooking for Engineers
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.
I guess superficially you can join them together with a final node that is like "serve all the dishes".
And for more complex meals, time planning becomes more important so that everything is ready to serve together.
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.
https://www.cookingforengineers.com/recipe/33/Lemon-Bars
Practically I just have it listed twice if it's important like butter.
https://cookbook.cstebbins.com/recipe/the-best-swedish-meatb...
otherwise if it's a staple like salt I just say something like "stir in and season with additional salt and pepper to taste"
like in https://cookbook.cstebbins.com/recipe/sloppy-sophisto-joes
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.
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
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"
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.
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.
Deleted Comment
A recent example: I really like the Hainanese chicken recipe at https://www.google.com/amp/s/amp.theguardian.com/food/articl... ... But I find it very hard to follow in this format.
Using o1-preview to restructure it, I get something that I find much easier to follow during my cooking workflow: https://chatgpt.com/share/6733e594-df28-8009-ac80-d5dabd1ae0...
But getting from a well-written recipe to structured data is now pretty straightforward... if/when you need structure data.
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.
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....
I found good success using this model for recipes, specially complex baking recipes like breads with multiple repeat ingredients.
For an example, here's a gantt chart for Beef Bourguignon:
https://ibb.co/c3TVTnX
Note that when I print it on a (physical) recipe card, I have the 'prose' instructions underneath.
I still think this is a pretty good idea, and I still use the cards for this recipe, and Beef Wellington.
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.
Here's an example. You'll need to scroll down to see the actual recipe format. https://www.cookingforengineers.com/recipe/194/Cream-of-Mush...
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.
The format is pretty well demonstrated at https://git.sr.ht/~martijnbraam/fathub-data/tree/master/item... which renders to https://fathub.org/en/recipe/indonesian/main/mie-goreng.html
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.
https://imgur.com/a/RDO6j6H
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...
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.
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.
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)
In particular, the cooking time is completely useless without the heat power and the kind of pan, and conversions between pans
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.
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.
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?