> The only "algorithmic" component to that step is that you add milk. The fact that you do so gradually, use a beater during the process, how you identify when you've added enough, how to correct for deviations in viscosity of the mixture, etc are all part of the "source code" rather than the algorithm and wouldn't be something you could republish without being considered a derivative work.
I would disagree. Here's what I learned from your quoted paragraph, expressed in pseudo-Prolog:
- beatInto(FrostingMixInBowl, Milk, $BeaterSpeed) => increaseQty(FrostingMixInBowl, Milk).
- beatInto(FrostingMixInBowl, IcingSugar, $BeaterSpeed) => increaseQty(FrostingMixInBowl, IcingSugar).
- invProportional(viscosity(FrostingMixInBowl), absorbancyPerUnitTime(FrostingMixInBowl)).
- nonNewtownianViscosity(FrostingMixInBowl).
:. invProportional(absorbancy(FrostingMixInBowl), $BeaterSpeed). // implication from standard library
:. require(maxThreshold($BeaterSpeed)). // implication from standard library
- invProportional(viscosity(FrostingMixInBowl), AmbientHumidity).
- invProportional(viscosity(FrostingMixInBowl), AmbientTemperature).
- proportional(viscosity(FrostingMixInBowl), currentQty(FrostingMixInBowl, Milk)).
- invProportional(viscosity(FrostingMixInBowl), currentQty(FrostingMixInBowl, IcingSugar)).
- target(viscosity(FrostingMixInBowl), centiPoise(10000)). //see https://www.globalpumps.com.au/list-of-typical-viscosities
...and then some stuff about how much frosting we're making here, but without the context required to translate those figures into absolute extruded surface area.
Anyway, do you see what I'm getting at with this? We're describing a system of dynamic constraints. What you generate from this "knowledge base" is an action plan that routes you through the system of dynamic constraints to achieve the target (in this case, icing of a specified absolute viscosity.) The constraints are generative, where constraints asserted together produce further constraints, and those constraints can be translated into structured-text warnings like:
• "the icing is too thick to absorb milk at faster than N mL per second; if you introduce it faster than that, the milk will bounce off the surface of the icing rather than absorbing, and probably splatter you in the face."
• "beating the icing too fast shears/aerates it, increasing its viscosity, making it unable to absorb anything, meaning that anything introduced to the icing will bounce off the surface of the icing and splatter you in the face."
Such a system also allows the resolution of ambiguities, where instead of saying "if the icing is too thick", it can know the variables that affect viscosity, and so just ask you to set those variables (i.e. the ambient temperature and rH value for your kitchen) either in your user preferences or at the recipe header; and take that into account to compute initial quantities for ingredients that should produce a viscosity in no need of further adjustment. (But it could also generate the structured text explaining what actions it knows about for this step that increase and/or decrease viscosity — you know, just in case you messed up and didn't follow its perfect robot plan.)
Note that this isn't super out-there tech. People build models that do these computations all the time. Which people? The operational engineers in charge of the day-to-day operations of baked-good and candy factories.
I'm just suggesting, in essence, a generalized domain-specific abstract machine for modelling all such problems in an easy way (rather than rebuilding it half from scratch in spreadsheets each time), such that you could just as easily describe the dynamic-constraint system underlying a steak as one underlying a Mars bar.
...and then using all that just to emit recipe prose. :P
(But you could also use it as the "mental model" a multi-purpose robotic kitchen could use to generate action plans, of course.)