Live data from Hacker News

Thinking about recipe formats more than anyone should

rknight.me

121–130 of 140 posts

Re: Thinking about recipe formats more than anyone should

#121

Earlier quoted context omitted.

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.

I don't think this knowledge even exists. Can you point me to a recipe website that has any structured information about paralellized steps?

To me, it sounds like you want to annotate data that doesn't even exist.

Re: Thinking about recipe formats more than anyone should

#122
post #95

Earlier quoted context omitted.

I'd start with a DAG. 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 ta…

> 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.

Re: Thinking about recipe formats more than anyone should

#123
post #7
post #4

Earlier quoted context omitted.

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!

Re: Thinking about recipe formats more than anyone should

#124

Earlier quoted context omitted.

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.

I don't think this knowledge even exists. Can you point me to a recipe website that has any structured information about paralellized steps? To me, it sounds like you want to annotate data that doesn't even exist.

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.

Re: Thinking about recipe formats more than anyone should

#125
post #75

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…

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.

Re: Thinking about recipe formats more than anyone should

#126
post #86

Earlier quoted context omitted.

Well, you need to be careful what your graph and nodes are supposed to model. I was implicitly assuming that your graph models instructions and procedures. You seem to assume that the graph models concrete physical items. You can execute the same steps twice, but you can't eat the same piece of butter twice.

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 s…

I'm glad you figured out that the graph is a model, and like any good model, it picks some characteristics of reality to keep and many to leave out.

Have a look at the example of a turnstile state machine on Wikipedia: https://commons.wikimedia.org/wiki/File:Turnstile_state_mach...

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.

Re: Thinking about recipe formats more than anyone should

#127

Earlier quoted context omitted.

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,…

See my comment in another thread about this topic: https://news.ycombinator.com/item?id=41700416 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, unfo…

Separating the eggs is a great example!

Re: Thinking about recipe formats more than anyone should

#128
post #108

Earlier quoted context omitted.

> 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 musta…

> if you make the "Lobster, Poached with Shellfish, Pear, and Kale" from the 11-madison park cookbook, you will make a "white balsamic vinaigrette" I think the post you're replying to is saying that you'll make 3 "white balsamic vinaigrettes" instead of reusing the same one 3 times. Which makes sense since one step of the recipe will be to divide the vinaigrette into 3 amounts to make the other ingredients.

No, you make a larger amount of liquid, and then you divide it.

You'd only have one node. Just like you don't put every bite of food into its own node.

Re: Thinking about recipe formats more than anyone should

#129
post #117

Earlier quoted context omitted.

What do you not like about cooklang? I’m in the early stages of building an app around it.

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 `{…

Interesting, I’m nowhere near a place where I’m thinking about the implementation yet so maybe I’ll poke your version a bit!

Re: Thinking about recipe formats more than anyone should

#130
post #124

Earlier quoted context omitted.

I don't think this knowledge even exists. Can you point me to a recipe website that has any structured information about paralellized steps? To me, it sounds like you want to annotate data that doesn't even exist.

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 t…

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.

Post reply on HN