Specify sub items ingredient, amount, note for each ingredient in Recipe

[arvidj]

It would be nice to be able to specify i.e.:
3 smashed bananas =
amount: 3
ingredient: banana
note: smashed

[nihonjinrxs]

also, unit of measure, as in:

3 cups olive oil =
amount: 3
measure: cups
ingredient: olive oil

[arvidj]

This might be interesting as well:
http://open.blogs.nytimes.com/2015/04/09/extracting-structured-data-from-recipes-using-conditional-random-fields/

/ Arvid

2015-11-07 17:35 GMT+01:00 Ryan B. Harvey notifications@github.com:

also, unit of measure, as in:

3 cups olive oil =
amount: 3
measure: cups
ingredient: olive oil

—
Reply to this email directly or view it on GitHub
#882 (comment)
.

[RichardWallis]

You could use https://schema.org/TypeAndQuantityNode for this - if we extended the range of recipeIngredient to include it:
typeOfGood: "Olive oil"
amountOfThisGood : 3
unitText: "cup"

typeOfGood: "Banana"
description" "Smashed bananas"
amountOfThisGood : 3

[mfhepp]

+1

[bbdg]

It looks like data-vocabulary used to allow name and amount sub-items in data-vocabulary.org/Recipe. Does anyone know the history of how this got dropped when migrating over to schema.org? I wonder if the thinking was to reduce complexity of the markup task.

The New York Times article hints at some of the possible complexity, like "4 tablespoons melted nonhydrogenated margarine, melted coconut oil or canola oil". Another issue would be with branded ingredients like "Heinz® Ketchup": do you include the brand in the ingredient name or no? Recipe sites tend to know when an entire ingredient statement starts and ends (it's often the basis of a bulleted list), but further parsing the ingredient statement can introduce ambiguity.

I like the idea of having a means of specifying more sub-structure, but I just wonder if the real-world ingredients fall easily into this pattern. The NYT article made it sound like quite a tedious process and I wonder if any other recipe sites go to that much trouble.

[arvidj]

As long as one leaves the possibility to not use these "sub-items", one could just not specify them in cases where it is too tricky.

In regards to current usage, I know some recipe sites link the name, so that one can for instance find more ingredients using the same recipies. Some sites mark up the amount, so that one can automatically convert between units and scale recipies.

[mundschenk-at]

Having something like the old http://data-vocabulary.org/RecipeIngredient with amount, unit and name seems kinda obvious to me. I'm a bit disappointed that schema.org still does not support this use case.

[akaleeroy]

Nearly 3 years on, what is the preferred way to represent recipe ingredients using structured data?

We need to represent quantity and price, to be able to do things like:

• unit conversion
• compute if the recipe is cheap
• know if you have the ingredients already, or you need to buy
• know how much to buy for the recipe

Just write them as type Text, as recipeIngredient expects, and repeat them modeled using HowToSupply elsewhere?

I tried looking at a WordPress plugin to see how they support unit conversion and I think they do it outside of the JSON-LD, through the page markup

<span data-normalized="200" data-fraction="" data-original="200" class="wpurp-recipe-ingredient-quantity">200</span>
<span data-original="g" class="wpurp-recipe-ingredient-unit">g</span>

[tisdall]

I can process and parse all the information on a Recipe, but ingredients required me to use CRFsuite and train with a data set to figure out that "2 tablespoons sugar" is "amount: 2, measure: tablespoon, ingredient: sugar". The whole point to structured markup is so a machine can easily understand the content without resorting to natural language processing, but recipeIngredient has been left to require natural language processing to interpret the contents. Even recipeYield already allows a QuantitativeValue so you can mark up the details!

recipeIngredient needs to be changed to also allow something other than just plain text. It's a pretty glaring oversight for anyone who has had to work with Recipe and do anything with the ingredients.

What do we need to do to get this issue actually looked at by someone with authority to change the standard?

[akaleeroy]

@tisdall I went around the pretty glaring oversight by using supply

"tool": [
  {
    "@type": "HowToTool",
    "name": "food processor",
    "requiredQuantity": 1
  },
  {
    "@type": "HowToTool",
    "name": "baking sheet",
    "requiredQuantity": 1
  }
],
"supply": [
  {
    "@type": "HowToSupply",
    "name": "rolled oats",
    "requiredQuantity": {
      "@type": "QuantitativeValue",
      "value": 100,
      "unitCode": "GRM"
    }
  }
],
"recipeIngredient": [
  "100g rolled oats"
]

Normally we'd say a baking sheet is a supply, and rolled oats is an ingredient.
More discussion on /r/semanticweb: Schema.org/Recipe – How should I model recipeIngredients as something richer than @type Text

[tisdall]

@akaleeroy - That's interesting, but then there's still the possibly difficult task of matching up supply entries with the recipeIngredient entries. Also, this adds duplication in the data when it seems like supply for a recipe really is the list of ingredients (unless you include something like cooking gases which is expended but not included in the final product). Also, my specific use-case is that I'm importing recipes and I'd never think to look in supply for already parsed information as ingredients should be under recipeIngredient. Likewise, I don't look for recipe instructions under step.

(BTW, supply says "A supply consumed when performing instructions or a direction.", so "baking sheet" isn't really a supply. That should be placed under tool.)

In that Reddit post it says that schema "made a trade-off between machine readability and ease of authoring", but the general principle in other fields is you can use a complex object (like a HowToSupply' in supply) or you can just use simple text. recipeIngredient is one of the few fields where a complex object makes a lot of sense, but none was added on top of just allowing text.

[akaleeroy]

@tisdall The arguments you made are exactly why I'm also in favor of changing the recipeIngredient spec.

(To flog this to death... baking sheet can stand for baking parchment – disposable, something you buy and run out of, hence supply – or silicone mat – not disposable, hence tool 😄 )

[Teifun2]

Is there nothing that can be done to expedite this change?

[github-actions]

This issue is being tagged as Stale due to inactivity.

[brettp]

This is still a problem 7 years later and shouldn't be closed as stale. If there are no plans to address this, then there should be plans to extend the standard to allow ad-hoc definitions for more specific, machine-readable types. The main argument against this seems to be "people don't use structured data for ingredients" which isn't particularly compelling because the goal is to enforce generators to use structured ingredients.

[mundschenk-at]

Also "more people would use structured data for ingredients if it was standardized" 🤷