recipe-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(: "note" is an hCard element)
(: "note" in an hCard element)
Line 108: Line 108:
* The element is identified by the class name <code>note</code>.
* The element is identified by the class name <code>note</code>.
* Ingredients and Preparation Time elements {{may}} include a <code>note</code>.
* Ingredients and Preparation Time elements {{may}} include a <code>note</code>.
* The contents of the element {{must}} follow the conventions outlined in [[hCard]].

'''Method''': The method of the recipe.
'''Method''': The method of the recipe.

Revision as of 09:24, 26 November 2008

Recipe Brainstorming

Towards a Recipe microformat. Please read the The microformats process before editing this page.

format-in-progress - #1 - september 2007

For the sake of clarity the format-in-progress from september 2007 was moved to recipe-brainstorming-archive. ThomasLoertsch 14:12, 11. Nov 2008 (CET)

format-in-progress - #2 - october 2008


Recipe is based on examples and fields in existing formats. The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

Please note that Format-In-Progress sections are intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema. This Format-In-Progress was produced by ThomasLoertsch 15:29, 15. Oct 2008 (CET)


This second Format-In-Progress reflects the discussions following the first one from september 2007 (see recipe-brainstorming-archive). It is not an entirely new format-in-progress proposal but rather an evolution from the september07-version and about 90% the same. A short overview of changes:

  • made author and published plural
  • added ingredients element
  • made ingredient an optional subelement of ingredients
  • modified quantity (and removed the element quantity) to improve compatability with Measure microformat research
  • deleted ingredient-optionality
  • method changed to optional
  • preparation-time changed to optionally multiple instances
  • added note to preparation-time and made both notes hCard elements
  • preparation-time
  • added nutrition
  • removed rel-license support for licensing and made license an element

Root Class Name

To be decided. Likely ‘hRecipe’.

Property List

Class names author, photo and note are taken from hCard 1.0, published used from hAtom 0.1 and item from Measure microformat research.

  • Title. recipe-title. required. text.
  • Summary. recipe-summary. optional. text.
  • Author. author. optional. 1 or more. hCard 1.0.
  • Date published. published. optional. 1 or more. Datetime Design Pattern.
  • Photo(s). photo. optional. 1 or more. img or url. [[hcard].
  • Ingredients. ingredients. required. text with optional valid HTML markup or 1 or more ingredient elements.
    • Ingredient. ingredient. optional. 1 or more.
  • Method. method. optional. text with optional valid HTML markup.
  • Yield. yield. optional. text.
  • Preparation time. preparation-time. 1 or more, optional. (see ISO-31-1 duration brainstorming)
    • Note. note. optional. text. [[hcard].
  • Tags. tag. optional. 1 or more. rel="tag".
  • Nutrition. nutrition. optional. 1 or more.
  • License. license. optional. see issues for scoping problems with rel="license".

Field Details

Title: The title of the recipe.

  • The element is identified by class name recipe-title.
  • A Recipe MUST have a recipe-title

Summary: The summary provides a short introduction or an accompanying statement about the recipe.

  • The element is identified by class name recipe-summary.
  • A Recipe MAY have a recipe-summary.

Author: Author the person who authored the recipe.

  • The element is identified by class name author.
  • A Recipe MAY include an author.
  • The contents of the element MUST include a valid hCard 1.0.

Date published: The date the recipe was published.

  • The element is identified by the class name published.
  • A Recipe MAY include a published date.
  • SHOULD (?) use the Datetime Design Pattern to encode the published datetime.

Photo: Accompanying image.

  • The element is identified by the class name photo.
  • A Recipe MAY include one or more photo elements.
  • The element SHOULD use an <img> element.
  • The element MAY use any other element that contains a URL, such as <a> or <object>, but it is not recommended.
  • The contents of the element MUST follow the conventions outlined in hCard 1.0.

Ingredients: Describes the ingredients used in the recipe.

  • The element is identified by the class name ingredients.
  • A Recipe MUST include one ingredients element.
  • The field MAY include valid HTML markup (e.g. paragraphs).
  • The element MAY include 1 or more ingredient elements.

Ingredient: Describes one ingredient used in the recipe.

  • The element is identified by the class name ingredient.
  • It MUST only occur within an ingredients element.
  • A Recipe MAY have one or more ingredients.
  • The element MAY include the fields num, unit and item following Measure microformat research.
  • The element MAY include a note.

Note: A note concerning an Ingredient or a Preparation Time element (for element Preparation Time see below).

  • The element is identified by the class name note.
  • Ingredients and Preparation Time elements MAY include a note.
  • The contents of the element MUST follow the conventions outlined in hCard 1.0.

Method: The method of the recipe.

  • The element is identified by the class name method.
  • A Recipe MAY include a method.
  • The field MAY include valid HTML markup (e.g. paragraphs).

Yield: Specifies the quantity produced by the recipe.

  • The element is identified by the class name yield.
  • A Recipe MAY include a yield.

Preparation Time: The time it takes to prepare the meal described by the recipe.

  • The element is identified by the class name preparation-time.
  • A Recipe MAY include one or more preparation-times.
  • Each Preparation Time element MAY include a note, to specify their respective purpose.


  • The element is identified by class name nutrition.
  • A Recipe MAY include one or more nutrition elements.
  • The element MAY include the fields num, unit and item following Measure microformat research.

License: Specifies the license under which a recipe is published.

  • The element is identified by the class name license.
  • A Recipe MAY include a license.


<div class="hrecipe">
	<p class="recipe-title">Pommes Frites</p>
	<p class="recipe-summary">
		Pommes frites originate in outer space. They are served hot.<br />
		This recipe is only an example. Don't try this at home!
	<p class="vcard fn">Thomas Loertsch</p>
	<p>Published <abbr class="published" title="2008-10-14T10:05:37-01:00">14. Oct 2008</abbr></p>
	<img src="/img/pommes.png" class="photo" width="100" height="100" alt="Pommes Frites"/>
	<p class="ingredient hmeasure">
		<span class="num">500</span> 
		<span class="unit">gramme</span>
		<span class="item">potatoes</span>,
		<span class="note">hard cooking</span>.
	<ul class="method">
		<li>First wash the potatoes.</li>
		<li>Then slice and dice them and put them in boiling fat.</li>
		<li>After a few minutes take them out again.</li>
	<p>Enough for <span class="yield">12</span> children.</p>
	<p class="preparation-time hmeasure">Preparation time is approximately 
		<span class="num">90</span> 
		<abbr class="unit" title="minutes">min</abbr>.
	<p class="preparation-time hmeasure">Add 
		<span class="num">5</span> 
		<abbr class="unit" title="minutes" >min</abbr> 
		for <span class="note">preparing the Ketchup</span>.
	<p>This recipe is <a href="" rel="tag">easy</a> and <a href="" rel="tag">delicious</a>.</p>
	<p class="nutrition hmeasure">
		Pommes Frites have more than 
		<span class="num">1000</span> 
		<span class="unit">Joule</span>
                <span class="type">Energy</span>.
	<p>This recipe is licensed under <a href="" rel="license">CC by 2.0</a>.</p>


RecipeML-based Brainstorm

Excerpted from Conor Bandon's Blog entry and derived from The RecipeML Spec:

  • Recipe_Title
  • Summary Description (one liner)
  • Measurement System (U.S., Imperial etc)
  • Ingredients (each one a separate "item" rather than block text with count/amount/range/unit broken out too)
    • Some (e.g. meats, vegetables) could optionally be marked up with (elements of) the proposed species microformat. Andy Mabbett 06:41, 16 Nov 2006 (PST)
    • Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. α
    • Units need separate microformat: see Measure microformat research
    • Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. Steve Lewis 18:55, 11 Feb 2007 (PST)
  • Preparation Time (overall time)
  • Yield Quantity and Unit (4 pancakes or 5 servings)
  • Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. α
    • Author (Person) (hCard 1.0?)
    • Submitter (Person) (hCard 1.0?)
    • Source (Book Title etc)
    • Date (Of Creation or Publication)
    • Rights (Copyright or other)
    • Meal Category (Starter, entree, dessert )
    • Cuisine Category (Italian etc)
  • Instructions (text, but can contain:)
    • Steps (optional)
      • Should be an ordered list Andy Mabbett 14:46, 16 Nov 2006 (PST)
      • Another vote for an ordered list, perhaps in the XOXO 1.0: Extensible Open XHTML Outlines format. α
      • Many recipes associate ingredients with specific steps of a multi-step method; if methods are broken out into steps, then the format should support this association whether the complete ingredient list is up front or the ingredient list is itself broken out per step. Ben Curtis
  • Photo (optional) Cameron Perry
    • Could be one per dish, or one for each (or for some of the) step(s). Andy Mabbett

Cookcamp brainstorming

At CookCamp in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a photo of the whiteboard: 422072573_9956d93f61.jpg

To Do: OCR this and enter rough notes here...

Additional Suggestions

  • Steps - As cited above but to include estimated time per step. Include the type of step (prep, preheat, cook, bake, mix, saute, etc) as well as the ingredients involved. This would be very useful when trying to time a meal so all the food appears together.
    • I think this is being to specific. Are there any real world examples where this would be useful? --Yde 08:41, 30 May 2008 (PDT)
  • Difficulty/Notes - Perhaps incorporation of hReview to describe difficulty (using rating) and general comments (review), as an optional field. Frances Berriman
    • -1. Too diverse in the wild, better handled bytags (at least in the first version). same for suitablility.
  • Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly rel="tag". Andy Mabbett 14:57, 16 Nov 2006 (PST)
  • Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an example recipe from for useful grouping in cocktail mixing. Steve Lewis 19:10, 11 Feb 2007
    • Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". Estêvão Samuel Procópio 15:33, 16 Dez 2007 (PDT)
    • This could be solved by using a xoxo list and ignoring list items that don't include a class="name". Example:

<ul class="ingredients"> <li>Booze <ul> <li>1 part <span class="name">Rum</span></li> </ul> </li> <li>Mixer <li>1 part <span class="name">Cola</span></li> <li>1 part <span class="name">Lime juice</span></li> </li> </ul> --Yde 13:09, 18 Apr 2008 (PDT)

    • We can't have a dependency on XOXO or any list mark-up for ingredients. That's too restrictive on publishing patterns, preventing patterns like:

<p class="method">Take <span class="ingredient"><span class="quantity">a handful</span>

of spinach</span> and fry it</p> --BenWard 13:20, 18 Apr 2008 (PDT)

    • You're right. I think grouping would introduce too many new elements (class="group", class="group-title") considering how relatively uncommon this is. --Yde 13:51, 23 Apr 2008 (PDT)
  • Method > Steps - or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
    • -1. Outside 80/20. POSH is good enough for this purpose. --ThomasLoertsch 15:04, 01 Oct 2008 (CET)
  • Number of dishes or similar - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. WilleRaab 16:57, 20 Jul 2007 (PDT)
  • Suitable for occasions - what occasions are the dish suitable for? WilleRaab 16:57, 20 Jul 2007 (PDT)
  • Category - many sites categorize their recipes. WilleRaab 16:57, 20 Jul 2007 (PDT)
    • Tags could be used for both suitability and category.
  • Under what terms is the recipe licensed? Microformat: rel="license". Often a page is in the creative commons but the page author has taken some text from a copyrighted page and in theory re-published the work in violation to the terms of use, adding a rel="license" to each recipe on the page? Lee Jordan 20:55, 04 Feb 2008 (GMT)
  • Single foodstuffs - If "method" is made optional, this could be used for marking up individual foodstuffs in prose. for example, "I like to eat cheese for supper." would become:
I like to eat <span class="hRecipe"><span class="ingredient">cheese</span></span> for supper.

or simply (if the proposed "sub-microformat-pattern" is adopted):

I like to eat <span class="hRecipe-ingredient">cheese</span> for supper.
Andy Mabbett 08:16, 5 Jan 2008 (PST)
    • But that's not really a recipe, is it? And what would the purpose of knowing that cheese is an ingredient be? --Yde 12:46, 18 Apr 2008 (PDT)
    • -1. Makes no sense to me either --ThomasLoertsch 15:29, 01 Oct 2008 (CET)
  • Menus - With the addition of a "price" field, and perhaps one or two others, and again making "method" optional, this microformat can also be used for menus. See menu examples. Andy Mabbett 02:39, 19 Feb 2008 (PST)
    • I would consider this out of scope (which is to produce an as-simple-as-possible microformat "for the mark-up of instructions for creating meals, drinks or food-based items" - introduction) --Yde 13:39, 23 Apr 2008 (PDT)


per serving. May be part of the Measure microformat research microformat in future.

  • +1. Nutritional information is quite important for a lot of people and is inside the 80/20. It should be included as an optional element. The problems are: which nutritional information exactly? A common denominator is calories, proteins, carbohydrates and fat. That's also what european law demands as information on packaged food. Most sites that I visited only list calories as nutritional information (if any). Since Calories are a somehow superordinate concept for proteins, carbohydrates and fat that's fine. is quite extreme with a huge list of nutritional information - clearly outside 80/20 IMHO. Another problem: although Calories are the most popular term, the measure is deprecated in favor of Joule. hMeasure too uses Joule. I'd therefor propose to add the optional element nutrition and subelements calories("mandatory") in Joule,fat("optional"), protein("optional"), carbohydrates("optional"), and dietary fiber("optional"), those all in grams. --ThomasLoertsch 15:16, 01 Oct 2008 (CET), modified 09.Oct 2008 and 13.Oct 2008
    • +1 for a nutrition element. However, I would like to change the subelement calories to energy, as that would allow using either calories or joules (using hMeausere) and it feels weird to state joule in an element called calories. --Yde 05:57, 11 Oct 2008 (PDT)
    • I felt the same and energy is a good idea. However I think we should stay with Joules, since hMeasure doesn't include Calories and we don't want to get things too complicated.
      • hMeasure allows any units to be used. The unit property is defined as an opaque string. The draft spec does allow parsers to delve into this otherwise opaque string and assign meaning to it, and strongly suggests that any parsers which do this support all SI units and prefixes. However, it does not prevent authors from using non-SI units, such as calories. TobyInk
      • You're right. Still, wouldn't it make more sense to go for the standardized Joule instead of the deprecated and non-standardized Calories?
        • I think a lot of people are using calories instead of joule (or both), so IMO it would be too restrictive to only allow joule. --Yde 02:50, 18 Oct 2008 (PDT)
    • But do we really decide for the multi-element proposal outlined above? Or should we rather go for a simple and single nutrition element, optional, without subelements (and with hMeasure Joule)? I'm still undecided myself. ThomasLoertsch 12:02, 13.Oct 2008 (CET)
    • I added a third version of encoding nutrition to the proposal. It is rather flexible and introduces only one new element. I also made Joules a preferred, but optional unit, so Calories are possible now too. ThomasLoertsch 12:55, 5.Nov 2008 (CET)

For the record: these are 3 possible encodings for nutrition. see abve for the final version

    • A more elaborate version would add information for fat, proteins, carbohydrates and dietary fiber - but this may already be out of the 80/20 range. Of course a lot more nutritional values would be available but these seem definitely outside 80/20.
    • Nutritionnutrition. optional
    • A third version would model nutritional information like ingredients:
    • The first version probably fits the 80/20 rule best. The second version gives more guidance and encompasses most real world usecases. The third version is very flexible, without adding many new elements.

ThomasLoertsch 15:54, 11.Nov 2008 (CET)

In a private discussion TobyInkster enlightened me: The idea behind hmeasure is that it has four key components:

  • item: the thing that you are measuring (e.g. The Great Wall of China)
  • type: the aspect of it that you are measuring (e.g. its height, its width, etc)
  • unit: the unit you are measure it in
  • num: the measurement itself
  • By embedding the "nutrition hmeasure" inside the hrecipe, you are implicitly setting "item" to refer to the recipe itself - so the thing that we are measuring is the recipe. So then "type" allows us to specify what aspects of the recipe we are measuring (Energy, dietary fibre, fat, etc). E.g.
<div class="hrecipe">
   <p class="nutrition hmeasure">
     <span class="type">Energy</span>:
     <span class="num">1000</span>
     <span class="unit">J</span>
   <p class="nutrition hmeasure">
     <span class="type">Dietary Fibre</span>:
     <span class="num">4</span>
     <span class="unit">g</span>

ThomasLoertsch 16:01, 11.Nov 2008 (CET)


The 'note' property is only useful in some rare cases and might not fit the 80-20 rule.

  • We might want to start as simple as possible and leave this out for a future revision.
  • People often put some of the very basic preparation steps into the ingredients list. For example, ingredients lists sometimes read like "one onion, finely chopped".
  • +1. note should stay as an optional value. There are so many ways to define ingredients that it seems useful enough to fit into the 80/20. --ThomasLoertsch 15:26, 01 Oct 2008 (CET)


Instead of note I'd rather remove the optional property. Information about the optionality of an ingredient can easily be added in the note field, e.g. together with suggestions for a possible replacement. --ThomasLoertsch 12:59, 13.Oct 2008 (CET)


For informally or concisely written recipes, the method is often left out. Could we either make this optional, or have an optimisation such that if the method is absent, the entire text of the recipe is taken to be the method. TobyInk 02:53, 15 Jul 2008 (PDT)

  • e.g. salad, sandwich and smoothie recipes don't often require a method to be useful.
  • +1 for making it optional. Although most recipes rely heavily on a method there are indeed those where it isn't necessary. If 80/20 does mean that easy or simple usecases should be facilitated it would be in line with the principal to make the method optional. And it wouldn't hurt anybody either. --ThomasLoertsch 15:04, 01 Oct 2008 (CET)
  • I don't know... Making the method optional would make "I like to eat cheese for supper" a technically valid recipe, but it provides no value as a recipe. In other words, I am concerned that this will lead to people using the format for things it was not intented for. I don't know if this will happen, but we need to take it into consideration. --Yde 06:17, 11 Oct 2008 (PDT)
  • I think there's no technical way to prevent misuse (and no other way either ;-). --ThomasLoertsch 12:52, 13.Oct 2008 (CET)

Preparation Time

Make preparation-time plural and add an optional preparation-time-note element inline to preparation time

  • preparation-time (optional, plural)
    • preparation-time-note (optional, singular)

There are often times additional to the main preparation time i.e. the time the dough needs to rise. When scanning a recipe for practicality - i.e. your guest are coming in 4 hours - this is a very important information. Allowing preparation-time to be used more than once per recipe and adding an optional note element would allow great flexibility in stating such details while staying simple. It could also be used to give times for different parts of a recipe like cake and topping or to differentiate times for preparation, waiting and cooking. --ThomasLoertsch 15:05, 01 Oct 2008 (CET)

  • That's a good point. But how do we semantically connect the preparation time and a specific part of the recipe? --Yde 06:25, 11 Oct 2008 (PDT)
  • In the absence of sections for ingredients or method steps I see no way to connect the preparation time and a specific part of the recipe in a standardized manner. But the same applies to ingredients and method steps. I guess a solution would need some quite involved sectioning constructs. In my feeling this is not such a big problem that it justifies further constructs. ThomasLoertsch 12:25, 13 Oct 2008 (CET)


There are a lot of units typically used in recipes that do not make much sense in most other cases and therefor most likely will never make it into a 80/20-aware measure-microformat. This is a deliberatly short list:

  • cup
  • leave
  • pinch
  • tablespoonful
  • teaspoonful
  • lacing
  • tie (??? my english is really leaving me here, hope you get the idea)

note can be used to indicate more subtle differentiation (like a "big spoonful", "some leaves" etc). I think this list is both usefully short and complete. The following measures:

  • weight (gram)
  • volume (litre)
  • length (metre)

can be taken from the measure microformat. I guess measure is already stable enough that it's save to use these terms "experimentally". The measure-element should be optional. That way nobody is forced to select a value from it - it's just a help to facilitate interoperability. --ThomasLoertsch 15:45, 01 Oct 2008 (CET)

Proposed Optimisations


Can we have this optimisation?... if no "item" is found, the entire ingredient is taken to be the item. TobyInk


<span class="ingredient">salt</span>

is a shorthand for:

<span class="ingredient"><span class="item">salt</span></span>
  • +1. That and the Proposed Ingredient List Optimisation seem to be very pragmatic proposals. --Yde 14:40, 14 Jul 2008 (PDT)
  • -1. I'm not convinced that it's wise to introduce variations in the syntax for the singlemost important element (beside the title). Also the case seems very rare to me. Can you give some examples? --ThomasLoertsch 15:07, 01 Oct 2008 (CET)

Ingredient List

TobyInk 03:42, 23 Mar 2008 (PDT):

If class="ingredients" (note: plural) is found on an element, class="ingredient" (note: singular) is automatically implied on all its children.

<ul class="ingredients">
<li><span class="quantity">3</span> <span class="item">eggs</span></li>
<li><span class="quantity">6 oz</span> <span class="item">self-raising flour</span></li>
<li><span class="quantity">6 oz</span> <span class="item">caster sugar</span></li>
<li><span class="quantity">6 oz</span> <span class="item">butter</span></li>
<li><span class="quantity">1 tsp</span> <span class="item">vanilla essence</span></li>

is a shorthand for:

<ul class="ingredients">
<li class="ingredient"><span class="quantity">3</span> <span class="item">eggs</span></li>
<li class="ingredient"><span class="quantity">6 oz</span> <span class="item">self-raising flour</span></li>
<li class="ingredient"><span class="quantity">6 oz</span> <span class="item">caster sugar</span></li>
<li class="ingredient"><span class="quantity">6 oz</span> <span class="item">butter</span></li>
<li class="ingredient"><span class="quantity">1 tsp</span> <span class="item">vanilla essence</span></li>
  • I agree. This would save a lot of space, especially combined with the proposed hmeasure minimisation technique. --Yde 12:57, 18 Apr 2008 (PDT)
  • Do we have ingredients (plural) as an element? Doesn't that open a whole can of list-issues? --ThomasLoertsch 15:37, 01 Oct 2008 (CET)

Problems with programatically marking up ingredients

While I understand the need for a item element within an ingredient, in practice this may be difficult to implement. The quantity element suffers from the same problem, but it's optional, unlike item.

The problem occurs when marking up existing recipes for display. A list of ingredients pulled from a database is trivial to mark up with ingredient but it's nearly impossible to add the required item with a high degree of accuracy. Doing so would require being able to parse each ingredient and identify and separate the quantities and items, which is only really possible if you know in advance every form the quantities will take so you can accurately pattern-match them.

For a real-world example, I'm currently building a site for a good-sized (9,000+) recipe collection. These recipes come from a number of sources and contain many different units of measure. While I can match for things like "oz", "cup", etc, and assume that what follows is the item, this is error prone and doesn't take into account things like "pinch", "dash", and the nearly endless list of other possible terms I may encounter.

I'd like to suggest that item be made optional, as the other child elements of ingredient already are. People coding recipes by hand or who are otherwise able to separate these things may use them, but those of us who are unable to do this can omit them while still outputting valid recipe microformat.

Kenn Wilson 11:29, 19 Oct 2008 (PDT)

  • The way I've implemented this in Cognition, any markup within ingredient is optional — ingredients can be just an opaque string if desired. TobyInk 01:49, 20 Oct 2008 (PDT)
  • Kenn's case is indeed a convincing argument. I changed the october08 proposal accordingly. It's now inline with Cognition too. ThomasLoertsch 12:59, 5.Nov 2008 (CET)


Issues have been moved to a seperate recipe-issues page.



As of September 2008, Cognition has experimental support for this format. (Details of support.) Recipes may be exported in format or RDF.

examples in the wild

Wild Mushroom, Pancetta & Truffle Risotto by Toby Inkster

related pages