schemaorg
Specify sub items ingredient, amount, note for each ingredient in Recipe
It would be nice to be able to specify i.e.: 3 smashed bananas = amount: 3 ingredient: banana note: smashed
also, unit of measure, as in:
3 cups olive oil = amount: 3 measure: cups ingredient: olive oil
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 [email protected]:
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 https://github.com/schemaorg/schemaorg/issues/882#issuecomment-154721831 .
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
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.
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.
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.
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>
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?
@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
@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.
@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 :smile: )
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
Also "more people would use structured data for ingredients if it was standardized" 🤷
@danbri: https://github.com/schemaorg/schemaorg/pull/2738 was closed and referenced this issue as the correct place to continue the conversation, but it does not seem any further discussion happened. Is there anything that can be done to move this forward?
(Replying by email, adding some google folk whose github IDs I don’t have to hand)
It really needs some parties who consumes the data to step up and say they’ll use the extra detail. Otherwise we can continue making things more expressive (aka complex) but it only adds cost to markup publishers, for questionable gain.
No harm in talking through the design possibilities here but we are always hesitant to just add expressivity endlessly without it being tracked by usage.
Our goal here is not so much to create the ideal description of a Recipe (or anything) but to help accomplish useful things in the real world. In this case, help folks cook, or track their eating.
A useful thing to do (since waiting for mega corporations to change their products is not so fun) might be to contact interesting data users like eg MyFitnessPal (who have import-from-the-web by url functionality) to see if they can be engaged. And as ever with metadata we are then stuck with tricky balance of advice to publishers - should they use the fancy new variation or the old structure which is understood by eg Pinterest, Apple, Yandex and others, as well as Google? Ideally extensions are additive in a way that allows a graceful evolution…
@rvguha & co. can relay a Google perspective on whether there is enthusiasm for the markup there, but as ever all search engines and large scale user-facing platforms are especially relevant.
Dan
On Wed, 31 Jul 2024 at 15:43, ChevySSinSD @.***> wrote:
@danbri https://github.com/danbri: #2738 https://github.com/schemaorg/schemaorg/pull/2738 was closed and referenced this issue as the correct place to continue the conversation, but it does not seem any further discussion happened. Is there anything that can be done to move this forward?
— Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/882#issuecomment-2260690767, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGKVABML2HF7N3GIWR3ZPDZ2LAVCNFSM6AAAAABLYUNPIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRQGY4TANZWG4 . You are receiving this because you were mentioned.Message ID: @.***>
@christianlupus: Would the Nextcloud Recipe app use this additional data structure? I know work has been done to parse out ingredient quantities to enable changing the number of servings in the app, but I think getting that in the official schema would be a better approach.
Solid apps like Umai would benefit from the additional data and interesting further use cases would evolve from having such data in a Solid Pod. E.g. there have been experiments with combinging pantry data with what is listed in a recipe.
As a potential user of this, I would also like proper support of amounts and units for ingredients.
Use cases for us:
- We'd like to do upscaling of recipes for larger community events (we need e.g. 500 portions of a recipe, based on the base recipe)
- We'd like to offer our recipes in a semantic format, to import in tools like e.g. Tandoor. Currently this is somewhat broken because Tandoor's import parses the units from the string and does not give an immediately usable result
It seems like this was already done in https://github.com/schemaorg/schemaorg/issues/4454 — but I’m not seeing these changes on the website yet.
This should be visible now as of the release that happened a couple weeks ago. I'm sorry I didn't find this issue at the time when I created the other. We have a lot of old issues.
