Live data from Hacker News

Thinking about recipe formats more than anyone should

rknight.me

91–100 of 140 posts

Re: Thinking about recipe formats more than anyone should

#92
post #25

Earlier quoted context omitted.

What if the same ingredient is used twice in a recipe, for example for cooking and finishing?

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. https://www.cookingforengineers.com/recipe/33/Lemon-Bars

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

Re: Thinking about recipe formats more than anyone should

#93
post #56
post #6

Earlier quoted context omitted.

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: prepare…

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

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.

Re: Thinking about recipe formats more than anyone should

#94
post #15

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

[deleted]

Re: Thinking about recipe formats more than anyone should

#95
post #15

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

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

Re: Thinking about recipe formats more than anyone should

#96
post #15

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

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.

Re: Thinking about recipe formats more than anyone should

#97
post #31

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

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?

Re: Thinking about recipe formats more than anyone should

#99
post #81
post #15

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

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.

Re: Thinking about recipe formats more than anyone should

#100
post #61

Earlier quoted context omitted.

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.
Post reply on HN